On Thu, Nov 20, 2008 at 7:44 AM, Marco Correia
<[EMAIL PROTECTED]> wrote:
> hi,
>
> I noticed that a number of benchmarks I use to run to test my library run
> about 10% slower with gcc-4.3.1 compared to gcc-4.2.3. Would someone here be
> interested on more details, or is this normal ?
>
See
http
hi,
I noticed that a number of benchmarks I use to run to test my library run
about 10% slower with gcc-4.3.1 compared to gcc-4.2.3. Would someone here be
interested on more details, or is this normal ?
Thanks (please forward any reply ro myself since I'm not subscribed)
--
Marco Correia <[EMA
Ken Zadeck asked me to do another round of DF branch benchmarking on
SPEC2000. There is a progress on compilation speed (0.5%-1%) since
last my benchmarking pratically for all platforms. Now in average
code size and SPEC scores are practically the same for the mainline
and the branch. To be
ears we
give the scheduler more freedom on the branch. This inevitably takes
time (the scheduler is the slowest part of GCC-on-Itanium already,
anyway).
>> PPC64 374.33 399.72 +6.8%
>> Pentium4 253.89 269.43 +4.9%
>
>
> Note that while I appreciate the benchmarkin
+6.8%
Pentium4 253.89 269.43 +4.9%
Note that while I appreciate the benchmarking very much, not
providing details on which SPEC tests regress in compile time is bad.
Can you manually identify the worst offender, ideally by file? Or is it
just overall regressing?
I can guess it is mostly o
On 5/7/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
This is one more df-branch comparison after the last merge branch (done
05/03) with the mainline on the merge point (r124382).
There is a big progress since last my benchmarking on compilation
speed of SPECFP2000 for PPC64
This is one more df-branch comparison after the last merge branch (done
05/03) with the mainline on the merge point (r124382).
There is a big progress since last my benchmarking on compilation
speed of SPECFP2000 for PPC64. But whatever changed this does not
work well for all platforms and
Vladimir Makarov wrote:
I've promised to make more thorough and accurate comparison of
df-branch and mainline on last merge point to the branch. The
df-branch compiler does not include sunday's Steven's patch which uses
a separate obstack for df bitmaps. It does not change code but it can
spe
On 4/23/07, Seongbae Park <[EMAIL PROTECTED]> wrote:
As for the perlbmk slowdown on P4.
my initial guess is that it might be due to cross-jumping or block ordering
- those are things I noticed the dataflow branch generates slightly
different code
than mainline.
I didn't try to narrow down where
On 4/23/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
...
To improve the scores I'd recommend to pay attention to big
degradation in SPEC score:
9% perlbmk degradation on Pentium4
3% fma3d degradation on Core2
3% eon and art degradation on Itanium
3% gap and wupwise degradation on PPC64.
V
chmarks). Four platforms for benchmarking were
used:
x86_64: 2.6 Ghz Core2.
Itanium: 1.6Ghz Itanium2.
PPC64: 2.5Ghz G5.
Pentium4: 3.2Ghz Pentium4 (additionally -mtune=pentium4 was used).
The attachments contain more verbose info about SPEC2000 results
(there base is df-branch, peak is mainlin
ny
said he has some ideas about how to fix this.
No problem. New DF infrastructure is inevitable (we differ only in
question when to merge). I see a real progress in compilation speed
improvement. I am going to do more benchmarking (on merge points) to
check the progress.
As you probably
On 4/12/07, Steven Bosscher <[EMAIL PROTECTED]> wrote:
On 4/12/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
> An interesting observation is that the more hard registers the processor
> has, the bigger slowdown is. Although it might be a coincidence.
Yes, I noticed this too. I don't believe
On 4/12/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
An interesting observation is that the more hard registers the processor
has, the bigger slowdown is. Although it might be a coincidence.
Yes, I noticed this too. I don't believe this is a coincidence. It's
the first thing I was plannin
Steven Bosscher wrote:
On 4/12/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
> Thanks for testing this. Do you also have per benchmark compilation
> times, perhaps?
>
Not really. I don't do that because runtest startup is about 0.4s (on
ppc64) and a few fp tests are compiled for 1.5s. If y
On 4/12/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
> Thanks for testing this. Do you also have per benchmark compilation
> times, perhaps?
>
Not really. I don't do that because runtest startup is about 0.4s (on
ppc64) and a few fp tests are compiled for 1.5s. If you are interesting
in anal
Steven Bosscher wrote:
On 4/12/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
SPECFp2000 compilation time (user time):
machine mainline branch change
-
x86_64 104.8s117.7s +12.3%
ppc64312.3s367.8s +17.8%
ia64 377.6s502.9s +33.2%
Hi
On 4/12/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
SPECFp2000 compilation time (user time):
machine mainline branch change
-
x86_64 104.8s117.7s +12.3%
ppc64312.3s367.8s +17.8%
ia64 377.6s502.9s +33.2%
Hi Vlad,
Thanks for testing
DF made a big progress especially with recent Ken Zadeck's DCE/DSE
improvements. I think dataflow benchmarking will be interesting to
people. Here is the comparison of dataflow-branch as of Apr 7. with
the mainline on the last merge point (r123656) done by Daniel Berlin
on Apr 7.
Comp
blic after HiPEAC conference and HiPEAC GCC tutorial
so that some researchers and engineers can start looking at this issue. There
was
an interest from some companies that develop embedded systems - they use
GCC more and more and they often use MediaBench and MiBench for the
benchmarking but find that
aluate this assumption and analyze the behavior of various
programs with multiple datasets. We hope that this will enable more
realistic benchmarking, practical iterative optimizations (iterative
compilation),
and can help to automatically improve GCC optimization heuristic.
I think this is nice bu
programs with multiple datasets. We hope that this will enable more
realistic benchmarking, practical iterative optimizations (iterative
compilation),
and can help to automatically improve GCC optimization heuristic.
We just made a pre-release of the 1st version of MiDataSets and we
made an
22 matches
Mail list logo
