Slashdot Mirror
Linux 2.6 And Hyper-Threading
David Peters writes "2CPU.com has posted an article on Hyper-Threading performance in Linux. They use Gentoo 1.4 and kernel 2.6.2 and run through several server-oriented benchmarks like Apache, MySQL and even Java server performance with Blackdown 1.4. The hardware they use in the tests is border-line ridiculous (3.2GHz Xeons, 3.2GHz P4 and P4 Prescott) and the results are actually quite interesting. It's a good read as he even takes the time to detail his system configuration all the way down to the CFLAGS used while compiling the software."
Has anybody run into a problem with Hyper-Threading and per-CPU licensing?
The hardware they use in the tests is border-line ridiculous
I'm typing this on a 3.0 GHz Pentium 4 that has hyperthreading. The entire system cost me $1200 to build just before Christmas - including 1GB of RAM, a Radeon 9800 Pro video card and a 120GB SATA hard drive. Dell and IBM sell 3GHz notebooks now for a similar price.
My point is that a 3.2GHz CPU is not ridiculous in an age where 2.66GHz processors are considered entry-level (FYI, Dell is currently selling a 2.66GHz desktop for $499).
What are you still running on? A 486?
Ok, Time to redo the benchmarks, Kernel 2.6.3 is out.
[joking]
Be nice when we see some nice Opteron benchmarks vs the new Xeons.
-
"But Calvin is no kind and loving god! He's one of the _old_ gods! He demands sacrifice!"
The first one performs semi-miracles on repetative build times where you aren't doing "incremental" builds. The second lets you distribute your compile to multiple build servers on the network (beware - there be deamons here)
Build times went from hours to minutes - it was great
I have mod points and I am not afraid to use them
Those sure are some interesting numbers. On the order of a 49% increase or 35% decrease in performance depending on the application. I always figured those high-GHz CPUs would be completely IO-bound. I guess this sometimes allows threads to run with what they've got in the on-chip cache.
Makes you wonder if a kernel could detect if it was helping or not and selectively enable it.
I did some informal testing between VC++ native and C# to .Net bytecode. I had a little loop calculating primes. The native C++ kept everything in registers, while the CLR made everything relative memory accesses to BP. I figured that would devastate performance, but on the Pentium 4, it was only 5% slower! It seems to have an L1 cache that's as fast as the registers. That will certainly make it easier on the compiler writers.
Sort of off topic, did anyone else see that article in MSDN about using .Net for serious number crunching? The author seemed to write the whole article as if he thought it was a good idea. Not that there wouldn't be some advantages to doing that (such as the possibility of tuning for the processor at runtime), but the one graph he showed comparing with native code had .Net running 50% to 33% slower!
OK, he cannot afford to buy a benchmark, but he has a trio of top of the line Intel systems to play with! WTF? Either he has a weird idea of money well spent, or someone has a lucrative agreement with the hardware vendors. I'm guessing the latter, and really wish I could write well enough to sucker them into sending me cool hardware to play with.
I'll live with my 2800+(2.133Ghz) AMD MP(only one for now, I'll upgrade when I need it) I'm running Seti, playing music, encoding DVD's and sometimes messing with the UT2004 demo and not even noticing it...
On another note, when do the PCI express test systems come out? I'd love to see some benchmarks on those as the pci performance for my secondary and tertiary video cards is below par. PCI express is supposed to allow multiple high speed video cards.
Anyway.
On Arrakis: early worm gets the bird. Magister mundi sum!
-mm kernels include fixes for the ht screwiness. Well, not fixes per se, but hacks that make the scheduler a bit smarter. Problem is, linux still sees a single HT CPU as two discrete CPUs, so there's a performance hit because of the way registers are handled.
My entire lab at school is filled with Dual 3.2GHz Xeons with Quadro fx 1000 cards. People have those types of machines... or 100 of them.
I'm guessing that the VolanoMark results is what happens when you have a lot of synchronization. When you go from one thread to 2 threads, it costs you a lot to set up the synchronization stuff. When you go from 2 to 4 threads performance increases again because the cost of synchronization will be less per thread of execution.
I was trying to impress anyone. I was just surprised. I've never attempted a first post before, so I don't follow the different types.
I posted my comment simply because I thought it was odd.
What comes first, finding a teacher or becoming a student?
What if they discovered they could shrink down an entire 8086 processor to Truly Ridiculous Proportions (that's a technical term) and pile like a thousand or a million of them into the space of a single modern day chip? Ok, since we're a 32-bit world now maybe we'd need to go to bunches of 386's instead. But the point remains--I wonder what kind of modifications to current software would have to be made to exploit this, or if it could all be done in hardware.
It'd be massively parallel computing. Like a human brain. Slow at methodical linear tasks like adding a list of numbers, fast at intuitive tasks like modding this post down to -1.
sev
but have you considered the following argument: shut up.