CONGRATULATIONS
NL59056
on making
FIVE MILLION POINTS!!!!!


Way to go NL59056

I am 5 points short of 400,000, oh well, be there by the midday update

I've seen that FAQ but the real windows problem is not a buggy report
of CPU usage but inefficient use of HTT technology with most versions.
Only XP (Home and Professional) make use of the HTT technology, but
not very well.

HTT is not as simple as you put it, many ressources of the CPU are
replicated, partitioned, and shared. Multiple threads DO benefit from
the technology if the OS and BIOS support it (and it is enabled). The
benefit a thread sees really doesn't depend on how "efficiently programmed"
that thread is (the CPU couldn't care less if it executes efficient or
inefficient code) -- what does matter is how innefficiently the Billy-OS
keeps the CPU busy already while actually doing close to nothing (for
the user). Check the CPU load of an idle Linux system and check the
CPU load of an idle Windows system and you know what I mean.



That's what I was asking for. A client that has only ONE running thread
that does all the work (the Rosetta thread) will not make very much use
of HTT (HTT in this case only helps to lower the CPU load generated by
the OS) or of DUAL CORE or real dual CPU boards. The client must be a
multi-threaded application (split the work into independent jobs that can
run simultaneously) OR the client must be able to be started more than
once. VMware allows the latter and on a HTT system you see 140-160%
performance in two virtual Windows machines compared to only one
(there was a paper on this doing real life benchmarks -- will post the
link when back in office).

I will do it with FOUR virtual machines as my workstation has two CPUs
which are both HTT enabled. The point output will prove my claim (I hope).


Best, Stefan.

Uh-oh, Graham, shouldn't we count only MOT points for HoF banners??

And: did you notice the gust of wind recently?? That was me

"Shooobidooo, shooobidooo -- now I crunched our graphics guru..."

13 hours ago:

Graham 368.929 for MOT
Esteban69 368.644 for MOT

Currently:

Esteban69 372.000+ for MOT
Graham 370.000+ for MOT??


Best, Stefan.

Do you really think that WCG crunching is going to generate threads using such wildly differing resource needs, enabling those unused portions of the chip to come into play? I tend to think that WCG CPU-use is probably far closer to benchmark usage than real-world usage, and yet most benchmarks other than RAW CPU tests tend to run a variety of calulation types in order to fully stress the system. I don't see the WCG calcs being quite so varied.

Where that helps is in running multiple types of applications with multiple types of needs. The WCG tends to pretty much run one type of calculation... mostly floating-point hard math. While the HyperThreading will allow other, background applications to squeeze a bit more performance out without impacting the WCG CPU-time as much (one big benefit of running the current client on dual CPU or dual core CPUs), which should indeed bring a performance boost, I strongly suspect the boost will be far closer to the lower end of your estimate than the higher end (i.e., closer to your 18% figure).

That said, the real world varies quite a bit. On a computer that is actually used, meaning more than a dedicated crunching slave, HT could bring about much higher benefits, as it brings it's benefits to bear on standard office tasks, allowing the WCG client much more CPU time than it otherwise would have had. So if someone actually uses their computer as a workstation, HT could indeed cause a nice spike in their scores. But for a dedicated crunching station that is not sharing it's CPU usage with that many other tasks, I stongly believe the boost won't be above 20%. Of course, a 20% boost is pretty nice. :)

As for the "efficiency in programming" I referred to in my other post, I was not meaning simply elegant code vs. sloppy code (although obviously the former will be better), I meant more how well the devlopers manage to spread the load of the various threads in a multi-threaded app. If the developers only manage to break it down into one mega-thread and several smaller house-keeping threads, it can still claim to be "multi-threaded" but only gain a modest amount of efficiency. This happens quite a bit in the software world, especially with regard to marketing hype. I have hope that the developers will be able to deliver a better product than that, but there's no way to know for sure at this point.

As there is no way to know ANYTHING for sure until we actually see and test the final release, further debate is pointless, but I guess time will prove one or the other of us right. ;)