After my recent patches to HEAD not anymore.
I have also a SSSE3 patch and a general gcc 4.2 update patch pending.
Dňa 12.03.2011 09:42, Jakub Lach wrote / napísal(a):
>
> "Core i7 based procesors run slower with -march=core2 (new option) on the
> system
> compiler than with -march=nocona"
>
>
On Sun, Mar 13, 2011 at 3:19 PM, Jakub Lach wrote:
>
>
> Vinícius Zavam wrote:
> >
> >
> > i'm still curious about things like CPUTYPE= and -march= configured as
> > native, gentlemen.
> > is it the "golden egg" to use with our system or not? why "natives"
> > aren't in the benchs?
> >
> > /me fe
Vinícius Zavam wrote:
>
>
> i'm still curious about things like CPUTYPE= and -march= configured as
> native, gentlemen.
> is it the "golden egg" to use with our system or not? why "natives"
> aren't in the benchs?
>
> /me feels confused.
>
>
> --
> Vinícius Zavam
> profiles.google.com/egypc
2011/3/12 Poul-Henning Kamp :
> In message <4d7b44af.7040...@freebsd.org>, Martin Matuska writes:
>
>
> Thanks a lot for doing this properly.
>
>>What significance level should I take?
>
> I think I set ministat(1) to use 95 % confidence level by default
> and that is in general a pretty safe bet (
In message <4d7b44af.7040...@freebsd.org>, Martin Matuska writes:
Thanks a lot for doing this properly.
>What significance level should I take?
I think I set ministat(1) to use 95 % confidence level by default
and that is in general a pretty safe bet (1 in 20 chance)
>I hope this approach is b
2011/3/12 Martin Matuska
> Hi Poul-Henning,
>
> I have redone the test for majority of the processors, this time taking
> 5 samples of each whole testrun, calculating the average, standard
> deviation, relative standard deviation, standard error and relative
> standard error.
>
> The relative sta
2011/3/12 Martin Matuska
> Hi Poul-Henning,
>
> I have redone the test for majority of the processors, this time taking
> 5 samples of each whole testrun, calculating the average, standard
> deviation, relative standard deviation, standard error and relative
> standard error.
>
> The relative sta
Hi Poul-Henning,
I have redone the test for majority of the processors, this time taking
5 samples of each whole testrun, calculating the average, standard
deviation, relative standard deviation, standard error and relative
standard error.
The relative standard error is below 0.25% for ~91%, betw
"Core i7 based procesors run slower with -march=core2 (new option) on the
system
compiler than with -march=nocona"
Sorry for double mail, isn't CPUTYPE=core2 just alias to nocona with base
compiler?
--
View this message in context:
http://old.nabble.com/FreeBSD-Compiler-Benchmark%3A-gcc-base-
Thanks for starting this interesting
comparison.
Maybe using -march=native would be
simpler and more meaningful? I'm thinking
about penryns especially.
regards,
- Jakub Lach
--
View this message in context:
http://old.nabble.com/FreeBSD-Compiler-Benchmark%3A-gcc-base-vs.-gcc-ports-vs.-cl
Martin Matuska wrote:
> we have performed a benchmark of the perl binary compiled with base gcc,
> ports gcc and ports clang using the perlbench benchmark suite.
> Our benchmark was performed solely on amd64 with 10 different processors
> and we have tried different -march= flags to compare binary
> Putting the 'speed' question completely aside, I would like to comment
> on other issue(s) there. The switching of the ports to use the port-provided
> compiler (and binutils) would be very useful and often talked about feature.
>
> Your approach of USE_GCC_BUILD as implemented is probably not go
In message <4d7a42cc.8020...@freebsd.org>, Martin Matuska writes:
>But what I can say, e.g. for the Intel Atom processor, if there are
>performance gains in all but one test (that falls 2% behind), generic
>perl code (the routines benchmarked) on this processor is very likely to
>run faster with t
I don't take this personally and fully understand your point.
But even if all conditions you described are met, I am still not able to
say "this is better" as I am not doing a microbenchmark. The +x% score
is just an average of all test scores weightened by factor 1 - this does
not reflect any rea
Quoting Martin Matuska (from Thu, 10 Mar 2011
22:33:37 +0100):
Hi everyone,
we have performed a benchmark of the perl binary compiled with base gcc,
ports gcc and ports clang using the perlbench benchmark suite.
Our benchmark was performed solely on amd64 with 10 different processors
and we
In message <4d7943b1.1030...@freebsd.org>, Martin Matuska writes:
>More information, detailed test results and test configuration are at
>our blog:
>http://blog.vx.sk/archives/25-FreeBSD-Compiler-Benchmark-gcc-base-vs-gcc-ports-vs-clang.html
Please don't take this personally Martin, but you have
On Thu, Mar 10, 2011 at 10:33:37PM +0100, Martin Matuska wrote:
> Hi everyone,
>
> we have performed a benchmark of the perl binary compiled with base gcc,
> ports gcc and ports clang using the perlbench benchmark suite.
> Our benchmark was performed solely on amd64 with 10 different processors
>
Hi everyone,
we have performed a benchmark of the perl binary compiled with base gcc,
ports gcc and ports clang using the perlbench benchmark suite.
Our benchmark was performed solely on amd64 with 10 different processors
and we have tried different -march= flags to compare binary performance
of t
18 matches
Mail list logo
