On Fri, Jan 30, 2009 at 11:20 AM, Darryl Gove <darryl.g...@sun.com> wrote: > Hi, > > 64-big gives you a larger address space. The downside of this is that > pointers and longs go from 32-bits to 64-bits. This results in a slight > drop in performance. > > So in general you should probably expect a 64-bit application to run > slightly slower than the same application compiled 32-bit. > > On x86, the situation is slightly different. x64 gives you more > registers and an improved calling convention. This means that the > application runs faster, so long as these performance gains are not lost > by the increase in memory footprint (from the pointers and longs > increasing in size). > > If you're interested in seeing where the time is going in your > application, I'd suggest trying the Performance Analyzer in Sun Studio. > > Darryl. > > Elad Lahav wrote: >> I wrote a simple benchmark that takes a 1 GB file and encrypts it in >> parallel using >> libgcrypt. On an 8-core T1000, using 32 threads, the benchmark completed in >> ~45 seconds >> (after warming the file cache, of course). >> I then recompiled everything (libgcrypt and the application) in 64 bits, and >> was surprised >> to notice no improvement. While I realise that the main purpose of 64 bit >> systems is to >> increase the amount of addressable memory, I thought that, on a >> number-crunching >> application such as this benchmark, there would be an advantage to using >> bigger integers >> that fit into the actual size of the registers. Is there any validity to >> this assumption? >> >> System information: >> >> uname -a: >> SunOS foxtrot 5.11 snv_104 sun4v sparc SUNW,Sun-Fire-T1000 >> >> cc -V: >> cc: Sun C 5.9 SunOS_sparc 2007/05/03 >> >> Thanks, >> --Elad >> >> P.S., >> cpustat/cputrack do not work for me in this release. It worked with Solaris >> 10. Is this a >> known issue? >> _______________________________________________ >> perf-discuss mailing list >> perf-discuss@opensolaris.org > > -- > Darryl Gove > Compiler Performance Engineering > Blog: http://blogs.sun.com/d/ > Book: http://www.sun.com/books/catalog/solaris_app_programming.xml > _______________________________________________ > perf-discuss mailing list > perf-discuss@opensolaris.org >
Just to state what might be obvious (but then again maybe not), it sounds like the original expectation was that in 64-bit mode, the 64-bit integers would be used to reduce the number of operations needed for a given input size. However, depending on how the libgcrypt code is written, this may or may not happen. IIRC, on Solaris (at least), in 32-bit mode, 'int', 'long', and pointer types are 32 bits (though you can still use 64 bit integers if you like), in 64-bit mode, the only ones that change are 'long' and pointer types, so if all the code uses '[unsigned] int' for all their types, all the code will still be using 32-bit integers (thus no possible difference if such a thing would have an impact). _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
