public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Nicholas Krause <xerofoify@gmail.com>
To: Richard Biener <rguenther@suse.de>
Cc: gcc@gcc.gnu.org
Subject: Re: Multi-Threading GCC Compiler Internal Data
Date: Wed, 18 Sep 2019 20:09:00 -0000	[thread overview]
Message-ID: <feaf1789-34d7-8496-2b77-0121bcb85f7f@gmail.com> (raw)
In-Reply-To: <nycvar.YFH.7.76.1909180959440.5566@zhemvz.fhfr.qr>


On 9/18/19 4:01 AM, Richard Biener wrote:
> On Tue, 17 Sep 2019, Nicholas Krause wrote:
>
>> On 9/17/19 2:37 AM, Richard Biener wrote:
>>> On Mon, 16 Sep 2019, Nicholas Krause wrote:
>>>
>>>> Greetings Richard,
>>>>
>>>> I don't know if it's currently possible but whats the best way to either so
>>>> about or
>>>>
>>>> use a tool to expose shared state at both the GIMPLE and RTL level.  This
>>>> would
>>>>
>>>> allow us to figure out much better what algorthims or data structures to
>>>> choose
>>>>
>>>> to allow this to scale much better than the current prototype.
>>> You are mixing independent issues.  Shared state needs to be identified
>>> and protected for correctness reasons.  In some cases changing the
>>> data structure to be protected can make it cheaper to do so.  The
>>> scaling of the current prototype is limited by the fraction of the
>>> compilation we parallelize as well as the granularity.
>>>
>>> Going forward the most useful things are a) reducing the amount of
>>> state that ends up being shared when we paralellize, b) increase
>>> the fraction of the compilation we paralellize by tackling
>>> RTL optimizations and the early GIMPLE pipeline
>>>
>>> The prototype showed that paralellization is beneficial and that it
>>> can be done with a reasonable amount of work.
>>>
>>> Richard.
>>>
>> Richard,
>>
>> Sorry I think your misunderstanding me. I was asking whats the best way to
>>
>> write a tool to expose twhere and how the shared state is using being used.
> Such tool would need to solve the halting problem so it cannot exist.
>
> Richard.

I figured but is it still possible to get the data out of perf if 
possible. Not sure

what the best way to get the data for GCC directly is or out of around 
profiler

as I assuming even just splitting out some of the larger GIMPLE functions as

a start may help. So what tools or ways are the easiest to profile make -jx

to your knowledge.

Thats where I starting to profile or get real data for the work,


Nick

      reply	other threads:[~2019-09-18 20:09 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-16 18:25 Nicholas Krause
2019-09-17  6:37 ` Richard Biener
2019-09-17 15:20   ` Nicholas Krause
2019-09-18  8:01     ` Richard Biener
2019-09-18 20:09       ` Nicholas Krause [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=feaf1789-34d7-8496-2b77-0121bcb85f7f@gmail.com \
    --to=xerofoify@gmail.com \
    --cc=gcc@gcc.gnu.org \
    --cc=rguenther@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).