> Thanks for the correction. I am not sure why anyone would want 32 bit longs on a 64 bit processor, unless there is a large code base out there that is lazy about using longs where ints would suffice.
It's mostly not to break the assumption that sizeof(long) == sizeof(void*) which is true for _most_ Unix software. Although it's getting less common nowadays due to portability issues with Windows (Win64 being L32P64).
As mansr already pointed out, Spec2k makes wide use of long where int (or properly sized stdints) should be used, which is one of the reasons why its benchmarks are getting better results than they should theoretically get.
I can discuss this more, and I'll probably do so, in a blog post with more detailed discussion on the cache issue.
Posted Jun 26, 2012 20:36 UTC (Tue) by butlerm (subscriber, #13312)
[Link]
>Spec2k makes wide use of long where int (or properly sized stdints) should be used
It sounds like Spec2k should be rewritten to use int32_t instead of int, and int64_t instead of long, in any places where this might make a significant difference.
Pettenò: Debunking x32 myths
Posted Jun 26, 2012 20:58 UTC (Tue) by Flameeyes (subscriber, #51238)
[Link]
Yes, too bad that it's a quite secretive and closed-source benchmark, which is my first problem with the benchmark's numbers — took quite a bit of investigative work to actually find somebody who could confirm my hunch about longs.
Pettenò: Debunking x32 myths
Posted Jun 27, 2012 3:11 UTC (Wed) by slashdot (guest, #22014)
[Link]