Re: gcc: poor log() performance on Intel x86_64

[Andrew Haley]

Torsten Rohlfing writes:
 > Greetings.
 > 
 > I am experiencing a major performance problem with the log() function on 
 > the x86_64 platform. It can be illustrated with the following little 
 > test program:
 > 
 > testlog.cxx===
 > #include 
 > 
 > main()
 > {
 > float f = 0;
 > for ( int i = 0; i < 1e8; ++i )
 > f += log( i );
 > }
 > ==
 > 
 > I compile this twice, on the same machine, once as a 64bit binary and 
 > once as 32bits:
 > 
 > g++ -mtune=nocona -msse -msse2 -msse3 -O3 -o testlog64 testlog.cxx
 > g++ -m32 -mtune=nocona -msse -msse2 -msse3 -O3 -o testlog32 testlog.cx
 > 
 > Compiler config is:
 > 
 > Using built-in specs.
 > Target: x86_64-redhat-linux
 > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man 
 > --infodir=/usr/share/info --enable-shared --enable-threads=posix 
 > --enable-checking=release --with-system-zlib --enable-__cxa_atexit 
 > --disable-libunwind-exceptions --enable-libgcj-multifile 
 > --enable-languages=c,c++,objc,java,f95,ada --enable-java-awt=gtk 
 > --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre 
 > --host=x86_64-redhat-linux
 > Thread model: posix
 > gcc version 4.0.2 20051125 (Red Hat 4.0.2-8)
 > 
 > When I run the two binaries on the exact same box and time them, I get 
 > the following outputs:
 > 
 > time ./testlog64
 > 13.264u 0.000s 0:13.26 100.0%   0+0k 0+0io 0pf+0w
 > 
 > time ./testlog32
 > 6.960u 0.004s 0:06.96 100.0%0+0k 0+0io 0pf+0w

You have weird hardware.

[EMAIL PROTECTED] ~]$ time ./testlog64

real0m7.330s
user0m7.328s
sys 0m0.004s
[EMAIL PROTECTED] ~]$ time ./testlog32

real0m7.538s
user0m7.528s
sys 0m0.000s

Andrew.

Re: aapcs apcs-gnu

[Paul Brook]

On Wednesday 15 March 2006 05:20, [EMAIL PROTECTED] wrote:
> Hi all,
> what is the difference beetween this abi?
> The standard arm procedure call is the first one. What is introduced in the
> apcs-gnu? Is there some documentation about the last one?

"apcs-gnu" is the pre-EABI calling convention. I believe it's based mainly on 
the RISCiX calling convention. There are many different variants of the APCS 
but AFAIK none of them particularly well documented. The best documentation 
for apcs-gnu is probably "whatever gcc generates".

"aapcs" is defined in the ABi for the Arm Architecture (aka. EABI)
http://www.arm.com/products/DevTools/ABI.html

Paul

Re: gcc: poor log() performance on Intel x86_64

[Torsten Rohlfing]

Andrew Haley wrote:

> When I run the two binaries on the exact same box and time them, I get 
> the following outputs:
> 
> time ./testlog64

> 13.264u 0.000s 0:13.26 100.0%   0+0k 0+0io 0pf+0w
> 
> time ./testlog32

> 6.960u 0.004s 0:06.96 100.0%0+0k 0+0io 0pf+0w

You have weird hardware.

[EMAIL PROTECTED] ~]$ time ./testlog64

real0m7.330s
user0m7.328s
sys 0m0.004s
[EMAIL PROTECTED] ~]$ time ./testlog32

real0m7.538s
user0m7.528s
sys 0m0.000s

Andrew.
 

My boxes are PogoLinux WebWare CN1200 servers 
(http://www.pogolinux.com/systems/servers/WebWare/index.html#cn1200). 
According to the manufacturer specs the chipset is "Intel E7520 
Chipset." Here's the CPU info according to the kernel (first virtual CPU 
only):


[EMAIL PROTECTED] ~]$ cat /proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 15
model   : 4
model name  :   Intel(R) Xeon(TM) CPU 3.00GHz
stepping: 3
cpu MHz : 3000.237
cache size  : 2048 KB
physical id : 0
siblings: 2
core id : 0
cpu cores   : 1
fpu : yes
fpu_exception   : yes
cpuid level : 5
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall 
nx lm constant_tsc pni monitor ds_cpl cid cx16 xtpr

bogomips: 6009.02
clflush size: 64
cache_alignment : 128
address sizes   : 36 bits physical, 48 bits virtual
power management:

So it's not a big brand box, but I didn't think of it as totally obscure 
either.


Unrelated - a previous reply to my post suggested that this is more 
appropriately discussed on the libc list, so I am sending a CC there.


Thanks for your help.
 Torsten

Re: Ada subtypes and base types

[Michael Matz]

Hi,

On Mon, 13 Mar 2006, Jeffrey A Law wrote:

> > What do you mean by "abuse"?  TYPE_MAX_VALUE means maximal value
> > allowed by given type.
> As long as you're *absolutely* clear that  a variable with a
> restricted range can never hold a value outside that the
> restricted range in a conforming program, then I'll back off
> the "abuse" label and merely call it pointless :-)

I really really can't understand your strong opposition against the 
sensible semantics of TYPE_MAX_VALUE.  If the type has only a certain 
range, than it obviously is a good thing to make this knowledge available 
to the optimizers, even if that range doesn't end at a power of two.  That 
the value of variables of that type has to stay in that range is a 
tautology (i.e. whereever that's not the case it's a bug somewhere, either 
in the source, in the frontend or the optimizer).  It doesn't make the 
notion of TYPE_MAX_VALUE pointless at all.

> The scheme you're using "promoting" to a base type before all
> arithmetic creates lots of useless type conversions and means
> that the optimizers can't utilize TYPE_MIN_VALUE/TYPE_MAX_VALUE
> anyway.  ie, you don't gain anything over keeping that knowledge
> in the front-end.

Sure it can, namely in VRP, and connected optimizations.  First: It's not
clear that also the pascal frontend goes back to the base type for doing
arithmetics.  In fact you assume that arithmetics is done on such
variables at all, which is not necessary.  It can just be used as lookup
value in switches for instance, or in comparisons.  And second: even if it
does promote to do arithmetics the final result probably is again in the
restricted type, again providing the knowledge of the range to VRP 
(obviously the frontend has to somehow make sure that the result of this 
arithmetic indeed fits into the real type, but see above for why this is 
not a very special request).


Ciao,
Michael.

Re: gcc: poor log() performance on Intel x86_64

[Andrew Haley]

Torsten Rohlfing writes:
 > Andrew Haley wrote:
 > 
 > > > When I run the two binaries on the exact same box and time them, I get 
 > > > the following outputs:
 > > > 
 > > > time ./testlog64
 > > > 13.264u 0.000s 0:13.26 100.0%   0+0k 0+0io 0pf+0w
 > > > 
 > > > time ./testlog32
 > > > 6.960u 0.004s 0:06.96 100.0%0+0k 0+0io 0pf+0w
 > >
 > >You have weird hardware.
 > >
 > >[EMAIL PROTECTED] ~]$ time ./testlog64
 > >
 > >real0m7.330s
 > >user0m7.328s
 > >sys 0m0.004s
 > >[EMAIL PROTECTED] ~]$ time ./testlog32
 > >
 > >real0m7.538s
 > >user0m7.528s
 > >sys 0m0.000s
 > 
 > So it's not a big brand box, but I didn't think of it as totally obscure 
 > either.

Mm yes, but the fact that I can't duplicate your problem suggests that
it might be localized to a particular CPU design of a perticular
library build.  It's hard to be sure, but it's not a generic gcc
problem.

Andrew.

Re: Ada subtypes and base types

[Laurent GUERBY]

On Mon, 2006-03-13 at 15:31 -0700, Jeffrey A Law wrote:
> On Mon, 2006-02-27 at 20:08 +0100, Waldek Hebisch wrote:
> 
> > What do you mean by "abuse"?  TYPE_MAX_VALUE means maximal value
> > allowed by given type.
> As long as you're *absolutely* clear that  a variable with a
> restricted range can never hold a value outside that the
> restricted range in a conforming program, then I'll back off
> the "abuse" label and merely call it pointless :-)

Variables in a non erroneous Ada program all have their value between
their type bounds from the optimizer perspective (the special 'valid
case put aside).

The Ada FE and RTS are currently compiled with compiler checks off
so of course programming errors are magnified by VRP (as seen in one
case already).

> The scheme you're using "promoting" to a base type before all
> arithmetic creates lots of useless type conversions and means
> that the optimizers can't utilize TYPE_MIN_VALUE/TYPE_MAX_VALUE
> anyway.  ie, you don't gain anything over keeping that knowledge
> in the front-end.

It just means that the optimizer has to be smarter than it currently is,
may be one day it will be, so yes front-end should pass their knowledge.

There's no reason in language design (unless you want to cripple
performance and usability) not to do what Ada and Pascal are doing:
intermediate values are kept in an implementation defined
"base" type. If you have a reason to do otherwise, please
let us know.

Anyway, I'm pretty sure that it's possible to find cases where
the current optimizer thanks to VRP improvements is able to remove
checks that the Ada front-end wasn't able to remove, and check removal
is usually a pretty important optimization in Ada and Pascal (of course
mostly useless in C :).

Laurent

new cctools, 590.36 for Darwin

[Geoffrey Keating]

I've uploaded cctools-590.36 to



and the source for it as



Their md5 checksums are:

MD5 (cctools-590.36.dmg) = 36232fb9525ef5101ed9089db7083d4d
MD5 (cctools-590.36.tar.bz2) = e90cf2e459c431b65a8989f79e4d625c

I've built them Universal on 10.4.5.  I think they should work back  
to 10.3, at least 10.3.9.


This is a pre-release version of cctools and I know of a few bugs in  
it (and it hasn't been tested very heavily yet) but it works fine for  
building and testing GCC.

smime.p7s
Description: S/MIME cryptographic signature

Re: Ada subtypes and base types

[Robert Dewar]

Laurent GUERBY wrote:

On Mon, 2006-03-13 at 15:31 -0700, Jeffrey A Law wrote:

On Mon, 2006-02-27 at 20:08 +0100, Waldek Hebisch wrote:


What do you mean by "abuse"?  TYPE_MAX_VALUE means maximal value
allowed by given type.

As long as you're *absolutely* clear that  a variable with a
restricted range can never hold a value outside that the
restricted range in a conforming program, then I'll back off
the "abuse" label and merely call it pointless :-)


Variables in a non erroneous Ada program all have their value between
their type bounds from the optimizer perspective (the special 'valid
case put aside).


Not quite right. If you have an uninitialized variable, the value is
invalid and may be out of bounds, but this is a bounded error situation,
not an erroneous program. So the possible effects are definitely NOT
unbounded, and the use of such values cannot turn a program erroneous.
(that's an Ada 95 change, this used to be erroneous in Ada 83).

changing the SPARC default

[Alexey Starovoytov]

Hi,

The default architecture for GCC SPARC is V7.
What do gcc sparc developers think about changing it to V8PLUS?

Few things to consider:
 - v7 is legacy
. used in old Sun's sun4c systems
. 32-bit only
. no integer mul/div insns

 - first 64-bit SPARC was made in 1995
. I guess it would be a valid assumption that there are
  not so many 32-bit SPARC chips left

 - there is a big performance gap between v7 and v8plus
. I guess no need to explain the importance of 64-bit registers


1st choice (the best):
 - change the default for all sparc platforms

2nd:
 - change the default for Solaris 7+ and linux

3rd (100% safe):
 - change the default for Solaris 10+

Also 64-bit Linux doesn't have to mean 64-bit (v9) gcc compiler,
so at the same time it would be good to change it to v8plus as well.

All that changes can be done by easily tweaking gcc/config.gcc
by adding with_cpu=v9

Alexey.

Re: aapcs apcs-gnu

[trimarchi]

Quoting Paul Brook <[EMAIL PROTECTED]>:


On Wednesday 15 March 2006 05:20, [EMAIL PROTECTED] wrote:

Hi all,
what is the difference beetween this abi?
The standard arm procedure call is the first one. What is introduced in the
apcs-gnu? Is there some documentation about the last one?


"apcs-gnu" is the pre-EABI calling convention. I believe it's based mainly on
the RISCiX calling convention. There are many different variants of the APCS
but AFAIK none of them particularly well documented. The best documentation
for apcs-gnu is probably "whatever gcc generates".

"aapcs" is defined in the ABi for the Arm Architecture (aka. EABI)
http://www.arm.com/products/DevTools/ABI.html

Paul



Ok,
but the default is to use the apcs-gnu instend of aapcs. Is it right? For
compatibility problem is usefull to forse the abi to the standard.

Regards
Michael



This message was sent using IMP, the Internet Messaging Program.

Re: changing the SPARC default

[Eric Botcazou]

> 1st choice (the best):
>  - change the default for all sparc platforms
>
> 2nd:
>  - change the default for Solaris 7+ and linux
>
> 3rd (100% safe):
>  - change the default for Solaris 10+
>
> Also 64-bit Linux doesn't have to mean 64-bit (v9) gcc compiler,
> so at the same time it would be good to change it to v8plus as well.
>
> All that changes can be done by easily tweaking gcc/config.gcc
> by adding with_cpu=v9

I'm all for it, at least for Solaris 7+.

-- 
Eric Botcazou

Re: Ada subtypes and base types

[Geert Bosch]

On Mar 16, 2006, at 05:09, Robert Dewar wrote:

Not quite right. If you have an uninitialized variable, the value is
invalid and may be out of bounds, but this is a bounded error  
situation,

not an erroneous program. So the possible effects are definitely NOT
unbounded, and the use of such values cannot turn a program erroneous.
(that's an Ada 95 change, this used to be erroneous in Ada 83).


Actually, that's a good point and raises some potential issues:
if we're never establish the invariant that a value of a type is in
range, we can only use the base range for variables that might be
used uninitialized. Any read of such a variable would then involve
a range check.

  package Uninitialized is
 N : Positive;
  end Uninitialized;

  with Uninitialized;
  procedure Test is
 for J in 1 .. Uninitialized.N loop
...
 end loop;
  end Test;

In this case, GCC might replace the loop with
   declare
  J : Integer := 1;
   begin
  while J /= Uninitialized.N loop
 ...
 J := J + 1;
  end loop;
   end;

which would be incorrect for N = 0.

  -Geert

Re: changing the SPARC default

[James A. Morrison]

Alexey Starovoytov <[EMAIL PROTECTED]> writes:

> Hi,
>
> The default architecture for GCC SPARC is V7.
> What do gcc sparc developers think about changing it to V8PLUS?
>
> Few things to consider:
>  - v7 is legacy
> . used in old Sun's sun4c systems
> . 32-bit only
> . no integer mul/div insns
>
>  - first 64-bit SPARC was made in 1995
> . I guess it would be a valid assumption that there are
>   not so many 32-bit SPARC chips left
>
>  - there is a big performance gap between v7 and v8plus
> . I guess no need to explain the importance of 64-bit registers
>
>
> 1st choice (the best):
>  - change the default for all sparc platforms
>
> 2nd:
>  - change the default for Solaris 7+ and linux
>
> 3rd (100% safe):
>  - change the default for Solaris 10+
>
> Also 64-bit Linux doesn't have to mean 64-bit (v9) gcc compiler,
> so at the same time it would be good to change it to v8plus as well.
>
> All that changes can be done by easily tweaking gcc/config.gcc
> by adding with_cpu=v9
>
> Alexey.

 Debian has been running with V8PLUS as the default since the sarge release
cycles started.  I.e. years.


-- 
Thanks,
Jim

http://www.csclub.uwaterloo.ca/~ja2morri/
http://phython.blogspot.com
http://open.nit.ca/wiki/?page=jim