On Nov 26, 2007, at 4:25 PM, Bryan O'Neal wrote:
> Time to express some ignorance here and seek some answers.
> TTBOMK -
> 1) I can run 32 bit code on a 64 bit machine with a 64 bit OS. I can
> never run an app of greater bitwidth then the OS or the processors
> bitwidth (note the OR, it is not an AND)
Basically you are correct. 64-bit Windows seems to have a lot of
issues with 32-bit applications. Some 64-bit Linux distros want you to
install all your 32-bit apps in a chroot jail. 32-bit plug-in won't
run in 64-bit browsers without a wrapper.
>
> 2) You talk about 64 bit being slower and more prone to faulting
> because
> the integers are twice as large. I can program a 32bit application
> using
> 1 bit, 8 bit, 16, or 32 bit variables in Fortran, Java, and VB, so why
> do you assume that if I intend to store a variable with 240 logical
> possibilities or perform calculations on this variable I am going to
> run
> for double precision 64bit variable just because I am programming
> for a
> 64 bit environment? I only took one C class, but I remember multiple
> variable sizes in it as well. True, if I compile in a 32bit world I
> have to recompile for 64, but I would have to recompile for PPC or
> Sparc, so what's the big deal? After a while everyone will have their
> stuff precompiled for 64 bit. Now it is true that some vendors like
> Adobe don't have their stuff available in 64 bit yet, but it was ages
> before they made it available in 32 bit. There is never any love from
> them.
The biggest issue is that all your pointers are twice as big. The
next issue is that while it was possible to never use int and always
use something like int32 and define that to be int in a header file,
I've only seen one place where everybody coded this way consistently.
So as a practical matter, the ints are going to double in size too.
>
> 3) The advantages are in the lager datapath and in the number of
> registers you can play with. Everyone always complains that the next
> newest OS is slower then the last, and it is true, my windows 98 was a
> dog compared to windows 3.1 ;) Is some of this because people are
> getting used to 64 bit programming, are they perhaps not being
> efficient
> with their port? Perhaps, but the fact that some one is willing to do
> it at all for us is great.
In the Intel world, the data path isn't wider between i386 and
ix86-64. There are more registers, but compilers haven't really been
optimized to use them yet. But even when they are, one cache miss will
wipe out the gains from running hundreds of instructions with more
registers.
>
> 4) I use 32 bit because I only have two needs for 64 bit; DB's
> moving a
> lot of data and games. Since I don't have my next big DB running yet
> and I haven't seen any good games requiring 64 bit, I run 32. But I
> don't hate the future just because I like to be a late adopter.
Well DB are the canonical example of applications that can really
benefit from 64 bits and games are the most cited example of the kind
of application that should never be 64-bits because the code is so
branchy and the long pointers increase misses. There was a time when
folks thought 64-bit and even 128-bit would be great for games because
of the advantages of wide arrays for graphics. But the emergence of
dedicated GPUs changed all that. The big numbers can live in the GPU.
>
>
> So, how much of this was wrong
They are all good questions/speculations. I do get the impression that
the pent up demand for 64-bits just isn't there the way it was for 32-
bits. When 32-bits came out there were all these kludges to get more
memory: expanded memory, extended memory, unreal mode - you may
remember. Now few people feel the need for more than 4GB.
--
Vegetarians eat Vegetables, Humanitarians frighten me
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
(text/plain)