Re: About exploring TLS parallelism

Mayan Moudgill <mayan@bestweb.net>
Mon, 30 Mar 2009 18:57:08 -0400

          From comp.compilers

Related articles
About exploring TLS parallelism milla.sun@gmail.com (2009-03-25)
Re: About exploring TLS parallelism mayan@bestweb.net (Mayan Moudgill) (2009-03-27)
Re: About exploring TLS parallelism milla.sun@gmail.com (2009-03-30)
Re: About exploring TLS parallelism mayan@bestweb.net (Mayan Moudgill) (2009-03-30)
| List of all articles for this month |
From: Mayan Moudgill <mayan@bestweb.net>
Newsgroups: comp.compilers
Date: Mon, 30 Mar 2009 18:57:08 -0400
Organization: Compilers Central
References: 09-03-098 09-03-103 09-03-115
Keywords: parallel, architecture
Posted-Date: 31 Mar 2009 14:26:27 EDT

milla.sun@gmail.com wrote:


> On 3TB27HU, OBNg7J1207V, Mayan Moudgill <ma...@bestweb.net> wrote:
>
>>milla....@gmail.com wrote:
>>
  I'm imagining about such a
> hardware simulation tool that could provide the following feature: It
> support that one can add a hardware component ...
> I don't know many about the hardware simulators, and couldn't get a
> clear view to decide which one could be the candidate. Could anyone
> give some advice on it or just put forward criticism on my idea about
> the simulation tool?
>
> And also another issue, If I want to study the TLS based on some
> compiler infrastructures, which would be a good choice? Open64?


Do what everyone else in academia does:
- adopt SimpleScalar (or some other processor simulator).
- don't use a compiler, use traces and assembly level tweaking instead.


The general problem in evaluating a compiler optimization + hardware is
that you are speeding up a program by capturing parallelism. However,
that same parallelism could also be exploited by other techniques. So,
to be of real interest you have to identify speed-ups in
highly-optimized programs for cutting-edge OoO superscalar processors.


The next problem is that it is quite common to come up with hardware
that can improve performance quite radically, if only it could be
implemented at current cycle times without huge increases in area.


Finally, coming up with a program transformation that is applicable to a
few situations is pretty easy; converting it into a compiler
optimization can be quite hard. This is specially true when you need to
analyze large segments of the program or examine memory
aliasing/reference patterns - and for TLS, it looks like you have to do
both.


Out of curiousity - which university are you studying? Who is your advisor?


Oh, yes - one last thing - good luck! You'll need it.



Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.