...

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

...

...

...

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 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. -- 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 wrote:

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 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

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

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

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

On Sat, Jan 14, 2012 at 3:45 PM, John Andersen wrote:

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 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