64-bit

[language_fan]

Mon, 19 Oct 2009 13:22:34 +0200, Fawzi Mohamed thusly wrote:
> On 2009-10-18 20:01:26 +0200, language_fan <foo at bar.com.invalid> said:
>> Sun, 18 Oct 2009 16:35:53 +0200, Fawzi Mohamed thusly wrote:
>> 
>>  Also note that cache size is heavily constrained and larger
>> binaries will fill it with less code. This alone can make the code a
>> lot slower on first generation and budget 2..4-core x86 machines with
>> smaller cache sizes.
> 
> cache usage is a real issue, but on the whole code is faster in 64 bit
> mode, at least in my experience

I believe in real world benchmarks more than in hollow words.

>> Main memory is expensive and you rarely can install more than 64 GB on
>> a PC style hardware. Many times you can even split a task into separate
>> 2..3 GB processes quite easily. So the immediate advantages of 64-bit
>> code are not that clear when you only need it to grow the processes
>> larger. On Linux, for instance, ordinary 64-bit desktop requires a lot
>> more memory than its 32-bit alternative. Why would you want to buy more
>> hardware to fix something that can be fixed with existing software?
>> 

You did not comment on this.. in desktop use cpu power rarely matters. 
But running out of memory is pretty common (think about laptops with 
limited amount of memory slots and expensive memory units).

>>> Anyway I also need 64 bit (computational chemistry, speed and memory
>>> hungry), and to that the only thing that I can say is D1 works very
>>> well with 64 bit.
>> 
>> That's one domain where 64 bits may give you an advantage. In normal
>> desktop applications there is often nothing in 64-bit code that can
>> improve anything. I am talking about firefox / winamp / mediaplayer /
>> photoshop / outlook / casual gaming use here.
> 
> not sure, see snow leopard...

That's a business decisions ffs. Not necessarily a technical one. Maybe 
they wanted to future proof their software by keeping the amount of 
binary formats at minimum.