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
Sorry
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/egypcio
Apparently
On Sun, Mar 13, 2011 at 3:19 PM, Jakub Lach jakub_l...@mailplus.pl 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
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:
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:
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%,
2011/3/12 Martin Matuska m...@freebsd.org
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
2011/3/12 Martin Matuska m...@freebsd.org
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
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
2011/3/12 Poul-Henning Kamp p...@phk.freebsd.dk:
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
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
and
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
Quoting Martin Matuska m...@freebsd.org (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
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 real
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 that
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 going
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
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
18 matches
Mail list logo
