Thorsten Froehlich <tho### [at] trfde> wrote:
> Yes, on some platforms that habe been 64 bit "for a long time" it tends to
> be not well supported anymore.  Other plaforms that had a vital 32 bit
> predecessor such as Sparc at least did support it (haven't checked for years
> though).

  The UltraSparc processor can run processes in 32-bit or 64-bit mode
(in a similar way as Intel processors can run processes in 32-bit or 16-bit
mode). By default programs are compiled as 32-bit binaries by the Sun cc,
but can be compiled as 64-bit binaries with an architecture option. Gcc
can only compile 32-bit binaries.

  For some reason many people think that compiling a program as a 64-bit
binary would make it faster. That's not so, naturally. In fact, compiling
a program as 64-bit binary makes it slightly slower (this is most probably
because pointers and long integers are now 64 bits long instead of 32 bits,
and caches fill up faster). However, we are talking about only some percents
of slowdown.
  Even if the program uses the long long type (which is 64 bits regardless
of the compilation mode), compiling to a 64-bit binary makes it slightly
slower. Curiously gcc is really sloppy when optimizing long longs for Sparc.
A program which uses long longs a lot can be several times faster when
compiled with Sun cc than when compiled with gcc.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message