[geeks] Dual Core Rules: your bugs will run twice as fast

[Charles Shannon Hendrix]

Tue, 13 Feb 2007 @ 15:19 -0500, Phil Stracchino said:

> Charles Shannon Hendrix wrote:
> > I will say though, that I could use 64-bit Linux if I had to, while I found
> > 64-bit Windows impossible to live with.
> 
> That's an interesting comment.  Would you care to expand upon it?

64-bit Linux worked, with the exception of some code not being 64-bit
yet, including a few drivers. Everything I actually needed would work. I
gave up on getting some 32-bit applications working, although later on
I figured out how. I'm mostly just not willing right now as I only have
one machine for a desktop.  That limits my experiments quite a bit.

64-bit Windows would not run all of the software I needed to run Windows
for.  That alone was a show stopper.

Beyond that, I found it occasionally slower than 32-bit versions, and it
wasn't as stable.

Finally, some hardware never did work right, even though there were
64-bit drivers for it.

That pretty much killed it for me.

If I had more time and a free machine to play with, I'd probably be
willing to spend more time on 64-bit Linux and Windows, but I don't so I
had to do my testing quickly and get it over with.

I have a new machine now and would like to try both again. I'll probably
give 64-bit Kubuntu a try and see if they've worked out the major
issues, especially 32-bit compatibility.

I can't legally try 64-bit Windows any more, though I'd like to see if
drivers and other issues have improved. From what I read on various
forums, even Vista still has much the same issues, but I also know that
most of the people are idiots so I'd like to try again myself.

Regarding 32-bit compatibility:

Any 32-bit code that is dynamically loaded has to be run inside of a
32-bit process, which is a real pain.

For example, if you want 64-bit Java and Firefox, you can't run 32-bit
plugins like Flash.  You end up installing two browsers.

Another issue is that 64-bit Java is slow until the app has been loaded
for awhile, and the JIT has had time to generate native code. That means
that short-lived Java programs are faster with 32-bit Java. You have
to decide which is more important to you. I've read that Sun could fix
this, but they refuse.

Possible fix in the future:

There are a few people here and there who've figured out how to make
32-bit code run in a 64-bit process by using 64-bit wrappers. I think
what they do is run the 32-bit code in a separate process, and the
64-bit wrapper talks to it so the 64-bit host app thinks the code is
natively 64-bits.

For example a french team has a program called nspluginwrapper which is
supposed to run Acrobat, DejaVu, Flash, jpeg 2000, Mplayer, and
Realplayer in 64-bit browsers.

I don't know if there are similar projects for 64-bit Windows or not.

Ultimately however, we really just need for all code to make the move to
64-bit.

32-bit compatibility comes at a performance price if the code uses the
FPU, because 64-bit x86 mode disables the FPU, and it must be accessed
through a hardware hook.


-- 
shannon           | We are all of us in the gutter, some of us looking at the 
                  | stars.  
                  |         -- Oscar Wilde