On 24/07/18 09:40, Fredrik Hederstierna wrote:
> Hi
>
> This is a general question to all you working with GCC benchmarking.
>
> I have been working with code benchmarks like CSiBE for ARM. From
> time to time unpredicted results appears where numbers gets worse by
> no reas
gt; unpredictable code generation, should such code be banned from benchmarking,
> since results might be misleading?
Well, all benchmarks are going to be imperfect reflections of real-life
workloads in the first place, so their bugs just increase the degree to
which they are misleading.
When a new c
Hi
This is a general question to all you working with GCC benchmarking.
I have been working with code benchmarks like CSiBE for ARM.
>From time to time unpredicted results appears where numbers gets worse by no
>reason.
When looking into what could cause this unpredictable behaviour, I
I have benchmarked both current gcc-4_7-branch and the release gcc 4.8.0
built with...
Using built-in specs.
COLLECT_GCC=gcc-fsf-4.7
COLLECT_LTO_WRAPPER=/sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin12.3.0/4.7.3/lto-wrapper
Target: x86_64-apple-darwin12.3.0
Configured with: ../gcc-4.7-20130323
On Wed, Jun 20, 2012 at 12:47 AM, Walter Landry wrote:
> Richard Guenther wrote:
>> On Fri, Jun 15, 2012 at 12:54 AM, Walter Landry wrote:
>>> Hello Everyone,
>>>
>>> I thought you might be interested in some C++ expression template
>>> benchmarks
Richard Guenther wrote:
> On Fri, Jun 15, 2012 at 12:54 AM, Walter Landry wrote:
>> Hello Everyone,
>>
>> I thought you might be interested in some C++ expression template
>> benchmarks I have done.
>>
>> http://www.wlandry.net/Projects/FTensor#Benchmar
On Fri, Jun 15, 2012 at 12:54 AM, Walter Landry wrote:
> Hello Everyone,
>
> I thought you might be interested in some C++ expression template
> benchmarks I have done.
>
> http://www.wlandry.net/Projects/FTensor#Benchmarks
>
> I found that GCC optimized the expression t
Hello Everyone,
I thought you might be interested in some C++ expression template
benchmarks I have done.
http://www.wlandry.net/Projects/FTensor#Benchmarks
I found that GCC optimized the expression template code better than
unrolling expressions by hand. In fact, GCC was far, far better at
A quick check with...
gfortran -ffast-math -funroll-loops -msse3 -O3 -fgraphite-identity
-ftree-vectorizer-verbose=2 air.f90 -o air >& air_cloog_legacy.txt
grep "LOOP VECTORIZED" air_cloog_legacy.txt | wc -l
5
gfortran -ffast-math -funroll-loops -msse3 -O3 -fgraphite-identity
-ftree-ve
Using the new CLooG.org support in gcc trunk, I was able to benchmark the
performance
of gcc trunk built against ppl 0.11 and either legacy cloog support (built
against ppl 0.10.2)
or cloog-isl support. The benchmarks were done on x86_64-apple-darwin10 with...
Compile Command : gfortran
Hi,
We are implementing a new context-sensitive algorithm for pointer
analysis in GCC-4.5.0.
Can anyone please suggest some good benchmarks for testing it ?
Thanks,
Swaroop.
I would conclude from the statistics that, right now, the cost of
including -fforward-propagate in -O1 overrides any performance benefit
that may result.
I'm still working on a patch to eliminate reaching definitions from fwprop.
Paolo
I've put at
http://www.math.purdue.edu/~lucier/bugzilla/9/
some compile-time and run-time statistics related to PR 39157 and PR
33928 and compile times and run times for the programs in the Gambit
Scheme benchmark suite. The statistics are for 4.1.2 release, 4.2.4
release, 4.3.3 release, 4.4.1 2
J.C. Pizarro wrote:
> p7zip-4.57
> [...]
> 1. 1m50s compile, 1630164 file, 1618639 text, 6120 data, 27168 bss, 5m50s run.
> 2. 1m53s compile, 1665952 file, 1649829 text, 4668 data, 29160 bss, 6m04s run.
> 3. 2m08s compile, 1629088 file, 1613313 text, 4672 data, 29
On Tue, Mar 04, 2008 at 09:02:34AM +, Martin Guy wrote:
> Is there a clause in regressions for "takes longer to compile and
> produces worse code"?
Worse code is a regression, so is slower compile time. Both are
judgement calls; some of them are not going to be changed, but safe
patches chang
2008/2/29, J.C. Pizarro <[EMAIL PROTECTED]>:
> Here are the results of benchmarks of 3 compressors: 7z, bzip2 and gzip, and
> GCCs 3.4.6, 4.1.3-20080225, 4.2.4-20080227, 4.3.0-20080228 & 4.4.0-20080222.
Thanks, that's very interesting. I had noticed 4.2 producing 10%
large
Here are the results of benchmarks of 3 compressors: 7z, bzip2 and gzip, and
GCCs 3.4.6, 4.1.3-20080225, 4.2.4-20080227, 4.3.0-20080228 & 4.4.0-20080222.
--
# User's time is taken, machine is Ath64 3200+ 2.0 G
On Mon, Apr 23, 2007 at 09:49:04AM -0700, Steve Ellcey wrote:
> Jim Wilson wrote:
>
> > Kenneth Hoste wrote:
> > > I'm not sure what 'tests' mean here... Are test cases being extracted
> > > from the SPEC CPU2006 sources? Or are you refering to the validity tests
> > > of the SPEC framework itself
Jim Wilson wrote:
> Kenneth Hoste wrote:
> > I'm not sure what 'tests' mean here... Are test cases being extracted
> > from the SPEC CPU2006 sources? Or are you refering to the validity tests
> > of the SPEC framework itself (to check whether the output generated by
> > some binary conforms with t
output)?
The claim is that SPEC CPU2006 has source code bugs that cause it to
fail when compiled by gcc. We weren't given a specific list of problem.
There are known problems with older SPEC benchmarks though. For
instance, vortex fails on some targets unless compiled with
-fno-stri
On 20 Apr 2007, at 08:30, Ian Lance Taylor wrote:
11) H.J. Lu discussed SPEC CPU 2006. He reported that a couple of the
tests do not run successfully, and it appears to be due to bugs in
the tests which cause gcc to compile them in unexpected ways. He
has been reporting the proble
Steven Bosscher wrote:
It obviously doesn't do that. ICC uses that larger register file, too,
for x86-64.
The Intel compiler can be set to compile for multiple processors,
keeping different versions of the same function in an executable and
picking which code to run based on the processor in u
On Tuesday 22 November 2005 21:18, Scott Robert Ladd wrote:
> Jan Hubicka wrote:
> > I should note that comparison to ICC is not quite fair since it lacks
> > Opteron tunning...
>
> I think you may be comparing oranges to tangerines -- not as bad as
> apples and oranges, but still potentially an in
experience the extra registers of the Opteron provide a
> significant benefit; GCC has an unfair advantage if ICC only generated
> code for the small set of x86 registers.
Forgot to mention, all the tests was x86-64, so ICC used extra registers
too. Also to clarify, the C++ bench
Jan Hubicka wrote:
I should note that comparison to ICC is not quite fair since it lacks
Opteron tunning...
I think you may be comparing oranges to tangerines -- not as bad as
apples and oranges, but still potentially an invalid comparison.
In my experience the extra registers of the Opteron
>
> > Which is why i said "It's fine to say compile time performance of the
> > middle end portions ew may replace should be same or better".
> >
> > And if you were to look right now, it's actually significantly better in
> > some cases :(
>
> Can you prove this assertion?
>
> Here is some dat
On Tue, 3 May 2005 [EMAIL PROTECTED] wrote:
> is there any link to gcc.gnu.org/benchmarks on the web pages ?
Yes, but _rather_ well hidden, to be honest.
Thanks for the hint! I just added a pointer to that page from the
navigation bar on our main page.
Gerald
Hi,
is there any link to gcc.gnu.org/benchmarks on the web pages ?
Hartmut
Machen Sie aus 14 Cent spielend bis zu 100 Euro!
Die neue Gaming-Area von Arcor - über 50 Onlinespiele im Angebot.
http://www.arcor.de/rd/emf-gaming-1
On Apr 8, 2005, at 1:35 AM, vivek sukumaran wrote:
Hello everybody,
I need benchmark programs for my project.
Does anybody have or know the links to C benchmarks
that can be compiled using gcc?
Thanking you,
You question is not clear and this is probably
wrong list for whatever you are looking for
Hello everybody,
I need benchmark programs for my project.
Does anybody have or know the links to C benchmarks
that can be compiled using gcc?
Thanking you,
Vivek
__
Yahoo! Messenger
Show us what our next emoticon should look like. Join the fun
30 matches
Mail list logo
