Re: Scheduling without profiling

touati <SidTouati@inria.fr>
Tue, 10 Mar 2009 12:20:48 +0100

          From comp.compilers

Related articles
Scheduling without profiling linuxkaffee_@_gmx.net (Stephan Ceram) (2009-02-19)
Re: Scheduling without profiling blume@hana.uchicago.edu (Matthias Blume) (2009-02-19)
Re: Scheduling without profiling SidTouati@inria.fr (Sid Touati) (2009-02-20)
Re: Scheduling without profiling linuxkaffee_@_gmx.net (Stephan Ceram) (2009-03-06)
Re: Scheduling without profiling SidTouati@inria.fr (touati) (2009-03-10)
| List of all articles for this month |

From: touati <SidTouati@inria.fr>
Newsgroups: comp.compilers
Date: Tue, 10 Mar 2009 12:20:48 +0100
Organization: Universite de Versailles Saint-Quentin-en-Yvelines
References: 09-02-098 09-02-101 09-03-030
Keywords: optimize
Posted-Date: 10 Mar 2009 15:31:24 EDT

Stephan Ceram a icrit :


> OK, so taking the danger of changing hot paths through different inputs
> into account, do you think that it might be a promising idea to mix
> instructions from several paths?


Yes, this idea has been explored simply and empirically by some trace
scheduling techniques. What we are missing is a good theoretical work on it.


Almost all the trace scheduling are simple heuristics that are
experimented on some toy benchmarks with fixed data input. The problem
of mixing instructions from several paths is still open since nobody
demonstrates that the performances are good on multiple data inputs
(from the theoretical and empirical perspective).


This would possibly help the scheduler
> to reorder instructions such that the pipelines/functional units are
> maximally exploited but on the other hand no particular path is favored/
> neglected too heavily.
>


Yes you are right. But new problems will arise regarding instruction
cache effects...
Anyway, providing an instruction scheduling method for multiple data
paths is a promising idea if you can bring some theoretical knowledge.



Post a followup to this message

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