Challenges of HyperThreading && 64-bit

[voidinit]

I haven't really been keeping up with all the hype and hoopla going on about Intel HyperThreading and 64 bit microprocessors. I've cocooned myself inside of the J2EE and will not leave until I am a persistence master. However, I have a few points to ponder concerning these emerging technologies..

Just to let you all know, I'm not a Bachelor's of anything and I never even stepped foot into a CS classroom or lab. I'm self-taught, so I missed all theory and was left with only the HomeDepot do-it-yourself guide and a roll of duct tape. I could be way out in left field here.

Now, if you beleive all the hype, Hyperthreading allows system threading libs like pthreads to execute instructions on two threads simultaneously? How is this different from SMP? I guess the one big difference would be the fact that there is only one floating point unit, but how does this effect threaded applications? It doesn't right?

We also read all the hype about OSes capable of running on 64bit architectures, and these OSes and hardware vendors are just waiting for the applications themselves to be "re-coded" for the 64bit microprocessor, or to be "re-coded" to take full advantage of hyperthreading. How much of these applications need to be "re-coded"? I mean if I have 27,000 lines of c++ then I have 27,000 lines of c++. Shouldn't the compilation of that code be the real determining factor in wether the application can handle 64bit architecture or take full advantage of hyperthreads?

I mean, if posix thread libraries were updated to take full advantage of hyperthreading, and gcc were updated to include a 64bit target of some sort could I just compile, say, MySQL: with these options and run it on a 64bit hyperthreaded machine?

It's obvious that some changes would need to be made in some applications to make performance advantages worthwhile. Less conservative memory management, more agressive threading, etc. But all in all, how much work would it take to get an application like MySQL 64bit and/or HyperThreading ready?

[Stuka]

There actually isn't (too) much hype in the hyperthreading claims - the system is actually capable of treating a single processor like 2 separate processors, which, as you said, is much like SMP (with all the issues involved there too...). As for the 64-bit stuff, again you're pretty much right on. At the C++ level, there's not much you can do short of using a 64-bit compiler (gcc already has this, as there's a 64-bit version of the linux kernel out already). Of course, KNOWING that you can use 64 bits does make a difference for lower-level coders, so it CAN make a difference in certain places.

[voidinit]

So really it's up to the compilers and maybe the inline assembly guy (who usually sit's in the back of the room and eats chalk) to optimize applications for 64bit processors!

Therefore I guess almost all Open Source applications are already ready to be "ported" to 64bits. That means the news and articles that say "vendors should really be concerned about re-coding their applications for 64bit microprocessors" are actually saying "closed-source vendors should be concerned." Since they are the only ones who can recompile thier source for a 64bit target.

[bwkaz]

Originally posted by voidinit
How is this different from SMP? It's not different from SMP, which is why I like to emphasize the "hype" part of hyperthreading. :D

I guess the one big difference would be the fact that there is only one floating point unit, but how does this effect threaded applications? It doesn't right? It does if the program does any floating point math at all. If it does, then that code will only run in single-threaded mode instead of two threads at a time like full SMP would give you.

Shouldn't the compilation of that code be the real determining factor in wether the application can handle 64bit architecture or take full advantage of hyperthreads? Not if the programmer has assumed that "long"s are exactly 32 bits, all the time. The C standard only guarantees that a long is at least 32 bits. On a lot of 64-bit processors, longs are actually 64 bits.

Ints are usually still 32, but they might be as small as 16. This is the other part of possibly having to re-code -- on a 64 bit chip, 32-bit operations may be slower than 64-bit operations.

if posix thread libraries were updated to take full advantage of hyperthreading, They wouldn't be changed. Hyperthreading P4's work right now, out of the box, on a normal linuxthreads glibc. /proc/cpuinfo lists two CPUs, just like on an SMP system.

This might depend on how you have your BIOS set up, though -- Intel's hyperthreading CPUs seem to be able to be configured to show up as either one or two depending on the BIOS. If you have them configured to show up as 2, then any normal SMP threading library will still work.

and gcc were updated to include a 64bit target of some sort Oh, you mean like what you get when you add -m64 to the gcc command line? ;)

[voidinit]

Originally posted by bwkaz

Oh, you mean like what you get when you add -m64 to the gcc command line? ;)

Yeah, kind of like that, but a little more purple with a hint of minty freshness.


No, really. Thanks a lot for clearing up some of the myth and mystery for me.