On 01/30/09 12:10 PM, Elad Lahav wrote: >> I think the point was that with 64-bit ints you might be able to use a >> different algorithm, or perhaps require fewer iterations and converge >> faster. > I guess that part of the answer is that you would be hard-pressed to > find code that preserves its 32-bit semantics when compiled as 64 bits, > unless the programmer had only used data types with fixed sizes (i.e., > no longs). If that is the case, and I understand you correctly, then the > compiler will do the right thing for 64-bit integers on a 64-bit > processor (e.g., use single 64 bit arithmetic operations rather than > split values and use two 32 bit operations), regardless of whether -m64 > was specified. Is this correct?
Yes, that's correct. Unless you restrict the compiler to using only those instructions in the V8 instruction set, the compiler will use the 64-bit instructions to handle 64-bit data - even on 32-bit applications. > > By the way, I did not mean my example to be taken literally. I believe > that on the UltraSPARC T1, even with the v9-optimised code, the run time > would still be dominated by load/store operations. I know, but I figured discussing the disassembly would make it clearer. In terms of T1 performance. Yes, the fundamental limit tends to be the number of instructions. You might find this an interesting read: http://developers.sun.com/solaris/articles/t1t2_perf_counter.html You may also find the corestat utility useful: http://cooltools.sunsource.net/corestat/ An interesting observation, is that if you take your original code, and constrain the data to be integer, then you could treat that integer data as long long, and compute two elements at the same time. Regards, Darryl. > > Thanks, > --Elad -- 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
