Hello, all-
I've written a relatively long-running search program (started it yesterday afternoon, and it was still chugging away when I left the house this morning). I can leave it going indefinitely on my desktop PC, but I noticed in the task manager that the Squeak process was using exactly 50% of available CPU. This remains the same regardless of whether the VM preference for "reduce CPU usage" is checked. In the image itself, the "higherPerformance" preference is checked.
(This is under Squeak 3.9 on a WinXP machine. If I remember correctly, the CPU itself is one of the vintage 2005 hyperthreading Intel chips.)
Is there a way to tell the VM to hog the CPU? Failing that, would there be any significant reason *not* to start a second Squeak session to run another such job at the same time? (=
Thanks, -Sam Livingston-Gray comp.sci. senior, Portland State University
Check if you have a CPU with Hyperthreading. On Windows, that behaves like a dual-core machine, so 50% CPU is simply the max you get for any single thread.
Cheers, - Andreas
Sam Livingston-Gray wrote:
Hello, all-
I've written a relatively long-running search program (started it yesterday afternoon, and it was still chugging away when I left the house this morning). I can leave it going indefinitely on my desktop PC, but I noticed in the task manager that the Squeak process was using exactly 50% of available CPU. This remains the same regardless of whether the VM preference for "reduce CPU usage" is checked. In the image itself, the "higherPerformance" preference is checked.
(This is under Squeak 3.9 on a WinXP machine. If I remember correctly, the CPU itself is one of the vintage 2005 hyperthreading Intel chips.)
Is there a way to tell the VM to hog the CPU? Failing that, would there be any significant reason *not* to start a second Squeak session to run another such job at the same time? (=
Thanks, -Sam Livingston-Gray comp.sci. senior, Portland State University
I wondered if that might be the case. Thanks! -Sam
On May 4, 2007, at 10:42 AM, Andreas Raab wrote:
Check if you have a CPU with Hyperthreading. On Windows, that behaves like a dual-core machine, so 50% CPU is simply the max you get for any single thread.
Cheers,
- Andreas
Sam Livingston-Gray wrote:
Hello, all- I've written a relatively long-running search program (started it yesterday afternoon, and it was still chugging away when I left the house this morning). I can leave it going indefinitely on my desktop PC, but I noticed in the task manager that the Squeak process was using exactly 50% of available CPU. This remains the same regardless of whether the VM preference for "reduce CPU usage" is checked. In the image itself, the "higherPerformance" preference is checked. (This is under Squeak 3.9 on a WinXP machine. If I remember correctly, the CPU itself is one of the vintage 2005 hyperthreading Intel chips.) Is there a way to tell the VM to hog the CPU? Failing that, would there be any significant reason *not* to start a second Squeak session to run another such job at the same time? (= Thanks, -Sam Livingston-Gray comp.sci. senior, Portland State University
On Fri, 04 May 2007 10:42:32 -0700, Andreas Raab andreas.raab@gmx.de wrote:
Check if you have a CPU with Hyperthreading. On Windows, that behaves like a dual-core machine, so 50% CPU is simply the max you get for any single thread.
Most hyperthreading machines can have hyperthreading turned off as a BIOS setting - if you want a single Squeak image to run at twice the speed, you can just turn off Hyperthreading. You may notice the rest of your system getting sluggish if Squeak is running full-bore though...
Later, Jon
-------------------------------------------------------------- Jon Hylands Jon@huv.com http://www.huv.com/jon
Project: Micro Raptor (Small Biped Velociraptor Robot) http://www.huv.com/blog
On 04/05/07, Jon Hylands jon@huv.com wrote:
Most hyperthreading machines can have hyperthreading turned off as a BIOS setting - if you want a single Squeak image to run at twice the speed, you can just turn off Hyperthreading.
Windows would probably report 100% CPU usage, but I doubt the CPU would go twice as fast... HT means a single core can run instructions from two threads simultaneously, not that the transistors are partitioned into two half-cores. Surely all computing units are shared among threads?
On Fri, 4 May 2007 20:35:21 +0200, "Damien Pollet" damien.pollet@gmail.com wrote:
Windows would probably report 100% CPU usage, but I doubt the CPU would go twice as fast... HT means a single core can run instructions from two threads simultaneously, not that the transistors are partitioned into two half-cores. Surely all computing units are shared among threads?
No, with hyperthreading, the BIOS basically builds two virtual processors, and each one gets half of the CPU speed.
Later, Jon
-------------------------------------------------------------- Jon Hylands Jon@huv.com http://www.huv.com/jon
Project: Micro Raptor (Small Biped Velociraptor Robot) http://www.huv.com/blog
On May 4, 2007, at 14:41 , Jon Hylands wrote:
On Fri, 4 May 2007 20:35:21 +0200, "Damien Pollet" damien.pollet@gmail.com wrote:
Windows would probably report 100% CPU usage, but I doubt the CPU would go twice as fast... HT means a single core can run instructions from two threads simultaneously, not that the transistors are partitioned into two half-cores. Surely all computing units are shared among threads?
No, with hyperthreading, the BIOS basically builds two virtual processors, and each one gets half of the CPU speed.
I'm pretty sure this is not true, but more like what Damien wrote. Basically all that HT does is having a second register set so you can hold the state of two processes in the CPU at the same time. Execution units are shared. Since one process seldomly utilizes all execution units (due to "pipeline bubbles") the other process can use the free units. This simply enhances throughput, but it's not like in one process you only ever get half the speed.
- Bert -
On Fri, 4 May 2007 15:58:40 -0400, Bert Freudenberg bert@freudenbergs.de wrote:
I'm pretty sure this is not true, but more like what Damien wrote. Basically all that HT does is having a second register set so you can hold the state of two processes in the CPU at the same time. Execution units are shared. Since one process seldomly utilizes all execution units (due to "pipeline bubbles") the other process can use the free units. This simply enhances throughput, but it's not like in one process you only ever get half the speed.
Okay, well perhaps I misunderstood. I know a couple years ago we did a bunch of research into this, because we were running 4-processor servers with hyperthreading in each processor, and we were running 4 VisualAge server images on each machine. By turning off Hyperthreading, we got a very significant speed increase (not quite double, but close). With hyperthreading on, we only ended up ever using 50% of the total CPU available.
Later, Jon
-------------------------------------------------------------- Jon Hylands Jon@huv.com http://www.huv.com/jon
Project: Micro Raptor (Small Biped Velociraptor Robot) http://www.huv.com/blog
On May 4, 2007, at 16:20 , Jon Hylands wrote:
On Fri, 4 May 2007 15:58:40 -0400, Bert Freudenberg bert@freudenbergs.de wrote:
I'm pretty sure this is not true, but more like what Damien wrote. Basically all that HT does is having a second register set so you can hold the state of two processes in the CPU at the same time. Execution units are shared. Since one process seldomly utilizes all execution units (due to "pipeline bubbles") the other process can use the free units. This simply enhances throughput, but it's not like in one process you only ever get half the speed.
Okay, well perhaps I misunderstood. I know a couple years ago we did a bunch of research into this, because we were running 4-processor servers with hyperthreading in each processor, and we were running 4 VisualAge server images on each machine. By turning off Hyperthreading, we got a very significant speed increase (not quite double, but close). With hyperthreading on, we only ended up ever using 50% of the total CPU available.
Well, then I'd take your experience over Intel's marketing I guess ;)
The idea actually is rather old, IIRC the Alto was 16-ways "hyperthreaded".
- Bert -
On 4-May-07, at 1:29 PM, Bert Freudenberg wrote:
The idea actually is rather old, IIRC the Alto was 16-ways "hyperthreaded".
Even systems could be 'hyperthreaded' in a sense. The old amiga took advantage of the fairly dismal 68K architecture that meant the cpu could only access the memory bus every fourth cycle to allow the coprocessors to get their work done at almost no performance cost.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oxymorons: Good grief
The TX-2 was one of the first computers to have quite a few program counters (I think over 20) and zero-overhead taskswitching according to various signals, including I/O ones.
Cheers,
Alan
At 01:29 PM 5/4/2007, Bert Freudenberg wrote:
On May 4, 2007, at 16:20 , Jon Hylands wrote:
On Fri, 4 May 2007 15:58:40 -0400, Bert Freudenberg bert@freudenbergs.de wrote:
I'm pretty sure this is not true, but more like what Damien wrote. Basically all that HT does is having a second register set so you can hold the state of two processes in the CPU at the same time. Execution units are shared. Since one process seldomly utilizes all execution units (due to "pipeline bubbles") the other process can use the free units. This simply enhances throughput, but it's not like in one process you only ever get half the speed.
Okay, well perhaps I misunderstood. I know a couple years ago we did a bunch of research into this, because we were running 4-processor servers with hyperthreading in each processor, and we were running 4 VisualAge server images on each machine. By turning off Hyperthreading, we got a very significant speed increase (not quite double, but close). With hyperthreading on, we only ended up ever using 50% of the total CPU available.
Well, then I'd take your experience over Intel's marketing I guess ;)
The idea actually is rather old, IIRC the Alto was 16-ways "hyperthreaded".
- Bert -
Don't think there is a hog switch, but there is no reason not to start another Squeak.
On 5/4/07, Sam Livingston-Gray sam@timestream.net wrote:
Hello, all-
I've written a relatively long-running search program (started it yesterday afternoon, and it was still chugging away when I left the house this morning). I can leave it going indefinitely on my desktop PC, but I noticed in the task manager that the Squeak process was using exactly 50% of available CPU. This remains the same regardless of whether the VM preference for "reduce CPU usage" is checked. In the image itself, the "higherPerformance" preference is checked.
(This is under Squeak 3.9 on a WinXP machine. If I remember correctly, the CPU itself is one of the vintage 2005 hyperthreading Intel chips.)
Is there a way to tell the VM to hog the CPU? Failing that, would there be any significant reason *not* to start a second Squeak session to run another such job at the same time? (=
Thanks, -Sam Livingston-Gray comp.sci. senior, Portland State University
squeak-dev@lists.squeakfoundation.org
-
Alan Kay -
Andreas Raab -
Bert Freudenberg -
Damien Pollet -
David Mitchell -
Jon Hylands -
Sam Livingston-Gray -
tim Rowledge