[opensuse] CPU: higher clock speed or more cores? and: ksysguard possible CPU usage bug?
Hi folks, I notice the trend in desktop CPUs is that clock speeds have been steady for some time at 2...4GHz obviously depending on price, while the number of cores is on the increase, current offerings running from one to eight cores. I always thought that more cores is good for doing lots of things simultaneously, but not necessarily for single CPU-intensive tasks, as these are often not able to run in multiple threads/cores at the same time. I'm obviously not an expert, so do correct me if I'm wrong. To check this, on a dual-core system, I tried looking at ksysguard (System Monitor), and as expected I see that a number of CPU-intensive tasks run up to 49% CPU usage (example: file compression with ark). Surprisingly, however, when I switch to the 'System Load' tab in ksysguard, the graph clearly shows CPU1 and CPU2 both running at or near maximum (100%), even though the CPU usage of all processes adds up to much less (say, 49% for ark, and not more than 10% for everything else). Two questions: 1) For typical desktop use, is it more sensible to buy a six-core 2,5GHz processor, or a dual-core 3,6GHz? In other words, should I prefer more cores, or higher clock speed? (I'm aware of the 'benchmark'-style comparisons around the Internet, but it's their ecological validity I'm curious about.) 2) Is what I see a possible bug in ksysguard, or is there something I'm not understanding here? Cheers! Haro -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thursday, January 12, 2012 03:27 PM Haro de Grauw wrote:
Hi folks,
I notice the trend in desktop CPUs is that clock speeds have been steady for some time at 2...4GHz obviously depending on price, while the number of cores is on the increase, current offerings running from one to eight cores. I always thought that more cores is good for doing lots of things simultaneously, but not necessarily for single CPU-intensive tasks, as these are often not able to run in multiple threads/cores at the same time. I'm obviously not an expert, so do correct me if I'm wrong.
To check this, on a dual-core system, I tried looking at ksysguard (System Monitor), and as expected I see that a number of CPU-intensive tasks run up to 49% CPU usage (example: file compression with ark). Surprisingly, however, when I switch to the 'System Load' tab in ksysguard, the graph clearly shows CPU1 and CPU2 both running at or near maximum (100%), even though the CPU usage of all processes adds up to much less (say, 49% for ark, and not more than 10% for everything else).
Two questions:
1) For typical desktop use, is it more sensible to buy a six-core 2,5GHz processor, or a dual-core 3,6GHz? In other words, should I prefer more cores, or higher clock speed? (I'm aware of the 'benchmark'-style comparisons around the Internet, but it's their ecological validity I'm curious about.)
2) Is what I see a possible bug in ksysguard, or is there something I'm not understanding here?
Cheers!
Haro
There are of course other forums which are focused on hardware performance, that would be your best source of information. IMO the question is really over-simplified. There are a number of inter-related issues to be considered, each of which has its own specifics. Here fwiw are a few generalizations: The first is your use model. A quick look at a cross-section of benchmarks will show how a processor performs differently under types of loads. So depending on the function being performed and how a particular application is designed, that may favor clock speed over cores or vice versa, or neither. Another consideration is the architecture of the processor. Beyond clock & cores there are factors such as L3 cache and the bandwidth of the memory controller. The RAM and the chipset can also be factors. And then yet again another consideration are other system components which may gate performance more than the cpu. Some obvious examples are gaming (GPU), database (storage), or the network (switch, etc.). There is the general rule that a clock >3GHz typically is only utilized in cpu intensive functions, e.g., video processing or financials. Additional cores are useful with multi-tasking, although only a second core doesn't buy all that much; IMO with today's cpu's a quad has better payback. But the biggest bump with cores comes from multi-threaded programs which are designed to utilize the cores. Still, when 3 of 6 cores are pegged at 100%, don't expect the other cores to be able to do much else because probably the memory controller and/or bus will be saturated. So in the end it all comes down to what you do with the machine, what you can afford, and how much homework you're willing to do. To that I'll just add that a much more powerful processor (and RAM) may be affordable if you architect and build your own machine; sometimes you can economize on other components, and you can re-use many components across several upgrades. I've done this with my workstation for years and I've spent less than buying replacement PC's while always having maximum performance. Re Ksysguard: The CPU% you see on the Process Table is the cumulative for the process across the cpu, so if 2 cores are being used at 25% it will show on the Table as 50%. The System Load sheet will show each CPU load separately. That said, there is load on the CPU which shows on the Load sheet but which does not show on the Process Table. I have no idea why; it is annoying. I imagine all of this is just being read from what is being written to /proc, so I don't know if the issue is with Ksysguard (although IIRC I've seen the same phenomena in htop & top) or the kernel or just the way that it is. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Haro de Grauw wrote:
I always thought that more cores is good for doing lots of things simultaneously, [snip]
Yup.
Two questions:
1) For typical desktop use, is it more sensible to buy a six-core 2,5GHz processor, or a dual-core 3,6GHz? In other words, should I prefer more cores, or higher clock speed?
I would go for the latter - for regular desktop use, even a single core is more than enough. -- Per Jessen, Zürich (3.1°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 1/13/2012 8:40 AM, Per Jessen wrote:
Haro de Grauw wrote:
I always thought that more cores is good for doing lots of things simultaneously, [snip]
Yup.
Two questions:
1) For typical desktop use, is it more sensible to buy a six-core 2,5GHz processor, or a dual-core 3,6GHz? In other words, should I prefer more cores, or higher clock speed?
I would go for the latter - for regular desktop use, even a single core is more than enough.
I disagree. For a user machine, as opposed to a server, 2-to-4 cores yield better responsiveness and apparent speed than a faster processor. Even for simple things, becauese Linux is very smart about farming out different tasks to multiple cores so that the whole workload flows more smoothly. Long compute operations will probably be tied to a single core. But screen refreshes need not wait for that, and realistically most users don't have long compute intensive tasks in their workload. Dual cores are here to stay. Two is better, 4 better yet, but beyond that I the benefits seem to fall off, at least with the workload I can muster. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Haro de Grauw wrote:
1) For typical desktop use, is it more sensible to buy a six-core 2,5GHz processor, or a dual-core 3,6GHz? In other words, should I prefer more cores, or higher clock speed?
My preferences for a gaming computer would be fewer, faster cores. For a desktop work, web, music, movies - everything but games on one machine, I would go with the more cores but still not go slower than 2.5 Ghz. I always have many things running at once when I am doing anything other than a game so more cores and a 64 bit OS are handy. For many games the performance can be limited by the processor speed and few (if any?) are written to use more than 2 cores anyway. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
John Andersen wrote:
On 1/13/2012 8:40 AM, Per Jessen wrote:
Haro de Grauw wrote:
I always thought that more cores is good for doing lots of things simultaneously, [snip]
Yup.
Two questions:
1) For typical desktop use, is it more sensible to buy a six-core 2,5GHz processor, or a dual-core 3,6GHz? In other words, should I prefer more cores, or higher clock speed?
I would go for the latter - for regular desktop use, even a single core is more than enough.
I disagree. For a user machine, as opposed to a server, 2-to-4 cores yield better responsiveness and apparent speed than a faster processor. Even for simple things, becauese Linux is very smart about farming out different tasks to multiple cores so that the whole workload flows more smoothly.
I challenge anyone to, in a double-blind test, notice any difference between 2 and 4 cores for a regular office/desktop workload. (no compilations, video editing, CAD/CAM, Mathematica, raytracing etc.) I have had a 4-core AMD as my main desktop for 2-3 years and I notice no difference when I work on elderly single-core machines in another building. The only place I do notice a difference is on my dual-core laptop with 3Gb, which can be unbearably slow at times :-( Today any modern machine will obviously come with a minimum of two cores, but if asked to choose for a regular workload, I would still opt for raw speed instead of parallelism - no system is stronger than the weakest link, in this case us. (humans). Having said all that, spend the money on memory, that's got way more potential to speed up your system than any GHz or extra cores. -- Per Jessen, Zürich (1.4°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
I always thought that more cores is good for doing lots of things simultaneously, [snip] Yup.
Two questions:
1) For typical desktop use, is it more sensible to buy a six-core 2,5GHz processor, or a dual-core 3,6GHz? In other words, should I prefer more cores, or higher clock speed? I would go for the latter - for regular desktop use, even a single core is more than enough. I disagree. For a user machine, as opposed to a server, 2-to-4 cores yield better responsiveness and apparent speed than a faster processor. Even for simple things, becauese Linux is very smart about farming out different tasks to multiple cores so that the whole workload flows more smoothly. I challenge anyone to, in a double-blind test, notice any difference between 2 and 4 cores for a regular office/desktop workload. (no compilations, video editing, CAD/CAM, Mathematica, raytracing etc.)
I have had a 4-core AMD as my main desktop for 2-3 years and I notice no difference when I work on elderly single-core machines in another building. The only place I do notice a difference is on my dual-core laptop with 3Gb, which can be unbearably slow at times :-(
Today any modern machine will obviously come with a minimum of two cores, but if asked to choose for a regular workload, I would still opt for raw speed instead of parallelism - no system is stronger than the weakest link, in this case us. (humans). Having said all that, spend the money on memory, that's got way more potential to speed up your system than any GHz or extra cores.
Thanks for the input everyone. One of the big benefits I noticed with multiple cores (versus single) is that if a process hangs on one core, the machine still responds. That only justifies the second core -- not the third, fourth, etc., where my experience is in line with what Per and tparker report i.e. little practical benefit from additional cores (>2). I was just intrigued by this because I remember how we hiked from the Pentium II 300MHz (1997) to the Pentium4 3.4GHz (2004) in less than a decade, but then with the transition to 64bit and multi-core systems the clock speed never really went up much higher. In time I trust software will catch up and learn how to make best use of the additional cores. Dennis, I certainly take on board your points on cache, FSB speed, etc. In the balance of things, and having read a few reviews and comparisons, AMD's FX4100 (4x3.6GHz) looks like a fair deal right now for €110. And yes, I also always buy components, rather than ready machines. For home use, anyway -- I can't beat Dell on assembly cost when it's for productive purposes! Thanks again everyone, have a good weekend. Haro -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Friday 13 January 2012, Haro de Grauw wrote:
Dennis, I certainly take on board your points on cache, FSB speed, etc. In the balance of things, and having read a few reviews and comparisons, AMD's FX4100 (4x3.6GHz) looks like a fair deal right now for €110.
You could also consider Intel's Dual Cores i3 or i5 in that price region. I'd expect them to be faster for a single thread. And they take only 65 Watt instead of 95. Less heat and noise. cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, Jan 13, 2012 at 23:20, Ruediger Meier
On Friday 13 January 2012, Haro de Grauw wrote:
Dennis, I certainly take on board your points on cache, FSB speed, etc. In the balance of things, and having read a few reviews and comparisons, AMD's FX4100 (4x3.6GHz) looks like a fair deal right now for €110.
You could also consider Intel's Dual Cores i3 or i5 in that price region. I'd expect them to be faster for a single thread. And they take only 65 Watt instead of 95. Less heat and noise.
Think very carefully before you go out and buy the FX4100. In ALL the tests I've seen so far, it has significantly underpreformed.... so much that the AMD dual cores beat it out in almost every test. Even overclocked by 1GHz, it still can't compare. C. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Friday, January 13, 2012 06:09 PM C wrote:
On Fri, Jan 13, 2012 at 23:20, Ruediger Meier
wrote: On Friday 13 January 2012, Haro de Grauw wrote:
Dennis, I certainly take on board your points on cache, FSB speed, etc. In the balance of things, and having read a few reviews and comparisons, AMD's FX4100 (4x3.6GHz) looks like a fair deal right now for €110.
You could also consider Intel's Dual Cores i3 or i5 in that price region. I'd expect them to be faster for a single thread. And they take only 65 Watt instead of 95. Less heat and noise.
Think very carefully before you go out and buy the FX4100. In ALL the tests I've seen so far, it has significantly underpreformed.... so much that the AMD dual cores beat it out in almost every test. Even overclocked by 1GHz, it still can't compare.
C.
There are some useful user reviews by experienced overclockers at newegg.com. What I gather is that overclocked it performs about on par with a mid-range Deneb. One reviewer who tests all the models puts it at ~75% clock comparison which fits the ~1GHz spread. Not surprising as it's a first generation Bulldozer, so it's value priced. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, Jan 13, 2012 at 6:09 PM, C
Think very carefully before you go out and buy the FX4100. In ALL the tests I've seen so far, it has significantly underpreformed.... so much that the AMD dual cores beat it out in almost every test. Even overclocked by 1GHz, it still can't compare.
The Bulldozer is suffering the same thing that the Pentium 4 did when it was released. The Pentium 3 had a 10 stage pipeline, whereas the Pentium 4 introduced a 20 stage pipeline. So, counting in mispredicted branches slowing it down, the 1.5Ghz P4 was basically comparable to a 1.0Ghz P3. The Pentium 4 had improved the pipeline's speed but it was slowed down due to having a longer pipeline. There was a similar issue with the Precott when it moved to 31 stages. However, there was improvements in Prescott that enabled it to be at parity with the Northwood at similar speeds. Look how much better the Pentium M(which was bascially a P3 with a P4 memory controller and a better pipeline) did vs the P4, with it's 12 stage pipeline. The Core2 went to 14. Well the Athlon64/K10 has a 12(or maybe 14) stage pipeline, Bulldozer has an 18 or 20(depending on where you read it) stage pipeline. So, we have a similar issue. AMD increased the stages, made them more efficient, and therefore Bulldozer has performance similar to(better on some things, worse on others) than the K10. However, Bulldozer is now positioned to have higher clock speeds in the future where K10 was starting to hit a wall. The Power6, with what looks like a 13stage pipeline managed 5Ghz. The Power7 has a deeper pipeline at a lower topend. So, basically, Bulldozer is meant to perform for the future. Hopefully, AMD did a better job with it than Intel did with the P4. I'm waiting on 128bit chips to come out. That's where things will go eventually for performance. Look at Intel's AVX - 256bit now with 512 & 1024 bit for the future. SSE was only 128bit(and kludged at 64bits till the Core2 thanks to the P3 design decisions). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 1/13/2012 10:55 PM, Larry Stotler wrote:
I'm waiting on 128bit chips to come out. That's where things will go eventually for performance.
I'm not convinced that will yield any real world performance except when moving large chunks of storage around. When manipulating big chunks of data larger registers help. Twice the data moved in the same number of clocks. But not all applications have that need, and lots of things work just fine with smaller registers. Even when you only want 16bits off the bus, you generally load 32 and discard half. The debate of running a 32bit vs 64bit version of OpenSuse on 64bit hardware is still not settled. I doubt it will be that much clearer when you are talking 128bit vs 64bit. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 14/01/12 20:45, John Andersen wrote:
On 1/13/2012 10:55 PM, Larry Stotler wrote:
I'm waiting on 128bit chips to come out. That's where things will go eventually for performance.
I'm not convinced that will yield any real world performance except when moving large chunks of storage around.
When manipulating big chunks of data larger registers help. Twice the data moved in the same number of clocks.
I would suspect that, living in the age of mobile/cloud computing, more and more of what the CPU does all day is either compress-decompress, or encrypt-unencrypt. In that sense, I sympathise with the idea of 128bit architecture. Although Intel and AMD are probably too busy clawing back the sub-5W handheld market from the ARM chips to surprise us with 128bit CPUs any time soon. I'm still waiting to see openSUSE running smoothly on a smartphone... the new Intel Atoms (N2600) hitting the streets right about now sound promising for handheld x86_64. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
John Andersen said the following on 01/14/2012 03:45 PM:
But not all applications have that need, and lots of things work just fine with smaller registers.
For example, most loops are just fine with 8-bit registers ... I suspect, that somewhere in the history of computing, there have been machines with small registers dedicated to loop counting. After all, its a much simple operation than having a general purpose register that can handle arithmetic and shift etc, and back in the days of valves all that logic was expensive. -- Objects in calendar are closer than they appear. -- Jim Duncan -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
John Andersen said the following on 01/14/2012 03:45 PM:
But not all applications have that need, and lots of things work just fine with smaller registers. For example, most loops are just fine with 8-bit registers ...
I suspect, that somewhere in the history of computing, there have been machines with small registers dedicated to loop counting. After all, its a much simple operation than having a general purpose register that can handle arithmetic and shift etc, and back in the days of valves all that logic was expensive.
I have worked at the machine level on several types of CPU and never seen such a "loop counter". On the other hand, a general purpose register that could handle that function, among many others has been part of every one and would be essential in any useful computer, unless all operations were performed in memory. BTW, the Data General Nova & Eclipse computers had an interesting feature called autoincrement (and decrement) memory. When memory was indirectly accessed through one of those autoincrement or decrement locations, the number they contained was incremented (or decremented). This was useful when you had to access sequential memory locatings. Those computers also had four accumulators, which were general registers that could do arithmentic and logic functions. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott said the following on 01/15/2012 09:37 AM:
I have worked at the machine level on several types of CPU and never seen such a "loop counter". On the other hand, a general purpose register that could handle that function, among many others has been part of every one and would be essential in any useful computer, unless all operations were performed in memory.
"Part" being the operative word. Not all machines had all registers as 'general purpose' as the old 404, 8080 and z-80 demonstrated. Yes, the series/360 and the PDP-11 and their look-alikes the Z-8000 and z-80000 had all programmer accessible registers "general purpose (except when they were 'stacked' or aliased to floating point), but there were many exceptions. Such general purpose registers banks are incredibly compiler-friendly. The Motorola 68000, the basis of the original SUN machines, had four general purpose registers and four dedicated memory pointer registers. You calculated an address and moved it to the memory pointer. Wasn't the the old Z-80 like that? The NS 32032 (and its 16 bit predecessor) was compiler friendly but in another way because of the way its dedicated regisrter were set. Some runtime models hand parameters via the stack frame, the same stack frame used for call-return. The 32032 had a dedicated frame pointer, dedicated stack pointer and dedicated opcode pointer - prehaps more, I forget - as well as its computational frame. The stack and frame were handled automatically. Machines of the 40s, 50 and 60s were not 'compiler friendly' because we hadn't developed language technology and because that was the era when hardware was more expensive than programmers. In England single register machines were the norm, perhaps with an overflow register. The military also had many very peculiar architectures that when described sound like RISK but actually were not since the opcodes interacted with memory (which was also expensive) in peculiar ways. I recall one ALGOL-60 complier that fit in 4K of 18-but words (one opcode to a word) which was mind-boggling. In the '70s I build, using the old AMD 2900-series bit slice micro-programmable chips, a number of of odd architectures that, for example, replaces magnetic logic arrays. Much, much lighter! -- I don't know the key to success, but the key to failure is trying to please everybody -- Bill Cosby -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
James Knott said the following on 01/15/2012 09:37 AM:
I have worked at the machine level on several types of CPU and never seen such a "loop counter". On the other hand, a general purpose register that could handle that function, among many others has been part of every one and would be essential in any useful computer, unless all operations were performed in memory. "Part" being the operative word. Not all machines had all registers as 'general purpose' as the old 404, 8080 and z-80 demonstrated.
Yes, the series/360 and the PDP-11 and their look-alikes the Z-8000 and z-80000 had all programmer accessible registers "general purpose (except when they were 'stacked' or aliased to floating point), but there were many exceptions. Such general purpose registers banks are incredibly compiler-friendly.
The Motorola 68000, the basis of the original SUN machines, had four general purpose registers and four dedicated memory pointer registers. You calculated an address and moved it to the memory pointer. Wasn't the the old Z-80 like that?
The NS 32032 (and its 16 bit predecessor) was compiler friendly but in another way because of the way its dedicated regisrter were set. Some runtime models hand parameters via the stack frame, the same stack frame used for call-return. The 32032 had a dedicated frame pointer, dedicated stack pointer and dedicated opcode pointer - prehaps more, I forget - as well as its computational frame. The stack and frame were handled automatically.
Machines of the 40s, 50 and 60s were not 'compiler friendly' because we hadn't developed language technology and because that was the era when hardware was more expensive than programmers. In England single register machines were the norm, perhaps with an overflow register. The military also had many very peculiar architectures that when described sound like RISK but actually were not since the opcodes interacted with memory (which was also expensive) in peculiar ways. I recall one ALGOL-60 complier that fit in 4K of 18-but words (one opcode to a word) which was mind-boggling.
In the '70s I build, using the old AMD 2900-series bit slice micro-programmable chips, a number of of odd architectures that, for example, replaces magnetic logic arrays. Much, much lighter!
The only CPU that I can think of that didn't have some sort of register for such operations was (IIRC) the Texas Instruments 9900 series which did everything in memory locations. CPUs such as the 6800 and 6502 did a lot in special memory locations, but still had an accumulator. the Data General Eclipse line also used the AMD bit slice processor. However, those chips (there were 4 of them in the Eclipse) formed only the ALU of the CPU. There was a lot of external logic, including microcode & registers, to make them function. An Eclipse CPU consisted of two 15" square boards. Back when I was a computer tech maintaining those systems, I used to work right down to the microcode level. Over the years, I have worked with systems from Data General, DEC, Collins and Pr1me. I have also worked with 8080, 6502, 6809 and 8088 microprocessors and the Datapoint 2200 intelligent terminal which had an 8008 CPU built from discrete logic, as the Intel 8008 performance wasn't good enough. The first computer I worked on was the "Bid Ask" system in the Toronto Stock Exchange. It was built with vacuum tubes, relays and a memory drum and even it had registers, though not in the sense we see today. In it, each dual flip flop module had 4 vacuum tubes. http://ed-thelen.org/comp-hist/BRL61-t.html#TELEREGISTER-MAGNETRONIC-BID-ASK... That system was older than me, when I was working on it. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott said the following on 01/15/2012 11:33 AM:
The only CPU that I can think of that didn't have some sort of register for such operations was (IIRC) the Texas Instruments 9900 series which did everything in memory locations.
There was also a Ferranti microprocessor in the late 70s that didn't have a register-as-we-think-of-registers. It was essentially a 1-bit machine that streamed. We never tried it so I don't know how it handled addressing, but everything else seemed to be memory-to-memory. I never did hear of any applications using it, but Ferranti had enough political lobbyist leverage that they scotched other standards projects that were going on in the UK about that time. But then along came the IBM PC .... -- All warfare is based on deception. There is no place where espionage is not used. Offer the enemy bait to lure him. Sun-Tzu -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
James Knott said the following on 01/15/2012 09:37 AM:
I have worked at the machine level on several types of CPU and never seen such a "loop counter". On the other hand, a general purpose register that could handle that function, among many others has been part of every one and would be essential in any useful computer, unless all operations were performed in memory.
"Part" being the operative word. Not all machines had all registers as 'general purpose' as the old 404, 8080 and z-80 demonstrated.
Yes, the series/360 and the PDP-11 and their look-alikes the Z-8000 and z-80000 had all programmer accessible registers "general purpose (except when they were 'stacked' or aliased to floating point), but there were many exceptions.
There are plenty of CPUs with registers dedicated for special purposes. -- Per Jessen, Zürich (-2.1°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
John Andersen said the following on 01/14/2012 03:45 PM:
But not all applications have that need, and lots of things work just fine with smaller registers.
For example, most loops are just fine with 8-bit registers ...
I suspect, that somewhere in the history of computing, there have been machines with small registers dedicated to loop counting.
The instruction pointer? Only increment or load. :-) -- Per Jessen, Zürich (-2.0°C) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, Jan 14, 2012 at 3:45 PM, John Andersen
I'm not convinced that will yield any real world performance except when moving large chunks of storage around. When manipulating big chunks of data larger registers help. Twice the data moved in the same number of clocks.
For a lot of scientific and media tasks a wider unit is helpful. Look at SSE/AVX/etc. The wider the instruction the more data that can be manipulated at one time. Adding in these special purpose instructions alleviates the need to move the whole chip to a wider instruction. Also, the RAM and other slower factors will hurt it as well.
But not all applications have that need, and lots of things work just fine with smaller registers. Even when you only want 16bits off the bus, you generally load 32 and discard half.
Of course. Word processing and other simple tasks are easily 8 or 16bit capable. It's when you add all the crap(bells, whistles, guis, etc) that you need more power. The faster the chip, the more crap we can run on it to make it as slow as the one it replaced.
The debate of running a 32bit vs 64bit version of OpenSuse on 64bit hardware is still not settled. I doubt it will be that much clearer when you are talking 128bit vs 64bit.
Of course. That's what makes it fun. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 16/01/12 04:24, Larry Stotler wrote:
The faster the chip, the more crap we can run on it to make it as slow as the one it replaced.
ROFL! :) -- Bob Williams System: Linux 2.6.37.6-0.9-desktop Distro: openSUSE 11.4 (x86_64) with KDE Development Platform: 4.7.4 (4.7.4) Uptime: 06:00am up 4 days 17:31, 4 users, load average: 0.19, 0.21, 0.30 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 1/13/2012 10:44 AM, Per Jessen wrote:
I challenge anyone to, in a double-blind test, notice any difference between 2 and 4 cores for a regular office/desktop workload. (no compilations, video editing, CAD/CAM, Mathematica, raytracing etc.)
I do most of my work in Virtual machines. (Vmware). Multiple different Linux distros and Windows versions are needed for my testing. I can adjust the number of cores on a vm and see the difference immediately, whether the VM os competing with other vms or simply running alone. It makes a huge difference adding a second core. Not much difference going to 4. The more windows you have open the better it all works, until you start running into IO bottlenecks. (With Windows, you get less per additional core than with Linux). I use to have lab full of identical machines for this, and saw the same results there. We manufactured machines for a long time, and had many for testing. However, anytime there are multiple physical machines involved you can never be perfectly positive things are identical, as simple things like disk fragmentation can play a role in masking actual performance. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (11)
-
Anton Aylward
-
Bob Williams
-
C
-
Dennis Gallien
-
Haro de Grauw
-
James Knott
-
John Andersen
-
Larry Stotler
-
Per Jessen
-
Ruediger Meier
-
tparker@etherstorm.net