Dell Set to Introduce AMD's Triple-core Phenom CPU

An anonymous reader writes "AMD is set to launch what is considered its most important product against Intel's Core 2 Duo processors next week. TG Daily reports that the triple-core Phenoms — quad-core CPUs with one disabled core — will be launching on February 19. Oddly enough, the first company expected to announce systems with triple-core Phenoms will be Dell. Yes, that is the same company that was rumored to be dropping AMD just a few weeks ago. Now we are waiting for the hardware review sites to tell us whether three cores are actually better than two in real world applications and not just in marketing."

Comments

You know what would be even better?

[LaskoVortex]

Enable that other core!

Re:You know what would be even better?

[TI-8477]

I don't understand why they disabled it in the first place. Anyone care to explain?

Re:You know what would be even better?

[Azh Nazg]

It allows them to sell chips with one of the cores broken, thereby getting higher yields from their production lines.

Re:You know what would be even better?

[cheater512]

In multicore systems each core can only talk to two other cores.
With a quad core system, each core cant directly talk to the core diagonal to it which slows things down.

Three core systems can talk among the cores easily without any bottlenecks so they are faster than dual core and quad core.

Re:You know what would be even better?

[jericho4.0]

Chip yields. A significant number of the 4 ways have a defect rendering one core useless. For the same reason, the Cell is speced with 8 SPEs, but the PS3 ships with 7.

Re:You know what would be even better?

[Anonymous Coward]

lol. Please get fatally hit by a crashing roflcopter so we don't have to listen to this kind of shit.

Re:You know what would be even better?

[Pyrion]

I don't think so. Not in the case of triple-core processors that are just quad cores with one core disabled. In this triple-core configuration, one of the cores is connected to the other two, but there is no direct connection between those two that doesn't involve the third core. Visualize it as cores 1, 2, 3, and 4, cores 1 and 2 at the top, cores 3 and 4 at the bottom, 1 is connected to 2 and 3, 4 is connected to 2 and 3 but 1 is not directly connected to 4. Core 4 is the unlucky one, and there is no direct connection between core 2 and core 3, so if core 2 wants to talk to core 3 it has to go through core 1.

A native triple-core would have equal spacing between the three cores such that any core could talk to any other core without having to go through a middleman.

Re:You know what would be even better?

[LaskoVortex]

Ah, yes. This makes great sense, but the announcement should have read "one of the cores defective", which would be more correct. The word disabled suggests purposeful disabling, which is misleading--but perhaps the announcement was a victim of marketing language chicanery.

Re:You know what would be even better?

[Wesley Felter]

In multicore systems each core can only talk to two other cores.
With a quad core system, each core cant directly talk to the core diagonal to it which slows things down. That's not correct. In the Phenom, all four cores are connected to the crossbar and can communicate equally.

Re:You know what would be even better?

[omeomi]

But when you think about it, there's a lot of times when a triple core will be "faster" than a quad core.

Like modeling the behavior of triple-core computers, for instance...

Re:You know what would be even better?

[edwdig]

If the demand for triple core processors is higher than the supply of quad core processors with one defective core, then AMD could disable a working core on the quad core chips to ensure supply.

Happens all the time in graphics cards. The main difference between different model numbers in the same line is the number of pipelines on the GPU. Top end cards have them all enabled, lower models progressively less. Often the lower end cards will have working pipelines disabled.

Re:You know what would be even better?

[Anonymous Coward]

Ah, yes. This makes great sense, but the announcement should have read "one of the cores defective", which would be more correct. The word disabled suggests purposeful disabling, which is misleading--but perhaps the announcement was a victim of marketing language chicanery. So... They disable the defective one. How is this misleading? Other companies do it too -- HDD makers sell bigger HDDs as smaller ones when they fail QA testing, for example.

Seriously, if the price difference is enough to make buying one of these "tricores" worth it, and more importantly, if these Dells allow me to throw in a "real" Phenom aftermarket (or even ship with the option to buy a true quad-core Phenom...) well, more power to them.

Not only that, AMD seriously wins in this -- they sell these (likely Dell Precision Workstations and/or Dell XPSes) with their "tri" core CPUs, as well as -- I would wager -- their Quad Core CPUs as an upgrade, and they'll start to finally make some inroads with them. So far the impression I've gotten is that both Intel and AMD's quad core offerings have been kinda DOA with consumers (as opposed to the enterprise). But then again, I typically work with office workstations (Optiplex, PWS, etc).

Ob-Full Disclosure: I work for Dell as a Prosupport Tech Support Agent.

Re:You know what would be even better?

[cbreaker]

I thought that this was a "native" quad-core CPU? I know that Intel does the dual-dual-core thing, but it was my understanding that the reason AMD is touting their quad (and this triple) core as being better than Intel because of this fact.

Then again, I haven't been following CPU product lines in the past few months, so I could be mistaken.

In the end, this CPU will enable AMD to yield more CPU's and actually turn profit, but it won't be on market too long once AMD perfects the process and yields working quad-core chips most of the time.

Re:You know what would be even better?

[thefear]

But very few programs can handle 3 cores. That's because for programmers, tasks and data and everything really just doesn't divide very well by uneven numbers like 3. So most programs will use 2 of the 3 cores. I have a feeling that you don't understand how cpu scheduling works.

Re:You know what would be even better?

[PolarBearFire]

I think most CPUs have some sort of "defects" of some kind, and the ones sold are the ones that pass qc. By your definition, most of these CPUs are "defective" which has almost similar meaning as "broken". As long as AMD sells what they market, you can't say its defective.

Re:You know what would be even better?

[frostband]

IANAICFE (IC Fab. Expert) but I do know that in testing for functionality, they just test a small sampling from a batch to determine whether the whole batch is good or not. It's possible that they found that one batch had a bad core by their small sample which means that other chips in that batch of quadcores (that are now selling as 3 cores) possibly had 4 functioning cores. Anyway, to the semantics, one core is definitely disabled but not necessarily defective (yes, I know you said "more correct" suggesting that 'defective' isn't 100% accurate either, but I've already written this much...). On the plus side, I like seeing the word "chicanery".

Re:You know what would be even better?

[Anonymous Coward]

As Wolfgang Pauli liked to say:
That's not right! That's not even wrong!

Re:You know what would be even better?

[CodyRazor]

Well considering they make them with 4 cores the vast majority are probably fully functional, and it is disabled. Perhaps they have a system like the ps3 where if one of the cores dies post production it enables the spare core to further reduce warranty claims.

Re:You know what would be even better?

[Your.Master]

Are the connections between cores laid after testing? If they are laid beforehand, then you're back to the original question: why are they laying a fourth core that isn't going to be used (it's not being connected to the other three)? Does connecting after the fact have consequences (such as a second round of decreased yield, albeit more than offset by allowing one core to malfunction and making it the disabled one)?

Re:You know what would be even better?

[dbIII]

Had that sort of thing with the Intel Celeron 300 A (with a stargate sort of A symbol). There was not enough supply so they were rebadging sweet 450MHz symmetric multiprocessor capable Pentium II processors as the cheaper Celeron - just the thing for a two CPU socket board. It made it possible to have a fast two CPU system for about the same price as a fast single CPU system with Pentium II on the label.

The distinguishing feature is often the number of tests done to certify the hardware and in some cases it is not a failure in a certain test but that the test required for the higher spec was not done at all. The rumor with the Celeron mentioned above was that they were rebadged after passing all the tests required for the Pentium II 450 spec but there were a lot of them in storage and more Celeron 300's were required - so they got the "A and circle" symbol to distinguish them from the other Celeron 300's.

Re:You know what would be even better?

[Kyojin]

It is possible, even with a two-dimensional arrangement, to set up 4 cores with a single hop between them.

Arrange 3 cores in a triangle. Place the fourth core inside the triangle. Join this core to the other three cores. This has two issues: 1.) The paths are different lengths. 2.) A 3-dimensional link is required for the centre core to talk to anything other than the other 3 cores.

With a three dimensional arrangement, it is possible to have a single hop between any number of cores.

Re:You know what would be even better?

[Anonymous Coward]

It is all patented by Konami and used in their game called Gradius.

"Destroy the core."

Re:You know what would be even better?

[saibot834]

Or: We could activate the other core only partially, let's say it runs on 14,159% capacity. This way, we'd have a -Core!

Re:You know what would be even better?

[Swoopy]

This used to happen even in the 486 days already.
486es with a working co-processor (Floating Point Unit) were sold as "DX" models, the ones where it was broken were sold as "SX".
Even better, it allowed a market for FPU co-pro upgrades where one would install a co-processor upgrade alongside their 486SX later on.
Once production yields improved, this practice was continued for a while maintaining a market for both "SX" and "DX" models, where the "SX" models would have their FPU deliberately disabled. What on earth moved AMD and Intel not to simply start selling the "DX" processors at a pricepoint closer to the "SX" ones, I don't know.

The DRAM market has been much the same for even longer. The ZX Spectrum (Timex in U.S.) 48K model had in fact 80K of possible RAM on board. The first 8K were a sort of memory swapping / paging bank, and the remaining 40K actually consisted of DRAM chips where only half of the chip worked, which were cheaper than even the half-size but fully working ones. Replace those DRAM chips with fully working full-size ones and you'd have a whopping 80k in your computer.
(This post outs me as a dinosaur fossil, doesn't it? :-( )

Re:You know what would be even better?

[Peet42]

What about the original Athlons and Durons? The only difference between them was often a cut link on the top surface of the CPU that disabled moste of the cache. Have a Google and you'll find lots of instructions on how to remake the link and turn a Duron into a fully functional Athlon.

It's all about economics and "perceived value", not technology.

Re:You know what would be even better?

[Fordiman]

Which begs the question: are there ways of enabling the extra cores in such devices?

Re:You know what would be even better?

[adamqaisar]

I wouldn't be shocked if there was, knowing AMD it'll be something simple to do - remember how to unlock the multiplier on the old Bartons? Just join the dots!

Re:You know what would be even better?

[justkeeper]

I don't understand why they disabled it in the first place. Anyone care to explain? Power consumption.

Re:You know what would be even better?

[ScriptedReplay]

But when you think about it, there's a lot of times when a triple core will be "faster" than a quad core.

Particularly, and gloriously so, when the quad-core system is not powered on.

Re:You know what would be even better?

[paulkoan]

It is borderline chicanery - the core is defective, yes, but it has to be disabled to stop it being used a producing unwanted behavour.

Re:You know what would be even better?

[nospam007]

Ah, yes. This makes great sense, but the announcement should have read "one of the cores defective", which would be more correct. The word disabled suggests purposeful disabling, which is misleading--but perhaps the announcement was a victim of marketing language chicanery. ...and chipmakers would never sell processors with a disabled co-processor on purpose.

Re:You know what would be even better?

[Anonymous Coward]

not to simply start selling the "DX" processors at a pricepoint closer to the "SX" ones

The 90s called. They want their idiotic corporate buzzword back. Sane, mentally healthy people tend to use the term "price".

Re:You know what would be even better?

[GreatBunzinni]

You've just demonstrated that you don't have a clue about how an application is ran, let alone how an operating system manages the running processes. For starters, you keep on blabbering about "programs handling cores". That does not have any basis on reality, as the only "program" that can be stated that handles "cores" is the operating system. That's all. The remaining programs that the operating system executes may spawn processes and may be multi-threaded but they do not nor they can handle "cores". At all.

Moreover, even if a certain program, running on a 4-core system, generates 4 processes or threads, you still cannot claim that that particular program "handles 4 cores". It is up to the operating system to manage the system's resources, including where and how a process is ran. It might even run all the 4 processes or threads in the same core.

Another silly thing that you imply which is clearly wrong is that a user can only take advantage of the multiple cores in a system if that user happens to run applications which spawn as many processes or threads as the number of cores. That is just plain wrong. The operating system manages the execution of all the system's processes and threads, which means that it distributes the execution of those processes and threads through all the available processing cores. So, if you run 4 separate applications (single-process/threaded) on a decent operating system running on a 4 processing core system then the operating system may end up executing those 4 separate applications in the 4 separate processing cores. As any desktop computer is running at any given time more than 20 different processes (single or multi-threaded) then the advantage of having more processing cores on your system is rather obvious.

But hey, don't let logic and concrete knowledge on the issue get in the way of your judgement.

Re:You know what would be even better?

[kir]

I loved the 300 A Celerys. My friends and their families loved them too. In Japan, the dually box I built was traded to a friend for a 666 Celery (Satan's processor). He took it to the Netherlands with him. He then traded to a mutual friend for a video card or something. Mutual friend then took it to Florida with him. Used it as a file server for years. He eventually shipped it off to his Mother so she read could email and such.

I tried to get it back, but mutual friend told me to blow. It was a fun machine though. That was the ultimate "finger to the man" machine.

Re:You know what would be even better?

[broomer]

I do remember the Spectrum having 16K of ROM, 16K of RAM (with shared video) and 32K RAM.
Nothing can you do about the Z80 having 65535 bytes addres-space, so 80K needs a hardware-hack.
The 32K chips were pin-compatible with the 64 bit, except for a removed pin.

Re:You know what would be even better?

[yoprst]

Is it an attempt to set a new standard of subtleness for Slashdot jokes?

Re:You know what would be even better?

[chuckymonkey]

I wonder if I have a roflcopter in my tower with all the noise coming from it.

Re:You know what would be even better?

[ozbird]

To paraphrase:

Nigel Tufnel: The numbers all go to three. Look, right across the board, three, three, three and...
Marty DiBergi: Oh, I see. And most cores go up to two?
Nigel Tufnel: Exactly.
Marty DiBergi: Does that mean it's better? Is it any better?
Nigel Tufnel: Well, it's one better, isn't it? It's not two. You see, most blokes, you know, will be playing at two. You're on two here, all the way up, all the way up, all the way up, you're on two on your computer. Where can you go from there? Where?
Marty DiBergi: I don't know.
Nigel Tufnel: Nowhere. Exactly. What we do is, if we need that extra push over the cliff, you know what we do?
Marty DiBergi: Put it up to three.
Nigel Tufnel: Three. Exactly. One better.
Marty DiBergi: Why don't you just make two better and make two be the top number and make that a little better?
Nigel Tufnel: [pause] These go to three.

Re:You know what would be even better?

[SpinyNorman]

I think more fundamentaly he doesn't realize that thread != core (i.e. that a three, or 42 for that matter, thread program can run on an N-core CPU, where N = 1, 2, 3, 4, ....). Number of cores just means how much genuine parallelism may be occuring at run time.

His claim thay threads are useful in powers of two is of course complete junk since threads are usually used one at a time for specific tasks (data aquisition thread, rendering thread, etc), or in groups (maybe of run-time configurable size) to provide thread pools for specific tasks - e.g. server threads.

Let's not forget also that the OS itself will be competing with whatever application(s) you are running for the CPU, so even a single single-threaded program will benefit from a multi-core CPU by way of not having to compete with the OS as much for the CPU cores.

Re:You know what would be even better?

[Jeff DeMaagd]

I don't think sampling can necessarily tell whether a given batch will have a lot of chips with one defective core. I think they have to go farther with testing. It sounds like the kind of defect that's dependent on like a microscopic speck of dust to fall onto the silicon, but in a good enough place such that you can just map out an entire CPU core.

Re:You know what would be even better?

[kitgerrits]

A few months ago, there was talk of a special triple-core design, where each core had one bus to HyperTransport and one direct bus to each other core.
Apparently, this is not that design. This is explained in this other review:

When AMD does see a "problem core" or when the frequency mis-match among cores, they now have the triple core option to keep from scrapping or down-grading that die. So: either one of the four core slows its three brothers down, or they 'amputate' the slow one and sell the last three at full speed.

Re:You know what would be even better?

[Anonymous Coward]

It's not a matter of physical positioning, it's the design of the core that only has direct I/O to two other cores.

Re:You know what would be even better?

[drinkypoo]

The word disabled suggests purposeful disabling, which is misleading--but perhaps the announcement was a victim of marketing language chicanery.

Or perhaps you're just not comprehending the semantics here. It was purposeful disabling, to avoid problems with a problem core (or maybe they're just having thermal problems, for all we know.) The cores don't disable themselves. Thus it was disabled to deal with the problem of a defect.

It's not any more misleading than telling you that one Cell SPE is disabled on every PS3.

Re:You know what would be even better?

[Wowsers]

We have dual core 64 bit machines now and software vendors being lazy in updating their software to run on 64 bit machines, that's despite them being around for ages, and increasingly people buying dual core over single core. What makes anyone think that a 3 core system would sell well when there are so many lazy software vendors?

Re:You know what would be even better?

[billcopc]

Funny, I feel my 2.4ghz => 4ghz Intel quad-core has more finger than my old 300A ever did.

Overclocker culture has come a loooooong way in ten years.

Re:You know what would be even better?

[VagaStorm]

Um, that would be true if you only ran 1 program on your computer, but I, like many others, often run more than one program at the time, most which are only made to run on a single core, but they still run faster with a multicore since they get more of the processor they use for them self. I can even play multiple games at once since each will use about 100% cpu on a single core, but both running smoothly.

Re:You know what would be even better?

[Anonymous Coward]

So why do operating sytems have APIs where processes can control their own processor affinity?
I know Linux does (sched_setaffinity) and Windows (SetThreadAffinityMask).

Some reasons might be...
Reduced processor scheduling overhead.
Threads not blocked waiting while other threads run on the same core.
Dedicating a processor to things like network processes that generate lots of interrupts.

While in an ideal world the OS should handle this invisibly, I'm sure there are situations like games where the programmer might not want the OS moving processes around between the cores.

Re:You know what would be even better?

[Hal_Porter]

You could probably test the chips on the wafer before you chop it up. I can imagine supply power to the wafer and looping JTAG test lines through all the chips. Then some self test would run in parallel on all chips and you'd know which chips were bad, which had one bad core and so on. Actually just testing the cache would be a good idea. Since most of the die area is cache, most of the dust-spec style defects should be found there.

Of course a few chips might fail in other ways and you'd catch them after packaging, but that should be rare - most of the defects should be caught before you chop up the wafer and package the chips.

I am not an IC engineer, but it seems plausible you could do this.

Re:You know what would be even better?

[billcopc]

Yes and no.

If the cores aren't actually defective, then yes, AMD will make it relatively easy to unlock because that's what they were once famous for, with the Athlon XP.

If the cores are crap, then most likely they will lock them down securely to avoid bad PR. Enthusiasts like you and I understand that there are no guarantees once you start tweaking, but we're not the problem. The problem is shady vendors that unlock/overclock to defraud the client.

Example: I just finished building a cheap machine for my mother-in-law, using an Intel Core Duo E2160 - 1.8ghz stock, but even on a low-end board I managed to hit 3.0 ghz with ease. There are plenty of half-bred sons of bitches who would gladly charge an extra $250 for that system and claim it uses the top-end E6850 processor. This sort of thing is why multiplier locking was implemented in the first place. Back in the 80s and 90s this type of fraud was the norm rather than the exception.

Unlocked or not, I'm not buying a Phenom anytime soon and neither should you. They're weak compared to Intel's 2-year-old Conroe architecture, and by consequence that makes them overpriced. Worse still is the lack of quality motherboards for this young dumb processor. One can only hope they will improve over time, but I won't hold my breath. In my book, everything that came after the NForce4 Ultra has been absolute garbage.

Re:You know what would be even better?

[flyneye]

From a consumer standpoint (mine),it makes me want to wait for actual working quad core processors.
Tell that to Herb,down in marketing.
Mention also,I took his stapler.

Re:You know what would be even better?

[jp102235]

ok, I am an IC test engineer:

#1: you do test these chips before the saw step (chopping the wafer up into individual die)
#2: its hard to predict speeds/vcc/temp sensitive yields at that stage, but you do test all the die and usually check for full functionality (as much as the test coverage allows)
#3: once packaged, the chips are "binned" to functional fails, speed grades. etc, and are tested at temp, vcc limits for speed sorting. so you could have 1 core that fails at 30C with a high vcc, but the others are ok (this is should be rare since they all sit together on the wafer in close proximity, and thus shouldn't vary much from each other)
#4: nanoscopic defects occur and could take out one or two of the die. It would be advantageous to bin this out as a tri/dual core.
#5: I am 100% sure that if these become popular, there will be some chips that pass all tests fully, but have one core disabled. happens all the time.

JP

Re:You know what would be even better?

[Sancho]

Not necessarily. If these processors are popular, and AMD's fab process improves to the point where there are fewer defective cores, they'll have to ship some fully-functional quad-cores with one core disabled in order to meet Phenom demand.

Re:You know what would be even better?

[Sancho]

It depends upon what you want to do.

Lots of programs still aren't threaded. These programs just won't see much of a speed improvement with multi-core. The best you get in those situations is that the thread tends to get more CPU time overall. Keep throwing more cores at the problem--with today's software, you'll hit diminishing returns pretty quickly. It's entirely possible that tri-core is the sweet spot right now.

Re:You know what would be even better?

[ILuvRamen]

yes, programs do indirectly control how many cores they use. If you only run your program's processor intensive code in one thread, the OS's scheduler can only assign it to one core and that's that. If it was capable of splitting a single thread between cores, every program would work well on multi-core systems. Like a zip password cracker for instance. The one I run only uses 100% of one core. If they coded another thread to try the second half of the list of passwords and started both threads at once, then it'd use both cores. And like I said, nobody programmed their programs to split the processing into three parts, only 1, 2, or 4. And like I said, if one program is using up all the cores and maxing them out, your system appears frozen because explorer.exe and other such processes don't get enough resources. If you have one core open, other processes from other programs can use it so it appears faster to have 3 cores than 4 under some circumstances.
And by the way, how often does more than one process running on your computer at any given time use up a significant amount of processor resources? Yeah, almost never. Most of them sit there idle.

Re:You know what would be even better?

[cuantar]

Parent is running Windows, which I can fully believe behaves the way parent says it does.

Re:You know what would be even better?

[Pyrion]

Native only in the sense that the cores communicate directly as opposed to indirectly. The problem with Intel's design is obvious: the FSB is much slower than a direct connection between the cores. The problem with AMD's design is not so obvious: middlemen. AMD's design is limited to a worst case of any core having to communicate across one or multiple middleman cores, though it might still be faster than going direct through the shared FSB.

Re:You know what would be even better?

[GreatBunzinni]

Processes cannot control their own processor affinity, at least not when running on those operating systems (and countless others). What the processes (and, through other mecanisms, also the users) are able to do is hint the operating system to run a certain process on a certain processor. The operating system takes those hints in condideration but it isn't forced to obey those hints.

Re:You know what would be even better?

[vbraga]

Now, go run your super leet zip password cracker and get off my lawn.

I don't see why you insist the number of threads must be an even number. It simple doesn't make any sense.

And like I said, if one program is using up all the cores and maxing them out, your system appears frozen because explorer.exe and other such processes don't get enough resources. Once upon a time, kid, we hadn't operating systems and we need to go to work uphill, both ways, on snow. But today, kid, we got this marvelous thing called operating system (well, not so marvelous if you need a "explorer.exe"): inside of it, you can find a magic box called scheduling.

And, at least, kid, go read a book on operating systems.

Re:You know what would be even better?

[electrosoccertux]

For some reason "Triple Core" sounds cooler than "Quad Core".

Re:You know what would be even better?

[Anonymous Coward]

No. Setting processor affinity on Linux with sched_setaffinity really does bind that process to a particular CPU CPUs. (The affinity mask can specify more than one CPU if desired).

From the man page: "In other words, a process is bound to and will only run on processors whose corresponding bit is set."

Its the same on Windows as far as I know. This will screw up load balancing etc, but sometimes the user knows best.

Re:You know what would be even better?

[BOFHelsinki]

And like I said, nobody programmed their programs to split the processing into three parts, only 1, 2, or 4.

Yes, this is why the triple-core Xbox 360 has practically no games for it.

Oh wait.

Re:You know what would be even better?

[Jesus_666]

And like I said, nobody programmed their programs to split the processing into three parts, only 1, 2, or 4.

Holy shit. My program uses one thread for the GUI, one for I/O and one for actual calculations. Does that mean it's broken? Can I fix my program by ading a fourth thread that just spinlocks?

Re:You know what would be even better?

[Anonymous Coward]

Oh shit, I've never seen someone get trolled so hard with such a glorious outburst of nerd rage before.

YOU GOT TROLLED, SON

Re:You know what would be even better?

[Frostalicious]

And like I said, nobody programmed their programs to split the processing into three parts, only 1, 2, or 4

I wrote several programs that spawn X threads, where I could configure X to any integer upon program launch. I've had X at 3 several times and the thing didn't self destruct.

Re:You know what would be even better?

[Anonymous Coward]

The one I run only uses 100% of one core. If they coded another thread to try the second half of the list of passwords and started both threads at once, then it'd use both cores.

No. It. Wouldn't.

The program does not "use cores". The operating system does.

From the post you're replying to is a great summary:

Moreover, even if a certain program, running on a 4-core system, generates 4 processes or threads, you still cannot claim that that particular program "handles 4 cores". It is up to the operating system to manage the system's resources, including where and how a process is ran. It might even run all the 4 processes or threads in the same core.

Re:You know what would be even better?

[cbreaker]

Of course, if a data hop through another CPU is necessary, it's just that - a hop. The other core doesn't have to reprocess the data, so it's a quick transfer. The same will happen in multi-socket SMP systems. Say, a quad socket CPU system. The machine will have four banks of RAM, each connecting directly to one of the sockets. So, if CPU 2 needs to access RAM connected through CPU 1, a hop will have to take place. But, that's what NUMA is supposed to help avoid. Moving RAM data around to be local to the CPU that needs it. The AMD Quad-core design would run into similar issues but NUMA can help a little bit there, too. And, AMD's BUS is faster than Intel's BUS, not to mention that AMD processors integrate the memory controller on the CPU which helps things out quite a bit - no need to always bridge through a northbridge.

Overall, if you want to be able to get the most out of a big SMP box, you need to run AMD. The proliferation of VMware across the enterprise has helped push AMD forward. If there's more than two CPU's, I insist on running Opterons. Better performance; less BUS and RAM contention issues.

I'm sure Intel will move to a similar architecture eventually, but you can still achieve good performance with the current design and it's cheap.

Re:You know what would be even better?

[Meski]

It allows them to sell chips with one of the cores broken, thereby getting higher yields from their production lines. If one has broken, does that increase the odds of another breaking, compared to one with none broken?

Re:You know what would be even better?

[Babu 'God' Hoover]

If they sell you three working cores and you get three working cores, there is no defect and no chicanery. You don't want that fourth core jumping in and yelling TUCK when you want it to yell BUCK so it's disabled.

Not 100% and allowed to park in the handicapped space = defective?

Re:You know what would be even better?

[Ihlosi]

If one has broken, does that increase the odds of another breaking, compared to one with none broken?

Not really. Flaws on the silicon (which is what causes "broken" processors) are randomly distributed. Having a flaw on the die that "breaks" one core does not mean that other flaws are more likely to be in the vicinity.

Re:You know what would be even better?

[neuromancer2701]

I used to work for a now defunct cooling solution company. We did cooling systems for speed sorters for Advantest and Delta Design. One of the Intel engineers described it as they don't know exactly what speed the chips are going to be but they know the range, example 2.2-2.6 and it is normally distributed across that range. Whenever a new speed lets say 2.8 comes out that means the center of that range has shifted up. We did a lot of interesting stuff, watching those speed sorters run was truly amazing. I used to work for Kryotech by the way.

Re:You know what would be even better?

[GreatBunzinni]

yes, programs do indirectly control how many cores they use.

Wrong. You still don't get it, do you? A program simply does not have the capability to state how many cores it will use. No matter how many times you repeat yourself, a program does not nor can it ever "use cores". The only thing that a program is capable of doing is defining what portions of the code may run parallel. That's all. The rest of the job is up to the operating system which, as it may surprise you, is the sole responsible of managing the system's resources, including CPU time.

(...snipped nonsense...) And like I said, nobody programmed their programs to split the processing into three parts, only 1, 2, or 4.

Wrong again. What you said doesn't make any sense at all and reveals a deep ignorance on the subject. See, it also wouldn't make any sense to state that a certain operating system could only run a "power of two" number of processes at any given time. So exactly why would it make any sense to state that you could only design applications so that they could only run power of two number of processes/threads? The mechanism that executes the application's threads/processes is the exact same mechanism that executes all the independent processes. Don't you even realize that? Moreover, there isn't a single parallelization interface that forces a programmer to only specify a power of two number of processes/threads. Anyone can run fork() as many times they wish, as pthreads_create() can run as many times you need. Heck, did you ever heard of the make utility? Do you happen to know that it has a nifty little option which enables the user to specify the number of jobs it runs parallel? For example, do you understand what make --jobs=3 does? And what about make --jobs=7? I bet it blew your mind.

And by the way, how often does more than one process running on your computer at any given time use up a significant amount of processor resources? Yeah, almost never. Most of them sit there idle.

Just because your ignorance is forcing you to make stuff along about parallel computing it doesn't mean you need to imagine what's the system load of some random person's computer which is located somewhere across the globe. You only end up looking sillier.

Re:You know what would be even better?

[Anonymous Coward]

Sorry, but you have some of your facts wrong. While the operating system handles scheduling and core use, it is possible for a program to tell Windows (XP and up) the maximum number of cores to use to run the program. This is necessary because there is a real difference between runing multiple threads on a single core and on multiple cores.

For those gamers who find a game locks up on their multicore computer, this is usually a sound issue that can be cured by reducing the number of cores the game uses to one.

Re:You know what would be even better?

[Ihlosi]

Sorry, but you have some of your facts wrong.

Well, a program has control over the maximum number of cores it will run on (if it has only two threads, it will utilitze two cores, but not more), but it can only set the actual number of cores to one (a program that has exactly one thread will only run on one core). As soon as it has more than one thread, it's up to the OS to assign the actual number of cores to it.

For those gamers who find a game locks up on their multicore computer, this is usually a sound issue that can be cured by reducing the number of cores the game uses to one.

This usually happens in single-threaded games that somehow don't like being moved between CPUs, afaik. The solution is to explicitly assign a core to the game by the OS (via the task manager).

Yield, effectiveness

[Sparr0]

Making 3-core machines out of 4-core CPUs will do wonders for their yield. So many chips get trashed because of single tiny failures, this will allow them to keep any chip with any number of failures as long as they are limited to just one of the cores. The same sort of benefit Intel saw by using Pentiums with bad cache segments to make Celerons, or nVidia saw when disabling (supposedly) bad pipelines to turn 16-pipe GPUs into cheaper 12-pipe versions.

I am sure some units will make it through the process with a functional-enough fourth core to be useful to "overclockers", but I think the majority will have actual problems. That is, unless there is no 4-working-core version of this processor for the known-working ones to be sold as?

One concern... How do they keep thermal load even if 1/4 of the die is not running?

Re:Yield, effectiveness

[MiniMike]

> One concern... How do they keep thermal load even if 1/4 of the die is not running?

If running Windows, the OS will cycle through the cores so 3 are always running, and one is cooling. This will usually not cause a problem before the system crashes due to something else.

For other OSes, I would think that the conductive layers over the non-functional core would still be working, and capable of distributing the heat evenly. Same problem as when 1 core is running full tilt and (1, 2, 3 for dual, triple, and quad core) are idling.

Re:Yield, effectiveness

[Sparr0]

OK, perhaps I am mis-educated regarding this particular device, but I expect that one of the four cores will be defective on almost every Phenom CPU. That means cycling through them would not be an option.

Re:Yield, effectiveness

[TubeSteak]

One concern... How do they keep thermal load even if 1/4 of the die is not running? I was wondering the same thing and I imagine that they don't. I never heard anyone say it was a problem in dual core systems when Windows pegs 1 core and lets the other sit idle.

Ultimately, that's what the heat spreader is for. Right?

Re:Yield, effectiveness

[Anonymous Coward]

I believe you are right. There is no option to cycle through the other core or whatever. It is disabled, and you would not want your code to do anything on it.

I am guessing it just works. Like newer Intel chips that power off a core to save power, probably Core 2 Solo chips that are really Duo's with one half disabled, IBM Cell chips with one SPU disabled, and so on, the thermal load gets absorbed by the chip package quite readily and heat moves to the disabled core(s) without ill effect.

Of course, I am not a EE or ME. I just can think rationally.

Re:Yield, effectiveness

[mr_matticus]

Why?

If one is disabled, it would cycle 1,2,4,1,2,4 (assuming #3 is the bad one).

Moreover, if one of the cores isn't running, and you have a cooling system designed for four cores, it really doesn't matter. If it can handle four full-tilt cores, it can handle three. The zero heat production is a bigger benefit than a slightly uneven distribution. If it's truly a suitable medium, the heat generated will be spread throughout pretty well, even if the heat-production is only on one edge of the medium. Think of an electric stove burner--it only has heat applied at one end, but the opposite end heats up pretty well. Obviously it's not perfect, but it doesn't need to be.

Re:Yield, effectiveness

[Ibiwan]

Maybe you missed where he specified this was only feasible in Windows... Who's gonna notice something trivial like a non-functioning CPU core a fourth of the time!?

Re:Yield, effectiveness

[jcorbett66]

is this possible? http://www.hypworks.com/blog/

Re:Yield, effectiveness

[Iguanadon]

If running Windows, the OS will cycle through the cores so 3 are always running, and one is cooling. This will usually not cause a problem before the system crashes due to something else.

I haven't really looked at Phenom's design, but I highly doubt that it'll rotate between the cores while running. You can't really transfer the contents of registers and whats in the pipeline between cores in any sort of efficient manner (unless there is something about the Phenom I don't know about).

Why would the thermal design even matter that much? It'll be equivalent to having hotspots on the motherboard (though nowhere near as dramatic, the die is tiny and very conductive to heat). By simply having a heatsink on it that can handle four loads, it'll easily be able to handle 3 active (and 1 idling) core.

Re:Yield, effectiveness

[mkranz]

Or for instance, using 7 of the 8 cores on the PS3 cell CPU?

Building a Cell with 8 "working" cores was going to make the playstation unbearably expensive to produce, so they decided to also use CPU's with one dud core. Of course, some PS3's do have the full quota of 8 cores, but the 'spare' is disabled before it exits the factory.

http://en.wikipedia.org/wiki/PlayStation_3#Hardware

Re:Yield, effectiveness

[Anonymous Coward]

The GGP was suggesting it would cycle through all 4 cores, 3 at a time. Which is totally wrong. You can only cycle through the 3 good cores. The 4th being unavailable.

The GP stated that was not possible for obvious reasons. And you replied with a "no! you're right."

Re:Yield, effectiveness

[rcs1000]

Whoosh!

(It was a great comment tho')

Re:Yield, effectiveness

[killmofasta]

Quote: "Who's gonna notice something trivial like a non-functioning CPU core a fourth of the time!?"

AMDs software can monitor, and cut power to any core, or change Vcc to any core, and overclock/underclock any core. You would notice it very quickly.

Re:Yield, effectiveness

[Anonymous Coward]

If it's truly a suitable medium, the heat generated will be spread throughout pretty well, even if the heat-production is only on one edge of the medium. Think of an electric stove burner--it only has heat applied at one end, but the opposite end heats up pretty well. Obviously it's not perfect, but it doesn't need to be.

1. That's why CPUs have heat spreaders.
   
2. Electric resistive elements heat up uniformly (in theory; variances in the materials will obviously have a minor effect). The field gradient throughout the conductor is constant, and so power is dissipated all along the length at a constant density. You don't put electricity in at one end, have the voltage abruptly drop to 0, and then conduct the heat through the rest of the coil. Otherwise, you would just have a very short heating element and connect a heat-spreading plate to that.

Re:Yield, effectiveness

[Anonymous Coward]

WOOOOOSH!

Re:Yield, effectiveness

[Anonymous Coward]

"You can't really transfer the contents of registers and whats in the pipeline between cores in any sort of efficient manner (unless there is something about the Phenom I don't know about)."

Every context switch in a multitasking OS already does that anyway. In the best case, you're only stuffing that info into cache and pulling your next process' info out of cache, but you might very well have to hit main memory anyway.

The Phenom's cores have a shared L3 cache, so theoretically you could shuffle a process around between cores without (much) penalty.

Re:Yield, effectiveness

[mr_matticus]

I don't believe that is this case. He was suggesting that a four-core setup can be configured so that one is idle to moderate heat buildup. This was a direct response indicating that with such a configuration, heat production is uneven even if there are four good cores. The post further states that the conductive medium would distribute heat throughout, which is correct.

The reply to that states that "one core is defective, so it can't cycle through them." That doesn't make any sense.

In a three-core system, the unevenness is not a problem, because heat production is uneven in a fully-function four core system, too.

Re:Yield, effectiveness

[mr_matticus]

That's why CPUs have heat spreaders. No kidding! Why else would I be talking about them?

Electric resistive elements heat up uniformly Precisely the point. You apply input at one end (in the case of a stove element, electricity), and the medium conducts it throughout. It's called choosing the right material for the right job.

You don't put electricity in at one end, have the voltage abruptly drop to 0, and then conduct the heat through the rest of the coil I didn't suggest that the heat was only produced at the end. I suggested that if engineers designing systems were as incompetent as the parent post to my comment implied, they wouldn't be able to pick the right material for the right job. If a material required even heat application, it wouldn't make a suitable heat distribution medium for a CPU cooler in the first place.

Re:Yield, effectiveness

[Anonymous Coward]

Electric stove burners don't have "heat applied at one end". The entire coil is a resistor and heat is generated through the length of the coil.

Re:Yield, effectiveness

[Anonymous Coward]

Clearly a typo. Electric stoves are, of course, electric.

Licensing?

[kermit1221]

So, does one have to purchase 1.5 Vista licenses?

Re:Licensing?

[Pyrion]

Ha ha, funny, but why would it matter? This is a single socket we're talking about, so unless Microsoft has changed their licensing to per-core as opposed to per-socket (and AFAIK, they haven't), this is a non-issue.

Re:Licensing?

[Lord Apathy]

One doesn't. Mickysoft has stated they will sell licenses based on the number of CPU's your system has. Not the number of cores your CPU has. So if your system has one physical CPU but that CPU has 2, 3, or 4 cores mickysoft only counts it as one CPU.

I've been away from IT for very long

[blind biker]

Since I started studying microsystems eng., I disconnected from a lot that's been going on in the IT world. So I admit, I had no idea Dell was making AMD-based PCs. When did this start?

Re:I've been away from IT for very long

[compro01]

it was either late '04 or early '05.

Re:I've been away from IT for very long

[neonmonk]

I wonder how it affects their relationship with Intel? Ubuntu, AMD... Intel, Microsoft.

Wonder what Dell's long term game plan?

Re:I've been away from IT for very long

[solafide]

When Dell bought Alienware (who used AMD CPUs) Dell began using AMD.

Re:I've been away from IT for very long

[Shadow-isoHunt]

How the hell did this get modded off topic?

Re:I've been away from IT for very long

[Vectronic]

1. Buy individual parts wholesale.
2. Configure parts in a myriad of configurations.
3. Market configurations to an assortment of consumers.
4. ???
5. Profit.

Thats there game plan... you seem to be in a weird conspiracy sort of thought mode, that because they are now offering AMD's that it means 2 years from now that they are going to switch to only Linux based Systems?...

Furthermore, I dont think there is any proof that Linux runs better on an AMD, or that Windows runs better on Intel, or vice versa... as far as I am aware, the only major difference is that AMD is more geared towards brute force, "Get It Done Now, Damn Everything Else" sort of processors, and Intel is more Multi-Tasked... if any Operating System runs better on one processor better than another, thats a FAULT of the OS, not a benifit... at least with regard to AMD and Intel, not including lesser-known or specialty processors...

But thats just from my own experience really, not a scientific analysis of AMD and Intel processors...

Re:I've been away from IT for very long

[neonmonk]

Not really what I was saying. From past history it's not a far stretch to think that Microsoft and Intel are quite against alternatives.

Re:I've been away from IT for very long

[repvik]

The same way yours got modded "Redundant" (wtf?!).
Anyone care to wager a bet on what my mod will be? I'd say flamebait/troll is a bit over the edge... Overrated perhaps?

Re:I've been away from IT for very long

[Anonymous Coward]

Not really. Dell using AMD had not much to do with Alienware... Dell has been prototyping AMDs for a while.. they didnt want to go AMD for supplychain reasons. And then Dell hired a lot of HP guys with experience with AMD and then decided to go AMD. Dell Started AMD with servers line and not desktops for example. Posting AC, I used to work on this project

No

[Sycraft-fu]

Microsoft has declared for all their products that a processor is defined as a physical processor in one socket. No matter how many cores it has, it is a single CPU for licensing purposes. Also you don't have to buy more licenses to run more processors, you have to buy different versions. Last I checked it was 2 processors for workstation versions, 4 for server, 8 for advanced server and 32 for datacentre. Not sure if that's changed.

At work we have purchased a dual processor system with a quad core CPU in each that runs Vista. All 8 cores show up and are usable by software.

Re:No

[rastoboy29]

Wow, how generous of them.

Re:No

[Spit]

How quaint!

Re:No

[dbIII]

If you can't do a bare metal reinstall without reading a 42 digit number over the phone to somebody in India their licencing confusion is barely relevant in a serious computing environment. Limits of 2GB and 2 processors show that the world passed them by long ago, let alone birrare connection limits defined by licences instead of the capabilities of the hardware that should render them irrelevant for fileservers once you get a company big enough to have more than five computers.

You have an 8 processor machine running Vista? I know quad core chips are cheap but if you are going to run MS stuff why use the hobby software instead of at least the small business software? You would have a better file server for the MS Windows environment by even putting a knoppix CDROM in and turning on samba - the slow read speed of any applications from the CD would still vastly outperform Vista and access to hard drives would be much faster.

Re:No

[Sycraft-fu]

There is no 2GB limit on Vista. If you are referring to the 2GB per process limit in 32-bit Windows, that is a function of how they do 32-bit memory allocation, and they aren't alone in that. Windows splits the virtual address space in half, 2GB for user 2GB for kernel. In 64-bit Windows the limit on 32-bit processes is 4GB, and there is no effective limit on 64-bit processes since the virtual space is larger than the physical memory you can get (it again splits the address space in half, however that gives 8EB for user and 8EB for kernel).

A 2 processor limit is not a significant problem as it is rather rare to find workstations that use more than 2 physical processors. Price does not scale linearly with number of processors. If you can get a single processor system for $1000, a similar dual processor system is not likely to be $2000, it is likely to be more. Quad processor systems yet again go up in price.

Vista is not hobby software, it is MS's current gen desktop OS. Regardless of what you may have heard, it is the Windows XP replacement and it functions as such. The reason the system in question runs Windows is because it is running Windows software. I believe it uses Visual Studio and the Intel Fortran addon, but I'm not sure (one of the research groups use it).

We wouldn't bother to put so much CPU in a file server, it wouldn't be useful. As a practical matter, we use a NetApp FAS unit as our central file server. It's performance and features are great.

Re:No

[dbIII]

If you are referring to the 2GB per process limit in 32-bit Windows, that is a function of how they do 32-bit memory allocation, and they aren't alone in that

They are completely alone in that since many other systems properly support the pentium pro and later processors - including other 32 bit systems sold by Microsoft. Their hobby line (including their latest 32 bit operating system) unfortunately does not.

Re:No

[TechyImmigrant]

>If you can't do a bare metal reinstall without reading a 42 digit number over the phone to somebody in India their licencing confusion is barely relevant in a serious computing environment.

It's a complete show stopper when installing in an air-gapped secure room holding the root keys for a certificate authority. The place is RF shielded, no wires enter the room except the well armored power supply, no cell phones or other comms equipment are permitted.

Re:No

[glitch23]

Last I checked it was 2 processors for workstation versions, 4 for server, 8 for advanced server and 32 for datacentre. Not sure if that's changed.

Well, the names have changed for one thing. There is Web (for R1 only), Standard, Enterprise, and Datacenter editions. From the horse's mouth:

R2 Standard Edition supports up to 4 processors

R2 Enterprise Edition supports up to 8 processors

R2 Datacenter Edition supports up to 32/64 processors depending whether the CPUs are 32-bit or 64-bit.

MS used to require Data Center to not even install on anything that had less than 16 CPUs if I remember correctly but based on the above it seems that they allow it but you would be wasting your money by doing anything less than 32 CPUs with it.

Re:No

[Anonymous Coward]

When dealing with high security data like that you'd have to be crazy to use Windows regardless of its licensing / unlocking conditions. Can you trust Microsoft's secret proprietary binary code to either (1) keep your secret key private, or (2) not lose, destroy or corrupt it?

Re:No

[TechyImmigrant]

No. I don't trust them. The security comes through the use of air-gapping (no network connection), HSMs (Hardware Security Modules) and the access and use procedures. The OS is Linux, but that is not what determines the security of the system.

Re:No

[walbourn]

The repeated usage of the word "hobby" here is actually somewhat ironic. The majority of contributions to Linux come from people who have day jobs that pay their bills, and they use their free time to support Linux and other Open Source products. This actually fits the definition of a "hobby".

This thread suffers the same problem as every other thread on /. that in any way touches upon Microsoft products and technology. The opinions expressed are not only biased but ill-informed. It's to be expected I suppose from a community that prides itself on being willfully ignorant of Microsoft products. The /. community is perpetually stuck in the mid-90s with respect to Microsoft, embodied by the continued use of "BillG as a Borg" icon as both cultural artifacts are laughingly outdated. I suppose I should simply be grateful you didn't side-track into the usual DRM FUD rant that seems to be engrained into /. whenever the word "Vista" is used in any context.

David Cutler when first approach by Microsoft is quoted as saying he wouldn't work on "toy" operating systems in reference to MS-DOS and Windows 3. This characterization could be applied to all the 32-bit Extended DOS products in the Windows 9/ME line. As of Windows 2000, Microsoft's operating systems were all built from the NT codebase David Culter architected, and cannot be characterized as a "toy" operating system. Windows Vista unifies with the Windows Server 2003 Service Pack 1 codebase, and the kernel is a fully modern multi-user, multi-threaded, multi-processor OS supporting x86, x64, and IA64 processor architectures.

Microsoft's per-socket licensing policy has been around for several years, and updates for the radical shift in the market. MP used to be the realm of servers and workstation machines, and the price-points of the business were built around this fact. With the mulitcore shift, this no longer applies by counting 'processors' or 'cores' but still holds with respect to 'sockets'. Machines with more than 1 or 2 physical sockets are typically servers, not workstations. Windows XP will work on dual, quad, and octcore multicore systems, although the OS itself was tuned based on the realities of the market in 2001: single-core and Hyperthreaded single-core machines were the 99% case, with a few high-end workstation machines sporting 2 single-core CPUs. A more serious architectural limit was the way the NT OS used a relatively fixed layout for the 2 GB of kernel-mode memory, and therefore had hard limits on the potential sizes of important kernel memory pools used when allocating a large number of resource handles. The Windows Vista kernel includes dynamic kernel-pool sizes, so this eliminates this problem which is endemic on Windows XP. Running Windows Vista on an 8-core machine is therefore a much better technological choice.

The 2 GB limit of 32-bit processes is not unique to Windows. Using the high-bit to indicate kernel-mode privileged memory is a long-standing technique, and has the benefit of ensuring that all pointer math actually works (i.e., the difference between two user-mode addresses or two kernel-mode addresses fits into a 31-bit signed integer without over/underflow). A 32-bit OS can make use of 32-bits of addressing lines on the physical memory to address up to 4 GB, but standard 32-bit processes are limited to 2 GB of user-mode address space. The problem is that some of those addresses must be used for adapters with the way PC architecture was designed years ago with some of the 3 to 4 GB ranged allocated by video cards and other devices. Therefore, a 32-bit OS can actually only support about 3 to 3.5 GB worth of physical memory, meaning it can support multiple 2 GB limited processes reasonably well.

2 GB was once a stupendous amount of memory address range. In fact, this was the realm of hard disk sizes for many years. Moore's Law has continued its growth, and we are now well into a another transition. There are some transition technologies like Large Ad

Re:No

[dbIII]

but standard 32-bit processes are limited to 2 GB of user-mode address space

That of course changed with the Pentium Pro some time ago. The professional line of Microsoft software (NT etc) did have support for that but the software intended for the home market did not.

I wish I actually was ignorant of Microsoft products in which case I would not have spend what appears to be hundreds of hours removing malware from poorly configured machines and much time getting Exchange 5.5 to work properly when the MS Windows sysadmins were too busy cleaning repeated virus infections from a couple of hundred machines.

Re:No

[DamnStupidElf]

It's a complete show stopper when installing in an air-gapped secure room holding the root keys for a certificate authority. The place is RF shielded, no wires enter the room except the well armored power supply, no cell phones or other comms equipment are permitted.

Can't you just turn the computer off at that point?

Re:No

[TechyImmigrant]

>Can't you just turn the computer off at that point?

Not if you want to it do something, like have an OS installed or sign some X.509 certificates.

Re:No

[cavebison]

At work we have purchased a dual processor system with a quad core CPU in each that runs Vista.
Would that be the minimum or recommended spec for Vista?

Re:No

[DamnStupidElf]

Not if you want to it do something, like have an OS installed or sign some X.509 certificates.

How do you actually use the computer once it's sealed away? Do you trust a USB stick or floppy disk not to have any viruses or hardware attacks built into it, or do you have some proprietary dongle to interface with the box? Or do you have to type in the byte values of the hash you want to sign and then write down the signature on a piece of paper?

Basically, if you have a machine that you have to trust so completely that it involves keeping it completely disconnected from the network and protecting it against power analysis (speaking of which, is the power supply flywheel isolated or just full of capacitors and inductors?), then how can you trust any other device that you might connect to the box? I'm not being facetious at this point, I've just never had to deal with systems that are that secure.

Re:No

[walbourn]

Exchange 5.5 was released 11 years ago in 1997. MS spent most of 2001-2003 in a major engineering training effort and a huge security push precisely because of the malware/virus problems that became endemic on the Internet in the late 90s. Large corporations don't change on a dime, but things do change over a decade. Appcompat and features were MS's mantras through the first 20 years. Now security and privacy are now considered more important than those traditional parameters. As I said, /. is stuck in the world of the 90s when it comes to Microsoft.

MS has supported PAE for many years (the technology referenced in the Pentium Pro), although 36-bit addressing mode breaks a large number of 3rd party drivers which is why its off for most versions of Windows. This is a PHYSICAL addressing technology, which is distinct from the VIRTUAL addressing technology that leads to the 2 GB limit for 32-bit standard processes. Even the Pentium Pro only has 32-bits for VIRTUAL addressing. x64 technology and versions of Winodws support 44 lines of PHYSICAL addressing and 64-bits of VIRTUAL addressing given everyone plenty of room to grow the PHYSICAL addressing over time. The high-bit reserveration for kernel-mode exists for both 32-bit and 64-bit processes.

Shick

[Anonymous Coward]

Works for razors - 2 is better than 1, so 3 has got to be better than 2. I'm not switching from Intel until someone comes out with 5 - count 'em, 5! - micro sharp cores...

Re:Shick

[nacturation]

Works for razors - 2 is better than 1, so 3 has got to be better than 2. I'm not switching from Intel until someone comes out with 5 - count 'em, 5! - micro sharp cores... Is this proof of shaving by induction?

Re:Shick

[Jesus_666]

Yeah, but once they get to five cores the processor is becoming too unwieldy to manage small processess well, so they have to add a single sixth core on the backside of the processor. Also, they will have to do TV ads that show two complementarily colored balls of plasma shoot into each other for no apparent reason.

Re:Shick

[vuffi_raa]

I'm not switching from Intel until someone comes out with 5 - count 'em, 5! - micro sharp cores. funny enough, dell has a few dual quad core systems on their site (I had to price some new systems for work last week and we are on a dell contract) so dump your 5 core AMD and go with 8 from intel my friend......
though if they do make 5 core system you can always get a dual 5 core making it a 10 core system.....
that is of course not counting your gpu- which are going dual- pop 2 of those in and you will have 14 cores running mwahahaha

There's no need to wait for any reviews

[Sycraft-fu]

3 cores will be better if you have a use for them. It's that simple. That answer will hold true for any arbitrary number of cores. Basically you need to have a number of threads equal to or greater than your number of cores that each need a lot of CPU time. This could all be from one program that's heavily multi-threaded and CPU intensive, or it could be from multiple applications running at the same time.

For most things, no 3 cores isn't really going to be much benefit at this point. While there are now multithreaded games out there that make use of 2 cores pretty well, they don't really scale past that at this point. I imagine that'll change as time goes on since quad core processors are getting more common, but it hasn't yet. As for desktop apps, well they don't tend to use much power so it won't help much. I suppose it might help responsiveness in some cases a tiny bit, but I doubt it.

However for some professional apps it can help. Cakewalk's Sonar makes use of multiple processors quite handily. Every effect plugin, every instrument, all run as a separate thread so it can easily use a large number of cores. I've seen it run on a quad core system and it distributes load quite well across them. I don't imagine anything would be different with 3 cores, it'd just have one less to use.

Re:There's no need to wait for any reviews

[idiotwithastick]

For most things, no 3 cores isn't really going to be much benefit at this point. While there are now multithreaded games out there that make use of 2 cores pretty well, they don't really scale past that at this point. But now you can play games and encode a dvd at the same time. It's still useful. And at some point or another there will be games that support use of multiple processors, just like there are games now that support physics processors (though few) even though most people don't have one.

Re:There's no need to wait for any reviews

[Kjella]

Unfortunately, that's why I think this processor won't be very useful. If you have poorly threaded applications, then the "one core does the critical task, other core runs the rest" is fine and the third core is almost idle. And if it scales well, then you'll probably benefit from 4+ cores. I guess it all comes down to price but I wouldn't be buying AMD stock, to put it that way.

Re:There's no need to wait for any reviews

[KPexEA]

Q: If you are running 3 apps at the same time will they each be assigned to their own core?

Re:There's no need to wait for any reviews

[compro01]

Q: If you are running 3 apps at the same time will they each be assigned to their own core? A: maybe. that depends on how good the operating system is about managing multiple processors and multiple threads.

Re:There's no need to wait for any reviews

[Antique Geekmeister]

I expect these to be popular for virtualization systems as well, where a spare CPU for the spare OS can do wonders for your performance, and a vastly cheaper set of triple cores can easily satisfy the needs of a few very expensive quad-cores, with an option for upgrades as needed.

Re:There's no need to wait for any reviews

[mpcooke3]

Or to put this another way, my girlfriend can now leave two flash adverts open in firefox on her profile before it totally cripples my machine.

Re:There's no need to wait for any reviews

[glitch23]

For most things, no 3 cores isn't really going to be much benefit at this point. While there are now multithreaded games out there that make use of 2 cores pretty well, they don't really scale past that at this point. I imagine that'll change as time goes on since quad core processors are getting more common, but it hasn't yet. As for desktop apps, well they don't tend to use much power so it won't help much. I suppose it might help responsiveness in some cases a tiny bit, but I doubt it.

A little more than a year ago I went to a Core 2 Duo from an aging Athlon 64. Although I don't have many apps that support multiple threads my system overall is more responsive because, as you stated, the system as a whole can take advantage of the multiple cores by running threads from multiple applications. I consider the difference to be more than a tiny bit because it was definitely noticeable by me the first time I did something using the new CPU that I used to do with the Athlon and I'd have to wait up to 10 seconds for it to happen and now that's down to probably 2 seconds.

I do some video processing but I don't have to do much encoding because the format I work with is already DVD-compliant but TMPEGEnc Editor does support multiple threads if I ever have to re-encode. The other thing is the Core 2 Duo runs much much much cooler than the Athlon64 even under load. The only issue a 3 core system would have is less cores for the job scheduler to spread jobs across, just like a 2 core system has 1 less than a 3 core. The scheduler doesn't care since it isn't doing the real work anyway.

The AMD Triple Track

[fahrbot-bot]

The AMD Triple Track has three cores - one core to cut into the problem, a second to grab what is left before it can snap back into the cache, and a third core to finish it off. The AMD Triple Track, because you'll believe anything!

[For those too young, the reference is the 1975 SNL parody about the Remco Triple Track Razor - done just after twin-bladed razors first appeared.]

Re:The AMD Triple Track

[TubeSteak]

Would someone tell me how this happened? We were the fucking vanguard of computing in this country. The Intel Pentium 4 was the CPU to own. Then the other guy came out with a 64 bit CPU. Were we scared? Hell, no. Because we hit back with a little thing called the Pentium 4 Extreme Edition. That's 3.2GHz and 2 MB of L2 cache. For performance. But you know what happened next? Shut up, I'm telling you what happened--the bastards went to two cores. Now we're standing around with our cocks in our hands, selling 3.2GHz and 2MB of L2 cache. Performance or no, suddenly we're the chumps. Well, fuck it. We're going to eight cores.

http://www.theonion.com/content/node/33930

[The reference is the 2004 Onion parody about a five bladed razor - presciently done just after the Gillette Mach3Turbo first appeared.]

Re:The AMD Triple Track

[Anonymous Coward]

So, we should be expecting a retort from Intel something like this any day now?

The advantage of dual-core...

[SanityInAnarchy]

Ironically, the main advantage of dual-core has nothing to do with applications taking advantage of that second core -- in fact, just the opposite.

Dual-core means that for most cases, I can run a video encode, a backup/compression process, a long-ish compilation (of the sort that doesn't like 'make -j2'), etc -- not so much all at once, as I can fire off any background process and not worry about it, as I have a whole other core to use. It's shameful -- Amarok will occasionally use 100% of one core, and I won't notice for hours.

Having more than two cores wouldn't benefit me a lot right now. I wouldn't mind it, certainly -- I've been playing a bit with things like Erlang, which should be able to scale arbitrarily -- but I think the real applications are only just catching on to the idea that threading is a good thing. I imagine it's still going to be a lot longer till a quad-core machine is useful for anything other than, say, running virtual machines, as most programming languages do not make threading easy. (Locks and semaphores are almost as bad as manual memory management.)

While I'm playing crystal ball, I'll predict that the first application of multicore will be things which were already running on multiple machines in the first place -- video rendering, for instance. Not encoding, rendering.

The second application for it will be gaming. This will take longer, and will only be the larger, higher-quality engines, who will simply throw manpower at the problem of squeezing the most out of whatever hardware is available.

I suspect that the old pattern will be very much in effect, though -- wherein gamers will buy a three-core system and unlock the fourth one (if possible), then use maybe one core, probably half of one, with the video card still being the most important purchase. If there's a perceptible improvement, it'll be because their spyware, IM, torrents, leftover Firefox with 20 MySpace pages and flash ads, etc, won't be able to quite fill the other three cores.

I'd like to add that for most people, including me, one core is plenty if you know how to manage your processes properly -- set priorities, kill Amarok when it gets stuck in that infinite loop, and get off my lawn!

Re:The advantage of dual-core...

[jgrahn]

Dual-core means that for most cases, I can run a video encode, a backup/compression process, a long-ish compilation (of the sort that doesn't like 'make -j2') ...

A broken Makefile, that is. I have them too.

... etc -- not so much all at once, as I can fire off any background process and not worry about it, as I have a whole other core to use. It's shameful -- Amarok will occasionally use 100% of one core, and I won't notice for hours.

I bet you would be mostly fine with one core, too. Nothing really bad happens to overall responsiveness on my system when I have something running at 100%. (That's with Linux; I have a feeling Windows is worse).

The only real usefulness of SMP/multi-core I have seen with my own eyes is on multi-user servers. You can support a lot of simultaneous users with a few cores, because they are usually not likely to all run batch compile jobs at once.

Re:The advantage of dual-core...

[Kuciwalker]

Having more than two cores wouldn't benefit me a lot right now. I wouldn't mind it, certainly -- I've been playing a bit with things like Erlang, which should be able to scale arbitrarily -- but I think the real applications are only just catching on to the idea that threading is a good thing. I imagine it's still going to be a lot longer till a quad-core machine is useful for anything other than, say, running virtual machines, as most programming languages do not make threading easy. (Locks and semaphores are almost as bad as manual memory management.)

In general I'd agree with you, but I've found that a quad-core (which is actually pretty cheap these days) is much better than a dual-core if you watch HD video. h264 at 1080p is pretty taxing on the processor, and on a C2D you generally can't have anything in the background or you'll drop frames. A quad-core means you can run one or two other processor-intensive tasks (usually as you said, video encoding/backup/compilation type stuff) and don't have to pause them when you want to watch video. Also, it's very helpful if you use Mathematica a lot for large computations.

Re:The advantage of dual-core...

[Anonymous Coward]

I have to disagree here. I watch 1080p H.264 video a lot (I even encode some using x264). Using an old version of coreavc (cpu doing all the work, no directx acceleration of any kind) i get ~20% CPU usage on my C2D. If I use a codec that can make use of my geforce 8500gt's video acceleration, it drops below 5%. I never, ever drop a single frame. It must be your video card driver's or the codec you use that's being problematic.

Dual cores are easy to keep busy. Do anything somewhat demanding, and use the other for other everyday tasks. If you do any kind of encoding, that'll utilize both just fine too.

However most quad cores (like the Q6600) have four somewhat slower cores. That will often be significantly slower for apps that can't make use of more than 1 core. And it's a lot harder to keep all 4 cores busy.

Anyways, I really don't know why Dell would bother with this. The Intel e8400 is faster than AMD's unreleased phenom 9700 (which has more cores, and likely clocked higher), and costs like 50$ less than the even slower phenom 9600! AMD just doesn't make anything I want to buy right now. I'm hoping to upgrade to a Intel Q9450 as soon as the price drops a bit (Quad core, 45nm, 12MB cache, runs cooler/uses less power than the Q6600, OC's a LOT better, has SSE4, 1333MHz FSB, etc). And so far phenom had significant problems (requiring BIOS patches making it 10% slower, most existing AM2 motherboards not supporting it, etc) and it doesn't seem to overclock quite as well as Intel's latest either. I don't think the 3 core idea will be popular either. You're essentially buying a partly defective chip, and most people don't like buying partly broken things (would you buy a car with a 4 cylinder engine, if only 3 of them worked?) The price would have to be quite low for me to even consider buying one.

AMD desperately NEEDS to come up with something better REAL soon.

Re:The advantage of dual-core...

[Tweaker_Phreaker]

Agreed, any decent h.264 decoder can run on a ~2 Ghz single core cpu and the great decoders can probably run on ~1Ghz. A lot of video codecs are written poorly (like every single one in quicktime) and don't care because it helps keep hardware sales up.

Core AVC is wicked fast, I just downloaded the Iron Man trailer from quicktime.com and here's some rough figures for the h.264 decoders that I tried on my Athlon X2 running at ~2.5Ghz:
Quicktime - ~80% load
Nero - ~60% load
Core AVC - ~25% load

Re:The advantage of dual-core...

[Fweeky]

Video encoding's been multithreaded in at least some encoders for a while now, some decoders too. Compression can be done multithreaded (e.g. pbzip2, WinRAR), as can generation of par files (I use concurrent par2cmdline for backups). My audio player's supported running NUM_CPU conversion/ReplayGain threads for years.

And yes, even when apps don't use it themselves, SMP's nice; I was doing it 9 years ago when I got my first BP6 and it was great, despite relatively little other than the OS actually making use of multiple cores; that system lasted me years more than a single socket would have. Increasingly though the CPU heavy things that actually make some people plop down £150+ on one are using multiple cores, and even if some do tend to max out around 2 cores, at least quad core lets you run 2 of them at full pelt; that was an advantage a decade ago enjoyed by people willing to spend a bit more, and it's an advantage now.

Of course what actually tends to be an issue more than available CPU is available IO. Being able to run 4 compression/encoding threads at once isn't so hot when each thread's waiting hundreds or even thousands of ms for a HD to get around to servicing them. I expect as core counts go up we'll probably see more consumer level hardware plonking down the extra £40 for RAID-1, or more.

Re:The advantage of dual-core...

[owlstead]

I'm a bit afraid that I will be loosing most of the benefits of a dual CPU (better GUI response) when applications are going to start using all those cores. Even now, if the applications are run from the same disk things get really messy. Of course, flash SSD's may alleviate some of that last problem.

I've had it with my video screwing up when running an IO or CPU sensitive task. The problem is that prioritizing tasks - for both CPU and IO - on current O/S does not really work, and it is starting to hurt.

Re:The advantage of dual-core...

[devilspgd]

Vista is actually much better in this area then previous Windows OSes, if you have a DX10 capable card and an EVR capable media player. The reason is that you can actually have the H.264 video decoding/rendering happening within your video card, rather then having the CPU do the work and output a constantly moving 2D image.

Say what you will about all the eye candy, if you have a decent video card Vista performs far better with the Aero enabled then disabled for the simple reason that Aero is actually using your video card's resources when feasible, rather then doing it all in CPU.

(Also note you can turn off glass, which is transparency, and still leave Aero enabled)

Re:The advantage of dual-core...

[devilspgd]

Using ultra-high density drives with larger cache sizes helps substantially.

Seagate's 7200.11 750GB are a great example, in my informal testing (called "actual use") they do far better then the 36.7GB 10,000 rpm Raptors drives I was using previously, and at a fraction of the $/GB cost.

Re:The advantage of dual-core...

[Anonymous Coward]

"Having more than two cores wouldn't benefit me a lot right now - by SanityInAnarchy (655584) on Sunday February 17, @01:36AM (#22450988) You sure about that?

See, I am not sure what Operating System you use, but, if it is of say for example, modern Windows NT-based OS family variants (2000/XP/Server 2003, &/or VISTA (even older NT variants had SMP support, iirc/afaik, as far back as NT 3.51-4.0 as well))??

You do "take advantage" of more than a single-core, especially if you saturate a core totally... such as you note happens for you, with Amarok.

The OS' process schedulers see to this, for you, IF the code you run as more than 1 thread (1 main, & N child threads), even if only designed as "coarse multithreading"!

("coarse multithreaded design" = Using threads, for doing more than 1 task, not breaking up a single task into threaded operations on said discrete single task. E.G.-> Formatting a spreadsheet on 1 thread, & doing recalcs of cells OR printing the sheet on other threads, for example - OR, playing a game's sound on 1 thread, doing the network code on yet another, & the gaming animation loop on the parent thread).

It works for "fine-grained" multitasking (taking a single task & processing its steps via multiple threads) as well.

APK

P.S.=> I think you'd be surprised how many apps you run today ARE multithreaded design as well - if you have never looked?

Well, on Windows NT-based OS derivants, the taskmgr.exe program can show you that much, using its PROCESSES tab, & selecting columns to view (selecting threads there from the VIEW menu).

Here, for example, I run 35 processes concurrently/simultaneously daily. Of those, 37 bear 2-N threads = 78% of my processes bear more than 1 thread, & thus, potentially I gain quite a bit, & especially if 1 of my programs decides to "hog the CPU", I can keep on multitasking smoothly, because of "implicit control" by the OS' process scheduler subsystem sending threads to CPU cores (or physical cpu's like on a "true SMP" system) as needed... apk

Re:The advantage of dual-core...

[repvik]

I'll tell you another useful bit about SMP. Back in the days when I had two Pentium II (or III?) cpus, I was suckered into clicking a link that got FF and IE to completely freak out and use 101% cpu resources. Fortunately for me this didn't bring my box into a grinding halt like "everybody elses", because they only ran on one of the cores ;-)

Re:The advantage of dual-core...

[Mattsson]

One of the more obvious gains with lots of cores (>2), if matched with lots of memory, is that you can still use your system for games while doing a week long matlab computation and transcoding a dvd into xvid...

Re:The advantage of dual-core...

[llzackll]

What about a program doing a CPU intensive task that isn't multi thread aware? Woul these see any advantage from a multi-core CPU? One reason I ask is because usually the multi core CPU's run at a lower clock speed than the fastest single core CPU's.

Re:The advantage of dual-core...

[Fweeky]

7200.11/ES.2's seem to have very good NCQ firmware, helps keep bandwidth up in face of heavy seeking compared with most other drives.

I went for the WD GreenPower drives, though; let me drop a fan without my HD's hitting 60+c, even if they are significantly slower in most respects.

Re:The advantage of dual-core...

[Anonymous Coward]

Bleh it's windows only and you have to pay for it, how annoying...

Re:The advantage of dual-core...

[SanityInAnarchy]

Well, let's see...

The video itself doesn't necessarily use all of a single core. But even if it does, you still have one more.

There is multithreaded h.264, but it requires that the video was encoded that way, and there's a slight loss in quality (or bit efficiency). This is because, if I understand it, the way multithreaded h.264 works is, it slices the video up, physically. Imagine a vertical bar down your 1080p display -- everything on the left is one thread, everything on the right is the other.

I think it's nice that this kind of thing is supported, in case it's ever useful -- particularly in much higher-resolution video -- but right now, I don't see it being particularly helpful. And again, a lot of the gain is in not having to set thread priority -- if I'm encoding, I generally don't care how long it will take, so I could just set that to the lowest possible priority, and watch all the video I want, even on a single core.

Now, I know how I could fill a quad-core, but none of the uses I can think of really have much everyday utility to me, at least until games start using them properly.

Re:The advantage of dual-core...

[SanityInAnarchy]

I use Linux, and yes, I'm pretty sure. Note that I said "more than dual-core", not "more than a single-core".

Also, simply having more than one thread doesn't necessarily mean it scales to multiple cores. Look at the big scripting languages -- I'm not sure about PHP, but I can say that Perl is at least honest about using green threads, and while Ruby and Python use OS threads, they each have their own variant of a global interpreter lock, meaning that effectively, only one thread can be running a script at a time. I'm sure there are many systems designed like that -- naively "multithreaded", run fine on a single core, but either won't fully utilize a second core, or will actually start crashing.

Regarding your example, let's see... Spreadsheets? Really? Throw it on a single-core, 3 ghz, it'll be fast enough. If not, it's doing something that spreadsheets were never designed to do. Again, dual-core might help, but I really don't see more than that being useful -- not because Excel is necessarily not threaded, but because it couldn't find anything reasonable to do with that extra power.

Or a game -- fine, audio in one thread. Audio that uses maybe 0.5% of the CPU. Networking -- what, 1%? And so on... Games are also the least likely to use languages that scale naturally (like Erlang), because for a long time, they've been programmed in languages like C and C++, trying to squeeze every last ounce of performance out of a single core. The story goes that when John Carmack got a dual-core system (or was it dual-processor?), he tried to make Quake3 multithreaded. In his first attempt, he made it slower than it was single-threaded.

Re:The advantage of dual-core...

[blind biker]

I didn't know Mathematica could use multiple cores! Do you have any estimate of the speedup going from 1 to 2 cores (or from 2 to 4)?

And did you perchance ever try to run Comsol Multiphysics on your quad core machine?

I am trying to gauge if it would be worth for me to upgrade my workhorse for the sake of speeding up some of my scientific work.

Re:The advantage of dual-core...

[devilspgd]

I like the idea of the GP drives, but it's a shame they can't just be honest about their speed and performance -- Not every application needs a fast/powerful drive.

That being said, I'd be very nervous about my drives exceeding 60C on a regular basis, mine are currently reporting under 40C (37C and 39C) via SMART, CPU clocking in around 24C, "motherboard" at around 40C (ambient room temperature is 18C) on a quad-core (Q6600) system with two 7200.11 drives running full blast (about half way through moving 300GB or so from one to the other) in a system that is almost silent.

Re:The advantage of dual-core...

[Anonymous Coward]

"Also, simply having more than one thread doesn't necessarily mean it scales to multiple cores." - by SanityInAnarchy (655584) on Sunday February 17, @08:28PM (#22457790) I never said it did - I only said the OS' of today's process scheduling components can & WILL send other threads to the least used CPU if one of the CPU's/cores gets "saturated" (all cycles used up). This is MOST useful in heavy multitasking scenarios (allowing you to run more backgrounded apps likes services, drivers, & trayicon apps for instance, ontop of regular apps you might use) imo.

----

"I'm sure there are many systems designed like that -- naively "multithreaded", run fine on a single core" - by SanityInAnarchy (655584) on Sunday February 17, @08:28PM (#22457790) On this note? On a single core system, multithreaded code actually has MORE OVERHEADS than single threaded code does, so you know.

----

"Again, dual-core might help, but I really don't see more than that being useful -- not because Excel is necessarily not threaded, but because it couldn't find anything reasonable to do with that extra power" - by SanityInAnarchy (655584) on Sunday February 17, @08:28PM (#22457790) Where you "gain", is under multitasking scenarios, the most - the OS process scheduler sees to it with multithreaded code, sending threads to the least used core, as is needed (usually IF the main core gets saturated, such as you note with this Amarok tool/game you use). Again, imo? This helps MOST, while multitasking diff. apps...

-----

"The story goes that when John Carmack got a dual-core system (or was it dual-processor?), he tried to make Quake3 multithreaded. In his first attempt, he made it slower than it was single-threaded." - by SanityInAnarchy (655584) on Sunday February 17, @08:28PM (#22457790) Well, doing "coarse multithreading" (splitting up discrete separate tasks & data onto separate threads) is not that bad, I do it quite a lot in code I have created (just did a Dr. Who Screensaver for the BBC, submitted it today, which plays the 2005-2008 intro. from said Sci-Fi series & it runs 6 independent threads, mainly for .avi playback, & storing the .avi as a resource in the .scr itself)... it's when you try to do a single task & its constituent parts on multiple threads is where it gets harder... imo, @ least.

& again: On a single-core rig, multithreaded code actually has MORE overheads.

APK

Re:The advantage of dual-core...

[SanityInAnarchy]

I never said it did - I only said the OS' of today's process scheduling components can & WILL send other threads to the least used CPU if one of the CPU's/cores gets "saturated" (all cycles used up).

Thank you, Captain Obvious.

On this note? On a single core system, multithreaded code actually has MORE OVERHEADS than single threaded code does, so you know.

Which makes systems designed this way all the more interesting when they fall apart on a multicore system.

Where you "gain", is under multitasking scenarios, the most - the OS process scheduler sees to it with multithreaded code, sending threads to the least used core, as is needed (usually IF the main core gets saturated, such as you note with this Amarok tool/game you use). Again, imo? This helps MOST, while multitasking diff. apps...

A side note: Amarok is a music player. It has absolutely no excuse to use any amount of CPU at all. That was a bug.

In other words, it helps when:

1. You don't want to deal with setting priorities. I have both my cores saturated now with povray processes, but my system is still perfectly responsive and feels just as fast, as I've set both of those processes at a low priority. It would be roughly the same on a single core. Even with Amarok.
2. You're actually doing something like rendering a couple of povray videos.

Well, doing "coarse multithreading" (splitting up discrete separate tasks & data onto separate threads) is not that bad

Remember that we're talking about Quake 3. If you split it up into nice, neat, "coarse" tasks, you might gain 5% or so over no mutithreading at all -- and maybe lose 5% on the single-core system. I think he did eventually manage to make it work well, but it was not easy.

This comes from the fact that even "coarse multithreading" isn't always easy. If you're using locks and semaphores, I'd argue that any sort of multithreading which must share data -- in Quake3, you're going to need to do culling, AI, physics, etc, all on the same model of the game world -- if you do that with locks and semaphores, it is probably one of the hardest problems in computer science. If you do it with message passing, it gets significantly easier, but it's still possible to have deadlocks, even in a pure message-passing system.

So, in most cases, you've got one core which is doing most of the game, and is saturated or close to it, and the other core is doing audio, compression, network, your standard antivirus, system tray apps, etc, and is at maybe 50%, if you're lucky. So dual-core does help, but three is pretty useless, unless you want to also be doing video encoding, raytracing, etc.

& again: On a single-core rig, multithreaded code actually has MORE overheads.

Are you sure? Played with Hyperthreading much?

Even if this is always true, it's also not necessarily relevant. Multicore systems are getting cheaper, so while it doesn't seem like a must-have to me as a consumer, I absolutely want to target them as a programmer. The classic example that I deal with at work now is, we use Ruby on Rails. The next version of the Ruby interpreter might offer as much as a 3x speedup, and even then, it's significantly slower than, oh, Java. But scalability is more important than performance -- this app runs on Amazon EC2, and if I need to, I can fire up another 20 or so servers, stick a load balancer in front of them, and we'll be able to utilize all of that.

So, sure, Rails is slower than some other solutions, but it's also very scalable, when done right.

(The real irony in that example is that Rails itself is not thread-safe, and that even if it were, Ruby has a global interpreter lock, so it could not utilize more than one core. This is resolved by running more than one Rails process on a single machine and putting a load balancer in front

Re:The advantage of dual-core...

[SanityInAnarchy]

If the computation was going to take a week, I can always drop the priority down and play games anyway, unless I don't have enough RAM. If I play games for a few hours a day, it might mean the week-long computation takes an extra day or so, and does that really matter so much?

Oh, and I'd transcode to h.264, anyway.

Re:The advantage of dual-core...

[SanityInAnarchy]

Short answer: Yes, but not a lot.

Long answer: The advantage is that the single CPU-intensive thread can use an entire core, instead of having to share it with other things that might be running on your system. Except that these other tasks probably aren't using a significant portion of your CPU.

The other advantage, which I think I said in my original post, is that you don't have to worry about prioritization, at least not by yourself. No single CPU-intensive task is going to saturate your entire system. It'll fill one core, and you'll have a whole other core to play with. With a single-core system, you'd have to make sure that CPU-intensive task runs at a low priority if you want your system to be usable for anything else.

Of course, if you're insane, you can always run more than one of those CPU intensive tasks.

In my case, it was a no-brainer. I had a single-core system at 1.8 ghz, which I occasionally overclocked until I found out that it really was unstable at 2.4 ghz. Now I have a dual-2.4 ghz system.

Re:The advantage of dual-core...

[Anonymous Coward]

"Thank you, Captain Obvious." - by SanityInAnarchy (655584) on Monday February 18, @10:52AM (#22463602) Well, you said I said something I never did... & you have the nerve to "toss names" & sarcasm?

"Oh, Please", as the saying goes...

----

"Which makes systems designed this way all the more interesting when they fall apart on a multicore system." - by SanityInAnarchy (655584) on Monday February 18, @10:52AM (#22463602) Funny, mine don't, & I've been building multiple thread bearing coded apps since 1997. Heck, I just submitted one to the BBC today (British Broadcasting Corporation) for their Doctor Who website in fact (a multithreaded avi playing screensaver which plays the intro. to said Sci-Fi series, longest running there is in fact, from the 2005-2008 series in fact)...

It works just fine, & even on a 64mb Pentium II 400mhz I tested it on this weekend running Windows XP no less!

Anyhow, on designing with threads? You get used to it, & what to look out for...

(Myself? I don't tend to do multithreaded ops, on the SAME set of data... I tend to use threads on diff. tasks, the easier method of multithreaded design imo, vs. taking a single set of data OR a single task, & processing it with multiple threads - THIS I STEER CLEAR OF, because imo?? It IS more difficult to conceptualize & get right!)

----

"I'd argue that any sort of multithreading which must share data -- in Quake3, you're going to need to do culling, AI, physics, etc, all on the same model of the game world -- if you do that with locks and semaphores, it is probably one of the hardest problems in computer science. If you do it with message passing, it gets significantly easier, but it's still possible to have deadlocks, even in a pure message-passing system." - by SanityInAnarchy (655584) on Monday February 18, @10:52AM (#22463602) Man...

I've been saying THAT, the whole time here & MANY TIMES NOW!

Thank YOU, "capt. obvious" (especially after I said that first earlier in reply to you here more than a few times now)

----

"Are you sure? Played with Hyperthreading much?" - by SanityInAnarchy (655584) on Monday February 18, @10:52AM (#22463602) Yes, I am - & since 1997 in fact when I first learnt the ways of multithreaded coding really, in both shareware/freeware creation, & industrial environs db work.

----

"And my point is not that there's no performance improvement -- certainly there is" - by SanityInAnarchy
(655584) on Monday February 18, @10:52AM (#22463602) Aha! So, you DO admit there is a gain... & in regards to THIS statement next from you:

----

"but that it's completely unnecessary for most of what we want to do on a desktop system. Even so, I concede that having two cores is handy, and often useful. But more than that just wouldn't be that effective, at least for me, right now, and I could get along just fine with one." - by SanityInAnarchy
(655584) on Monday February 18, @10:52AM (#22463602) Ok, consider this then - what about all the applications in the way of say, backgrounded services &/or trayicon'd minimized apps you could run, & more smoothly, doing your normal workload as well alongside they, IF you have them coded with multiple thread design & with dual (or more) cores (or, physical CPU's in "True SMP")?

Again - the 'gain' is not only some speed, but, also the ability to bear larger workloads & to be able to multitask just as smoothly as ever... & the OS process scheduler sees to this, & especially with multithreaded coded apps!

APK

Re:The advantage of dual-core...

[SanityInAnarchy]

The "Captain Obvious" comment was in response to a statement which is always true. If an OS couldn't send additional tasks to another CPU, there would be no point to multicore at all, would there?

It's a bit like saying "A multitasking OS lets you run multiple tasks at once. You no longer have to stop one task to start another."

Funny, mine don't, & I've been building multiple thread bearing coded apps since 1997.

Good for you.

I've been saying THAT, the whole time here & MANY TIMES NOW!

No, you've been saying "coarse multithreaded", which is a bit different than pervasive message-passing.

Aha! So, you DO admit there is a gain...

Never said there wasn't. How is "there is a gain" inconsistent with "it's completely unnecessary"?

Ok, consider this then - what about all the applications in the way of say, backgrounded services &/or trayicon'd minimized apps you could run, & more smoothly, doing your normal workload as well alongside they, IF you have them coded with multiple thread design & with dual (or more) cores (or, physical CPU's in "True SMP")?

I'm sorry, I'm really having difficulty parsing this one. Correct me if I read you wrong:

Do you mean background processes which are multithreaded and CPU intensive? That's what it looks like... But what does the system tray (or minimization) have to do with that?

If so, then I simply haven't seen many of these. Partly due to this "coarse multithreading" design that is so pervasive, partly due to things like global interpreter locks creeping in where people don't expect them, and mostly due to the fact that I simply don't have that many CPU-intensive background tasks I want to run in the first place, threaded or not.

And if they were written to scale properly, it would actually, in some circumstances, make things worse -- if a video encode can use 100% of 4 cores on a quad-core system, I have to prioritize it down, just as if it was using 100% of 1 core on a single-core system. Where multicore is providing the biggest perceptual gain right now is laziness -- I fire off one background video encode that can only saturate 1 core, maybe spill over a few minor IO threads and such and use 2% of the other core, and I still have most of a core free for anything interactive.

Re:The advantage of dual-core...

[Anonymous Coward]

"No, you've been saying "coarse multithreaded", which is a bit different than pervasive message-passing." - by SanityInAnarchy (655584) on Tuesday February 19, @12:13AM (#22471650) I don't know who you think you're fooling (unless you have ADD or are dyslexic that is), but I did mention single tasks & data being processed by multiple threads, as well as 'coarse multithreading', thru this exchange, more than just once, & prior to yourself.

Anyone can read that much.

"Do you mean background processes which are multithreaded and CPU intensive? That's what it looks like... But what does the system tray (or minimization) have to do with that?" - by SanityInAnarchy (655584) on Tuesday February 19, @12:13AM (#22471650) Easy - & NOT just for "CPU intensive" apps either.

I.E. -> The more CPU cores you have, the more of these backgrounded apps like services OR trayicon minimized apps (multiple threads (or not)) you can run across said cores!

(& thus, you'd be able to run more of them @ once due to the presence of multiple CPU cores (or, physical CPU's present, such as a true "SMP" rig has) & SMOOTHLY (or, moreso, even if you have a "CPU HOG" of an app, such as you noted Amarok could be (due to bug)).

Doesn't only mean for multithreaded apps either...

E.G.-> There is NOTHING stopping the OS' process scheduler subsystem from sending single thread designed apps to the 2-N cpu cores present either, mind you.

This also extends to services as well as trayicon'd minimized apps running...

APK

Re:The advantage of dual-core...

[SanityInAnarchy]

Disclaimer before I begin: When I say "core", I really mean "core and/or CPU". I mean this because multiple CPUs do still have cores, so calling a multi-CPU system "multicore" isn't that innaccurate, whereas calling a dual-core system "multi-CPU" is wrong. Also, "core" sounds better than "CPU".

I did mention single tasks & data being processed by multiple threads, as well as 'coarse multithreading'

Also not the same thing as pervasive message passing.

& prior to yourself.

If you want to play the "me first" game, I mentioned Erlang before you entered this thread. Erlang takes the model you describe to an extreme -- a well-designed Erlang system could have hundreds, or thousands, of "processes", all of which communicate via message-passing alone. And note again, this is orthogonal to what you describe -- you may or may not be using message passing to do what you do, and an Erlang program may or may not be operating on the same data, or even somewhat "shared" data -- although Erlang would tend to encourage sharing less rather than more, when appropriate.

I should note also that I mentioned Erlang with the assumption that anyone interested would look it up (apparently you didn't), and with the full knowledge of what an Erlang-like system does. And I should also note that even in an Erlang program, it's possible your app doesn't scale as well as you think it does, and it's even possible you'll get some unexpected synchronous-ness, although I admit that is rare. But it's also hard to test for without actually running it on a multicore system.

I.E. -> The more CPU cores you have, the more of these backgrounded apps like services OR trayicon minimized apps (multiple threads (or not)) you can run across said cores!

And if they're not CPU-intensive, what's the point, honestly? If they're not CPU-intensive, they don't need to be threaded at all, just shove them all to an unused core; they probably won't fill it.

If you're not running anything CPU-intensive, hey, a single-core system still has a mostly-unused core. If you're running one thing that's CPU-intensive, shove them to that second core, which is in line with what I keep saying: Dual-core is fine and useful, but more than two isn't going to do much, most of the time.

(& thus, you'd be able to run more of them @ once due to the presence of multiple CPU cores (or, physical CPU's present, such as a true "SMP" rig has) & SMOOTHLY

Maybe "not CPU-intensive" isn't sinking in.

Right now, I'm on a laptop -- dual-core, 2ghz. I have 158 processes running. My system hasn't had more than 5% CPU used, and generally less than two. These processes include things like MySQL (just in case I want to do some Rails development, even though I'm using SQLite, but I haven't disabled MySQL yet), Kopete (for IM), ssh, Konqueror with, oh, eight tabs, Firefox with four tabs (all Google apps), a few virtual-machine related stuff (DHCP server, virtual switch, etc) in case I should want to fire up an XP machine, and so on.

Oh hey, and there's a Rails console sitting open... and four other Konsole windows I'd forgotten about on another desktop. Some of it might even be swapped out by now.

And it all still uses less than 5%. If we assume that's distributed fairly, and we take the 5% number (which is generous; it's more like 2%), it'd still be less than 10%.

E.G.-> There is NOTHING stopping the OS' process scheduler subsystem from sending single thread designed apps to the 2-N cpu cores present either, mind you.

Except a distinct lack of 2-N single-threaded apps needing to use a significant amount of CPU on a typical desktop. That was my point.

Go back to my original post, where I mention raytracing and make -jN. Povray isn't threaded itself; I'd have to run more than one of them, but I'm sure, given a big enough ani

Re:The advantage of dual-core...

[SanityInAnarchy]

Here's what I do on Linux:

First, kill anything that would be stressing the video card. I really don't know how to prioritize this, or even to get any sort of report on what's using my video card, how much RAM, how many pipelines, etc. For now, it should still be pretty easy. If Flash starts getting hardware accelerated, flash ads in your browser will lag you horribly.

Next, find any task that's using CPU and renice it down:

renice 40 -p `pidof a_huge_app`

And finally, play your movie at the highest priority:

sudo nice -n -20 mplayer -cache 102400 foo.mp4

There's probably a GUI somewhere for doing something similar. Point is, I've gotten CPU prioritization to work reasonably well -- I suppose YMMV? -- and I don't care much about IO prioritization when I've stuck a 100 meg buffer in front of it, especially as any OS or filesystem that can handle that much traffic in the first place should serve my process in a reasonable amount of time.

Then again, maybe that last point is mostly because I've got a RAID-0 system at home.

Re:The advantage of dual-core...

[Anonymous Coward]

- by SanityInAnarchy (655584) on Wednesday February 20, @03:12AM (#22485350) When I mentioned "coarse multithreading" as a method of designing a way to use multiple threads in a program (taking diff. threads & doing diff. tasks with them & with diff. data)?

"Coarse Multithreading" IS THE EXACT OPPOSITE OF "fine grained multithreading" (as I call it, & that's taking a single task &/or single data set + processing its data & steps via multiple threads)...

I did that , to show 'extremes', this is all. Does YOUR 'pervasive messagepassing' (sounds like a normal Win32 message queue passing & scrubbing/reading messages system basically) fit the bill as a complete opposite, as does "fine grained" multithreading (vs. "coarse" multithreading)?

----

"Yes, that's also painfully obvious." - by SanityInAnarchy (655584) on Wednesday February 20, @03:12AM (#22485350) Then, why did I have to mention it for you then??

----

"Except a distinct lack of 2-N single-threaded apps needing to use a significant amount of CPU on a typical desktop. That was my point." - by SanityInAnarchy (655584) on Wednesday February 20, @03:12AM (#22485350) You don't get it, do you? If you have enough of them running, they can 'eat up' a single core CPU setup's cycles, just like anything could eventually in enough numbers... that is the point I was making:

I.E.-> With a dual (or more) CPU setup, you can count on being able to do more than you could with a single CPU/core setup, just by the fortune of having another core to field program interrupts.

E.G.-> By having another CPU/core to use, you could run more programs, more smoothly, & multitask just as smoothly as ever because of the presense of the OS scheduler sending threads to CPUs/cores, as needed (when needed, usually in HIGH CPU usage situations - give me enough 4%-5% cpu using apps, even trayicon'd ones? The other core will HAVE to be used @ some point).

----

"As far as I'm concerned, the only difference between "system" processes and "trayicon" apps is that I've never seen a system
tray app owned by root, whereas daemons (system processes) are owned by root, nobody, real users, or few dozen app-specific users" - by SanityInAnarchy (655584) on Wednesday February 20, @03:12AM (#22485350) Applications (run under Windows @ least) run under the context of the user logged on, & with his rights + abilities (down to ACL levels)...

Additionally, for services (Windows NT-based OS version of *NIX "daemons"), you can change logon entities for services easily enough (using services.msc & the properties for a service, in its LOG ON tab there), from the std. Local System, to Network Service, to Local Service (each is ordered in decreasing 'power' order here)... &, even OTHER users (both existing & ones you can fabricate yourself, using lusrmgr.msc even).

APK

P.S.=> Ahhh, now, finally - "TIME FOR COFFEE" (I need consciousness fuel)... apk

Re:The advantage of dual-core...

[SanityInAnarchy]

I did that , to show 'extremes', this is all. Does YOUR 'pervasive messagepassing'

Erlang's, but thanks for the compliment.

(sounds like a normal Win32 message queue passing & scrubbing/reading messages system basically) fit the bill as a complete opposite, as does "fine grained" multithreading (vs. "coarse" multithreading)?

They are orthogonal. It does, however, make it easier to do fine-grained stuff.

And no, it's not a new idea -- Win32 didn't invent it either. But do me a favor, run a "ring benchmark".

Write a function that spawns N threads in a ring. That is, thread A connects to thread B, which connects to thread C, and eventually comes back around to thread A.

Now, send M messages around the ring.

How big can N get before you run out of RAM, or your system slows to a crawl? What's the relationship between M and the time it takes to execute?

On Erlang, I just had it spawn 100,000 processes and send 1,000 messages, and it took just under 14 seconds. Reversed those numbers -- spawned 1,000 processes, sent 100,000 messages -- and it took 26.7 seconds. Neither way used more than about 20 megs of RAM.

Understand, I'm not including this as a proof of raw performance, just as proof of the paradigm -- the language itself makes it easy to spawn ridiculous numbers of threads, and the runtime can handle it. They are green threads, but with SMP enabled, Erlang spawns exactly as many real OS threads as you have processors, and schedules green threads between them. Which means you get the best of both worlds: You can spawn literally one thread per function if you want, with minimal overhead, but you'll also automatically scale to the number of physical cores in use.

Now, if your Windows threads are anything like my POSIX threads, it's not going to take anywhere near a hundred thousand threads (around a thousand of which are actively vying for CPU time) to slow your benchmark to a crawl, and quite possibly overwhelm your OS scheduler.

Then, why did I have to mention it for you then??

You didn't. Read the paragraph after the one you're quoting.

You don't get it, do you? If you have enough of them running

But you see, I don't. Most people don't. This is the point you are missing.

By having another CPU/core to use, you could run more programs, more smoothly

Right now, I'm running email, IM, an MMO (under Wine), an IRC client, a web browser, and a povray instance. I simply don't have more programs that I want to run right now. That's not to say that I couldn't max out an eight-core system, if I just wanted to prove a point.

give me enough 4%-5% cpu using apps, even trayicon'd ones? The other core will HAVE to be used @ some point).

Yeah, at 4-5%, that's, what, 25 of them? Keep in mind, I have less than 5% used, total, among my seven system tray icons and 151 processes, not including povray. That means, depending on how you count, they are using on average a little less than 1%, or a little more than 0.03% each, meaning it would take either 120 system tray icons, or over 3000 processes, before it hits that other CPU. Let's pretend that I'm way off and the OS will spend 50% of the time scheduling -- I still don't have 60 system tray apps, and I have never seen my Linux system have 1500 processes except when I was playing with forkbombs. And I don't see either happening in the near future -- again, unless I'm playing with forkbombs.

Now, for this next part: You've just basically told me that Windows behaves the same way as Linux, in this regard. Maybe you don't know the terminology I was using. Or maybe you do, and were just pointing out what I'm about to:

Applications (run under Windows @ least) run under the context of the user logged on, & with his rights + abilities (down

Re:The advantage of dual-core...

[Anonymous Coward]

"Erlang's, but thanks for the compliment." - by SanityInAnarchy (655584) on Thursday February 21, @12:00AM (#22498848) That doesn't answer the question I asked: Does "pervasive message passing" function as an example of an exact opposite of "coarse multithreading" as do mine for "fine grained multithreading"?

I hadn't heard of that term applied to anything in terms of designing paradigms for multithreaded code (ala "coarse multithreading" (a thread to each discrete dataset/task) vs. "fine grained multithreading" (a single task/data set having its data processed by multiple threads), & this is why I have asked...

----

" I still don't have 60 system tray apps, and I have never seen my Linux system have 1500 processes except when I was playing with forkbombs. And I don't see either happening in the near future -- again, unless I'm playing with forkbombs." - by SanityInAnarchy (655584) on Thursday February 21, @12:00AM (#22498848) Forking processes is a LOT heavier than threadwork. When you do a *NIX "fork", you are spawning a completely NEW process, not just a lighter-weight thread, by the by... & I have had my system up to 60 backgrounded apps before (the majority bearing 2-N threads too, mind you, with only a small %-age bearing a single thread only).

I.E./E.G.-> Right now (again):

I have 37 backgrounded trayicon & services running... of those, 27 bear 2-N threads.

(That is over 78% worth of my processes that run backgrounded that gain because of OS process scheduler subsystems sending threads, as needed (usually in the case of cpu cycles starvation on the main CPU core), to 2-N cpu cores/cpus available).

APK

Re:The advantage of dual-core...

[SanityInAnarchy]

That doesn't answer the question I asked: Does "pervasive message passing" function as an example of an exact opposite of "coarse multithreading" as do mine for "fine grained multithreading"?

Read the paragraph below the one you quoted! I did answer your question.

Forking processes is a LOT heavier than threadwork. When you do a *NIX "fork", you are spawning a completely NEW process,

It's also done copy-on-write, so it's very fast when your forked process doesn't change much compared to the original. Threads are faster, though.

And none of this is relevant to the current discussion.

I have 37 backgrounded trayicon & services running... of those, 27 bear 2-N threads.

How many of those are actually using a significant chunk of CPU?

(That is over 78% worth of my processes that run backgrounded that gain because of OS process scheduler subsystems sending threads, as needed (usually in the case of cpu cycles starvation on the main CPU core), to 2-N cpu cores/cpus available).

And if they are, collectively, using less than 5% of one core, then your performance gain for those processes being threaded is:

• 0 with no CPU-intensive tasks running (unloaded is unloaded, period).
• One CPU-intensive thread will run 5% faster on a dual-core system than on a single-core.
• Two CPU-intensive threads will each run 2.5% faster if a third core is available.

Re:The advantage of dual-core...

[Anonymous Coward]

"Read the paragraph below the one you quoted! I did answer your question." - by SanityInAnarchy (655584) on Thursday February 21, @07:37PM (#22509980) Well, imo? Not really - how does "pervasive message passing" function as a COMPLETE OPPOSITE, in terms of design, vs. "coarse multithreading" - taking separate data & processing it using diff. threads ("fine grained multithreading" definitely does - taking a single task/single data set & processing it using multiple threads)).

----

"It's also done copy-on-write, so it's very fast when your forked process doesn't change much compared to the original. Threads are faster, though." - by SanityInAnarchy (655584) on Thursday February 21, @07:37PM (#22509980) "Copy-On-Write" uses less memory, & its functionality ONLY takes over when you have two (or more) users accessing the EXACT same data via pointers to it, which are using more than a single instance of a given program (that manages said single set of SAME data) - &, when 1 user makes a change, & THEN ONLY, does it do any work (if changes ARE indeed made by any users of the program making changes to the shared data involved).

This is all & again: IF NO CHANGES ARE MADE? This NEVER happens, period.

Threads additionally (again), are much "lighter" to instance, than an entire process (as forking does, vs. spawning extra threads).

----

"And none of this is relevant to the current discussion." - by SanityInAnarchy (655584) on Thursday February 21, @07:37PM (#22509980) It's VERY relevant, so that others can gain by it, & it IS "on topic" (about possible gains using multiple thread designed code + multiple CPU/cpu core setups).

----

"How many of those are actually using a significant chunk of CPU?" - by SanityInAnarchy (655584) on Thursday February 21, @07:37PM (#22509980) A few - but, the point is NOT so much about them (though, using multiple cores + multiple threads in backgrounded trayicon minimized apps &/or services can help per our discussion where you even note gains are possible using multiple thread designed apps + multiple CPU cores in combination with them)... it's more about what happens when you have a "CPU Hog" of an app...

Like you said you have/had in "Amarok" taking up 100% of a CPU core on you... the OS' process schedulers of today (Windows & *NIX variants, probably Os/2 even, in its SMP capable builds) makes it so that when your MAIN cpu core is saturated? Other threads will be sent to less used up CPU cores (this is not only for multithreaded apps, but also single threaded ones too).

APK

Re:The advantage of dual-core...

[SanityInAnarchy]

Well, imo? Not really - how does "pervasive message passing" function as a COMPLETE OPPOSITE, in terms of design

It doesn't. I will give this one more try...

"Pervasive message passing" is a feature of language, or the framework. It's like object-orientedness, or garbage collection. It's a property of the tool.

"Coarse multithreading", as you've explained it, is a methodology. So is "fine-grained multithreading". These are like, oh, model-view-controller. You can implement model-view-controller with an object-oriented language, or, if you really want, you can implement it in a purely-functional language (like Haskell), or in a language without even a concept of a subroutine (BASIC with GOTOs), etc... you can do it in a language with garbage collection or without...

What's more, "coarse" and "fine-grained" are relative and a matter of opinion. How do you define a "task"? And keep in mind that while having thousands of threads sounds like "fine-grained", they are not sharing data, except by passing messages back and forth...

This is all & again: IF NO CHANGES ARE MADE? This NEVER happens, period.

Exactly.

Threads additionally (again), are much "lighter" to instance, than an entire process (as forking does, vs. spawning extra threads).

Sigh...

Apparently, you still don't get it, even though you just tried to explain copy-on-write to me. fork() on Linux is implemented as copy-on-write, and has very little overhead. Linux sees threads and processes as essentially the same thing.

The overhead of using processes instead of threads is pretty much irrelevant, especially if you were going to use message-passing in the threads, even moreso if you're intentionally doing "coarse multithreading". Of course, you could also use shared memory between processes.

And yes, all of this is Linux-specific. Forking a process on Windows is much slower.

A few - but, the point is NOT so much about them

No, the point is that, originally, I said that I would not see any real improvement if I had a quad-core system instead of dual-core.

it's more about what happens when you have a "CPU Hog" of an app...

You seem to be operating in a fantasy world where:

1. I have more than one app that wants to saturate a core
2. I do not have the ability to set the priority of these apps lower
3. I absolutely need my one app to run at 100% of that one core, rather than 90% of it. (Especially ludicrous as you keep bringing up Amarok -- if Amarok is using 100% CPU because of a bug, forcing it to use 90% isn't going to cause problems.)
4. I was saying that dual-core is actually useless to me -- it's not. It just means I don't have to do item #2, above.

I never said or implied that multicore would never be usable, or that it was useless to everyone. I was merely speculating that most people are probably in the same situation I am.

Furthermore, most of the points you bring up, I knew, but didn't think they were relevant to the discussion. Had you been paying attention, you might have noticed that I was specifically making a statement about how completely irrelevant the deep technical details are to the point of whether dual-core is useful to the general population -- most people I know would never notice a machine they were using was dual-core until you pointed it out to them.

Re:The advantage of dual-core...

[Anonymous Coward]

"It doesn't." - by SanityInAnarchy (655584) on Saturday February 23, @06:18PM (#22530138) Yes, I know your mention of "pervasive message passing" doesn't function as what I stated, period, as an opposing design method to 'coarse multithreading' (as does "fine grained" multithreading, which I mentioned).

----

""Coarse multithreading", as you've explained it, is a methodology. So is "fine-grained multithreading"" - by SanityInAnarchy (655584) on Saturday February 23, @06:18PM (#22530138) Which was my point, to a tee - to extoll diff. methodologies used... simple. You went 'off track' basically...

----

"Apparently, you still don't get it -

Beg to differ: I have caught you saying things that are blatant errors, using your OWN words no less (I close this post on that very note in fact)...

----

"even though you just tried to explain copy-on-write to me. fork() on Linux is implemented as copy-on-write, and has very little overhead. Linux sees threads and processes as essentially the same thing." - by SanityInAnarchy (655584) on Saturday February 23, @06:18PM (#22530138) BUT, they are NOT THE SAME THING...

POINT-BLANK/FACT: Forking entire processes is much heavier than thread spawning, period... & you admit it is faster to use threads as well (& more efficient period) earlier!

----

"And yes, all of this is Linux-specific. Forking a process on Windows is much slower." - by SanityInAnarchy (655584) on Saturday February 23, @06:18PM (#22530138) I NEVER ONCE SAID IT WASN'T, first of all... BUT, the smallest atomic unit of execution (afaik, because I have not seen fibers implemented on Windows to date) is threads, & it IS what is typically used (IF you want speed & efficiency on Windows, & this you concede is possible using threads).

Heck, it took LINUX the longest time just to have a TRUE thread model (not just usermode threads, that spun out to a single kernel mode one that "round-robined" thru the usermode 'threads'... &, it is what held back LINUX from SMP usage period, for years & out of "industrial environs" because of a lack of SMP readiness!)

----

"You seem to be operating in a fantasy world where:
I have more than one app that wants to saturate a core" - by SanityInAnarchy (655584) on Saturday February 23, @06:18PM (#22530138) Uhm, didn't you state this "amarok" program did that to you here, earlier?

APK

Re:The advantage of dual-core...

[SanityInAnarchy]

Which was my point, to a tee - to extoll diff. methodologies used... simple. You went 'off track' basically...

YOU replied to ME. I like to think that I was on track with my original comment.

Beg to differ: I have caught you saying things that are blatant errors, using your OWN words no less (I close this post on that very note in fact)...

So the best you've got is nitpicks. Nitpicks in which you are wrong. Your reading comprehension is as low as ever.

BUT, they are NOT THE SAME THING...

I did not say they were. They are treated the same way by the Linux scheduler, is all.

Oh, and this also ignores the part where the performance difference is irrelevant. Oh noes, it takes one millisecond instead of 0.3 to start a new process. Guess I better leave them in threads... Or maybe I can split tasks into separate processes and users, gain some security and stability (one process can completely blow up, and be restarted by another)...

Uhm, didn't you state this "amarok" program did that to you here, earlier?

As a bug, meaning when it does this, I kill it...

And since when does one program constitute "more than one app"?

Re:The advantage of dual-core...

[Anonymous Coward]

"YOU replied to ME. I like to think that I was on track with my original comment." - by SanityInAnarchy (655584) on Sunday February 24, @01:31PM (#22536548) And, this changes WHAT, exactly? Your "pervasive message passing" is NOT a design paradigm for multiply threaded apps, period.

----

"Oh, and this also ignores the part where the performance difference is irrelevant. Oh noes, it takes one millisecond instead of 0.3 to start a new process." - by SanityInAnarchy (655584) on Sunday February 24, @01:31PM (#22536548) Performance you even NOTED & ADMITTED, is better using threads... first of all - SECONDLY, you are now omitting the fact that forking ENTIRE PROCESSES is not only SLOWER, but also is heavier in RAM as well!

----

"As a bug, meaning when it does this, I kill it... And since when does one program constitute "more than one app"?"" - by SanityInAnarchy (655584) on Sunday February 24, @01:31PM (#22536548) A buggy Linux app... gee, "will wonders NEVER cease"... and, when that one program eats up your CPU, bug or not? When you compound its load with other apps you run (background daemons/services OR otherwise like trayicon apps)?

Multithreaded design assures the system should keep multitasking smoothly... just based on the implicit control the OS' process schedulers of today can do, especially with multithreaded apps (&, even single thread designed ones no less)

APK

P.S.=> Also, it's rather funny how you avoided the part about LINUX's intially designed "thread model" too, which I mention, which held them back for YEARS in terms of SMP support, & thus, also "enterprise class ready" certification on HIGHER/HEAVIER 'industrial strength' levels... & they instead had to copy a "Windows-like" kernel mode thread model!

(LOL, just like they have had to make KDE more like Windows... TO BEAT WINDOWS? YOU HAVE TO FIRST BECOME EQUAL TO IT - & Linux still it not that, nor, superior by ANY means! Especially in terms of peripheral hardwares support)... apk

Re:The advantage of dual-core...

[SanityInAnarchy]

Disclaimer: I'm no longer answering your off-topic comments. Your attempt to turn a discussion on threading into Linux vs Windows is neither welcome nor appreciated. And that's ignoring that the original discussion was not about threading.

And, this changes WHAT, exactly? Your "pervasive message passing" is NOT a design paradigm for multiply threaded apps, period.

Where did I say it was?

you are now omitting the fact that forking ENTIRE PROCESSES is not only SLOWER, but also is heavier in RAM as well!

By a few bytes, yes. Does the concept of "copy-on-write pages" still elude you?

and, when that one program eats up your CPU, bug or not? When you compound its load with other apps you run (background daemons/services OR otherwise like trayicon apps)?

I'm sorry, was there a question in there?

If the question was "what do you do", you already know the answer, if you would read before replying, which you never seem to be able to do.

Re:The advantage of dual-core...

[Anonymous Coward]

"By a few bytes, yes. Does the concept of "copy-on-write pages" still elude you?" - by SanityInAnarchy (655584) on Sunday February 24, @06:59PM (#22539876) Uhm, wasn't I the one who posted its formal definition (more-or-less) rather than yourself, & also examples of WHERE/WHEN/WHY "copy on write" functionality takes place here, & first (ONLY is more like it)? Well, that ONLY TAKES PLACE IF TWO OR MORE APPS ARE SHARING DATA (say, in a document both users are making edits to)... IF THAT DOES NOT HAPPEN? Copy on write, never even TAKES EFFECT, period.

----

"By a few bytes, yes" - by SanityInAnarchy (655584) on Sunday February 24, @06:59PM (#22539876) Again, you concede that multithreaded apps are not only leaner, but earlier you admitted/conceded they are FASTER, & I pointed out they are lighter than FORKING ENTIRE PROCESSES (on more than just a few levels)...

Can't you admit where you are wrong/off, once you have said 1 thing & then stated another later that contradicts it, AFTER I POINT THEM OUT TO YOU?

Apparently not!

APK

Re:The advantage of dual-core...

[SanityInAnarchy]

Well, that ONLY TAKES PLACE IF TWO OR MORE APPS ARE SHARING DATA

Like, I don't know, executable code? Or, yes, a document!

Like, maybe, the same things that would be shared with threads!

And if you're not sharing data with threads, the performance improvement is not significant. It's the kind of thing which might easily be sacrificed for stability or security. By the time you've got enough overhead from running separate processes, it might be time to look at partitioned green threads (Erlang-style) anyway.

Can't you admit where you are wrong/off

It would help if you showed me where. I say "not significant", and you hear "not at all". Let's find my original quote:

Forking processes is a LOT heavier than threadwork. When you do a *NIX "fork", you are spawning a completely NEW process,

It's also done copy-on-write, so it's very fast when your forked process doesn't change much compared to the original. Threads are faster, though.

This was as a reaction to your capslock emphasis on spawning a completely NEW process -- which is incorrect, by the way, as I've shown repeatedly; copy-on-write means that the new process is not entirely new, as it shares some memory with its parent.

I have never once said that processes are exactly as fast to spawn, or use exactly as much RAM, as threads. In fact, I'm not sure why you mentioned this, originally -- you were replying to:

I have never seen my Linux system have 1500 processes except when I was playing with forkbombs. And I don't see either happening in the near future -- again, unless I'm playing with forkbombs.

Perhaps you don't understand what a forkbomb is? Hint: It's not intended to be efficient. It's intended to be the opposite of efficient.

Re:The advantage of dual-core...

[Anonymous Coward]

"I have never once said that processes are exactly as fast to spawn, or use exactly as much RAM, as threads" - by SanityInAnarchy (655584) on Monday February 25, @08:46PM (#22553770) Didn't you state you would see NO GAINS using more than 2-N cores? OR, more than dualcore machines??

Yes, you did.

I merely am showing that the MORE MULTITHREADED APPS you have (&, even not, because of modern OS' of today's process schedulers) alongside MORE CPU CORES present, the more you can multitask & more smoothly... & ESPECIALLY if you have a "CPU Hog" of an app (i.e. -> 1 that sucks up the ENTIRE 100% of a CPU).

The OS' process schedulers will then take remaining child &/or parent threads, & send them off to available & unsaturated CPU cores present... &, the more CPU cores present you have w/ a modern OS? The more smoothly you can operate still, and do so with MORE APPS running concurrently/simultaneously.

Simply because the CPU CORES are present & the OS process schedulers take advantage of them, sending said aforementioned threads off to the unsaturated CPU cores present, even IF 1 CPU core is dominated by a single CPU hog of a process (like you noted Amarok did to you).

----

"Perhaps you don't understand what a forkbomb is?" - by SanityInAnarchy (655584) on Monday February 25, @08:46PM (#22553770) Look - don't even TRY to insinuate "I don't understand something" (or, toss names as you have, like your "Capt. Obvious" b.s.), like you have several times here - I have had to show you in error many times, and then after that, you have HAD to concede I was correct.

I had to point out that forking ENTIRE processes is much "heavier" & resource intensive, than it is using threadwork instead, for 1 example here.

(ABOVE ALL ELSE, though - I know one thing: I could put out a body of evidence here of things I have done that did really well in commercial softwares (or shareware/freewares for example), OR, times I have been in publication (written hardcopy form in publications in this field such as Windows IT Pro mag, PCWorld, Books & newspapers as well) in the field of computer science, that I KNOW, you can't touch, or... that YOU have NEVER DONE (& probably never will, as long as you waste time on /.)...

So, please - cut that crap right out already, ok?

APK

Re:The advantage of dual-core...

[SanityInAnarchy]

I had to point out that forking ENTIRE processes is much "heavier" & resource intensive, than it is using threadwork instead, for 1 example here.

And you have never been able to show that I wasn't already aware of that. Here, let me adopt your tactic for a moment:

OMG! I had to point out what a forkbomb is! You must not have known!!!111!!!one. Now let me reiterate for the next ten posts: I know what a forkbomb is and you don't. A forkbomb is a process which forks itself over and over. A forkbomb is a PROCESS which FORKS ITESLF over and over! Oh, and by the way, I know what a forkbomb is and you don't.

Is this all you've got? If so, this discussion is over -- you're clearly not willing to discuss the real issue here.

probably never will, as long as you waste time on /.

Look who's talking.

For that matter, from how rarely you even grammatically make sense here, I'm surprised you were published at all, even in PC World.

Re:The advantage of dual-core...

[Anonymous Coward]

"Look who's talking." - by SanityInAnarchy (655584) on Tuesday February 26, @11:53AM (#22559940) Not just "talking", like yourself... but, in MYSELF?

Actually DOING:

WINDOWS NT-Magazine (forerunner of today's .NET magazine) 1997 (iirc, Oct. issue pg. 83) issue review by Mr. John Enck, a technical editor of theirs for SuperCache & SuperDisk by EEC Systems (now SuperSpeed.com - first part was writing up an article featured on their corp. website alongside Mr. Enck no less, about the technical effective uses of Ramdisks, & the latter was on PAID CONTRACT to improve the mathematics & algorithm for tuning their SuperCache product w/ a programmatic addon they shipped w/ their product, & now is incorporated into the main program itself (Mr. Eric Dickman is their CEO iirc, & offered me a job w/ them back in 2003, but life took me to NYC instead of BOSTON) - they ARE A CERTIFIED Microsoft Partner you know, by the by)

WINDOWS MAGAZINE, 1997, "Top Freeware & Shareware of the Year" issue page 210, #1/first entry in fact (my work is there)

PC-WELT FEB 1998 - page 84, again, my work is featured there

PC-WELT FEB 1999 - page 83, again, my work is featured there

CHIP Magazine 7/99 - page 100, my work is there

WINDOWS MAGAZINE, WINTER 1998 - page 92, insert section, MUST HAVE WARES, my work is again, there

GERMAN PC BOOK, Data Becker publisher "PC Aufrusten und Repairen" my work is contained in it

HOT SHAREWARE Numero 46 issue, pg. 54 (PC ware mag from Spain), my work is there, first one featured, yet again[/b]

So... How about you, by way of comparison?

----

"And you have never been able to show that I wasn't already aware of that" - by SanityInAnarchy (655584) on Tuesday February 26, @11:53AM (#22559940) No, I showed you were TRYING to "pull the wool over my (& any other readers' eyes) w/ attempted 'techno babble' @ most... & I had to point out that:

Forking processes is heavier on nearly every level vs. threads

Copy-on-write functionality only taking place if data is shared between an app run by multiple usersMultiple thread designed apps, via today's modern OS' process scheduler kernel level subsystems, allow for smoother multitasking (especially if you run into CPU hog type apps)

& more...

APK

P.S.=> ... & that list of mine's been growing since 1996 in publication, working continuously in this field professionally as well since 1994, & actually doing well not only in the shareware/freeware creation arena, but also in commercially sold applications as well... apk

Re:The advantage of dual-core...

[SanityInAnarchy]

Not just "talking", like yourself... but, in MYSELF? Actually DOING:

Great, thanks for proving my point.

Now, why the irrelevant insult about wasting time on Slashdot? Is it possible that you have no valid points left? Maybe you never did?

I had to point out that: Forking processes is heavier on nearly every level vs. threads

Why?

No, seriously, let's pretend that I didn't know that. Let's pretend that when I said "no significant difference", what I really meant was "No difference at all! Everyone should use OS processes!"

In fact, let's ignore the fact that these "full OS processes" on some platforms are faster than "OS threads" on other platforms. Let's not even bring up which platform is which.

What relevance does this possibly have to the current discussion?

Put it back in context. I know you can do it, I just don't know why it always takes five posts to force you to make the connection...

It matters very little whether we talk about the 130 or so processes that are running on my laptop now, or the 150 or so threads. Either way, they are using less than 10% of one core -- or, more likely, less than 5% of each. You suggested that background threads could actually add up to fill one core:

You don't get it, do you? If you have enough of them running, they can 'eat up' a single core CPU setup's cycles, just like anything could eventually in enough numbers... that is the point I was making:

Have you retracted this position?

Because this means, at the current rate -- that is, assuming the kinds of background processes I currently run -- I would need 10 times as many running as I have now before they filled up a core. And that's on my laptop, which is slower.

In that context, the choice of threads vs processes is completely irrelevant. The programs are already written. And even assuming processes are ten times slower (which they aren't), that only further proves my point -- I'm running a pile of (according to you) inefficient background processes that still don't eat up a tenth of one core. Were they more efficient, it would just mean it would take me doing that much more than ten times as much as I do now before triple core buys me anything more than faster povray renders.

Do any of the articles you linked to make the above untrue? Do any of them prove that a typical desktop user gives a flying fuck how efficient the multitasking is, as long as it feels fast?

Or have you managed to prove yourself as even more of a clueless geek than I am?

Re:The advantage of dual-core...

[Anonymous Coward]

As to "valid points"?

"Or have you managed to prove yourself as even more of a clueless geek than I am?" - by SanityInAnarchy (655584) on Wednesday February 27, @02:26PM (#22577204) Don't put me in the same category as you feel YOU are in, until you have appeared in this field's trade mags & books/newspapers, etc. et al for it, as I have, almost annually since 1996 as I put up SOME examples thereof for you... you have not done the same, & thus, are NOT in the same league.

(That's ontop of myself having been continually employed professionally for 15 yrs. now, either as a software engineer, OR, network admin).

ALSO - Didn't YOU admit that:

1.) Using threads is lighter than process forking (and, process forks are NOT just for "fork bombs" either), AFTER I pointed it out?

2.) That threads are also FASTER than process forks?? AND, You said that only after I pointed out these facts & you admitted them as correct...

3.) You did NOT point out how Copy-On-Write ACTUALLY WORKS (which I pointed out, in detail, & I also noted WHEN it works & takes effect)???

----

"I would need 10 times as many running as I have now before they filled up a core" - by SanityInAnarchy (655584) on Wednesday February 27, @02:26PM (#22577204) Didn't you also state that AMAROK (some app you use on Linux) took up 100% of a CPU? Bug or not, that still happened to you... & there are DEFINITELY apps that can sail a person's CPU usage upwards into that range, WITHOUT bugs, & thus... having more than 1 CPU core will help someone multitask more smoothly + WITH MORE APPS, since today's modern OS' process schedulers can & WILL send application threads off to the most unsaturated CPU core present, especially IF CPU 0 (first one for example) is saturated out of 2-N cores present.

Most code today is also multithreaded: Again, I run 30 processes right now, as I write this to you... 28 bear 2-29 threads here, 2 are single threaded. Overwhelmingly, I run more multithreaded apps than single threaded ones... not that it'd matter, because the OS process scheduler subsystem will send even SINGLE THREAD DESIGNED APPS off to 2-N cpu cores present, if the first core present is saturated to 100% cycles usage.

Multithreaded code has more overheads than single threaded code does as well (another point I brought up) & only shows performance & multitasking advantages on MULTICORE (or, true physical SMP rigs w/ more than 1 cpu core present) systems... it will actually RUN SLOWER ON SINGLE CORE SYSTEMS!

THUS, today? You ARE better off using MULTICORE MACHINES, since the majority of your code today, is most likely of multithread design (as I had to point out from MY system's taskmgr.exe program showing me show... you should check yours also, for overall count of multithreaded apps, vs. single threaded ones).

----

"Now, why the irrelevant insult about wasting time on Slashdot? Is it possible that you have no valid points left? Maybe you never did?" - by SanityInAnarchy (655584) on Wednesday February 27, @02:26PM (#22577204) Funny:

I was not the one tossing the "Capt. Obvious" names @ others, but, you did...

APK

Re:The advantage of dual-core...

[SanityInAnarchy]

If you are not going to even read my post, don't bother replying.

I will say this:

Didn't you also state that AMAROK (some app you use on Linux) took up 100% of a CPU? Bug or not, that still happened to you...

This one, it's possible I didn't make clear. It takes up 100% of one CPU, in an obscure bug involving me unplugging the soundcard, and plugging it back in. By closing it and re-opening it, the problem is eliminated -- no need to kill it, even. So we can stop talking about amarok -- unless your whole argument is going to be that we need three cores so that we can still work when two threads are stuck in infinite loops.

I'd say, if you have two threads stuck in an infinite loop, you have a bigger problem.

The rest of your post has descended into name-calling, arguments from authority, and a re-iteration of points I've addressed... all in the post you just replied to.

By the way, in case you were wondering, your "years of experience" get you exactly as much respect as it did this guy.

There's no need to wait for any space.

[Anonymous Coward]

Pretty much my thinking. If you're going to invest in a new computer? Why invest in last years tech? Anyway I'll be going with an Intel for the simple reason that an Intel quad takes up less boardspace than the comparable two "dual-core" AMD. The same thinking with the latest ATI dual-GPU board.

Look at the word you highlighted

[Mage Powers]

defective

Re:Look at the word you highlighted

[Anonymous Coward]

FYI, Intel does this as well, but more commonly with cache. Their CPUs need lots of cache to be competitive with AMD chips. But when the cache contains defects, they disable it and sell the chip as a lower grade CPU.

Hmm.

[Fishchip]

How long before Dell starts badgering Nintendo to allow Alienware to badge systems with a TRI-FORCE logo, I wonder.

Re:Hmm.

[Zymergy]

At least they did not try to call it the "Trinity"... But wait, that is taken too... Then again, Play.com is now out of business (Remember the Snappy?)... hmmmm?
(I can't be the *only* nerd (in the late 90's) who thought the "Play.com co-founder and evangelist Kiki Stockhammer" was one HOT redhead! -I wonder whatever happened to her?)

Re:Hmm.

[Faylone]

Well, when in doubt...search Google. First result has plenty of info http://www.patswayne.com/kiki/

Re:Hmm.

[Tony Hoyle]

play.com out of business? WTF? They're still one of the most popular online stores in the UK!

At least try to go to a url before making bizarre assertions.

sweet!

[Anonymous Coward]

This will go great with my Sunbeam UniToast (tm) .. the world's first single-slice toaster.

How did Sunbeam create such a powerful and versatile kitchen toaster? Easy! They took their top-of-the line dual-slot toaster, and disabled one slot!

Depends

[Sycraft-fu]

Different OSes have different methods for managing threads. In the case of Windows it shuffles them around as it sees fit. If you have three apps all using 100% of a core then yes, they'll get stuck each on their own core. You can also force it in task manager, where you can tell Windows which cores a given process is allowed to run on.

In general most modern OSes do a pretty good job moving things around. It isn't necessarily an app per core situation since many apps don't use much power and thus can all run on a single core. Also a single multi-threaded app may run on multiple cores at the same time. In general the OS will move things to try and get all threads as much CPU as they want, and to try and have CPU left over for new tasks.

I agree

[Sycraft-fu]

I think it is mostly marketing. AMD is likely having poor yields on their quad core processors since it is actually 4 chips on one die and not 2 separate 2 core dies as Intel is doing. So they probably figured for chips where 1 core fails, they'll just disable and market it as 3 cores. Ok that's fine, but as you noted, it is a solution looking for a problem. Every app I have falls in to one of the following categories:

1) Only uses a single core.
2) Uses 2 cores, but no more (games mostly).
3) Can scale to an arbitrary amount of cores and make efficient use of all of them (sound apps and such).

As such if I were to step up form my dual core processor, a quad core would be of more interest.

Now we'll have to see what pricing is like. I suppose if it is cheap enough it could be useful. For example if you are a gamer that'd give you 2 cores for a game and still have 1 left over for background processes. Ok so not really that useful, but still if the price is right I could see it.

Maybe games will scale up and start using more cores and gain an incremental benefit from 3, but I'm not holding out a lot of hope. Dual cores still aren't used by a lot of games, and it isn't as though it is easy to arbitrarily increase the threads in a game engine. I'm sure with time they'll be made quite parallel, but for now I'm thinking it'll be slow progress, and primarily match the widespread processor. That is dual core for now, and is likely to jump to quad core since Intel seems to have little interest in a 3 core solution.

I don't imagine they'll allow it

[Sycraft-fu]

It is getting more common for companies to physically disable the section on a chip that isn't supposed to be used. I'm not sure how it is done but I imagine just burning the traces with a laser would work. I'm going to guess AMD will be doing this with their 3 core systems. It servers 2 purposes:

1) Reduces complaints. You'd get people who would enable a defective core and then bitch that their system didn't work, especially since it could be somewhat random when failures happened.

2) Allow them to have a cheaper part. Yields may improve to the point that there are few defective cores, however there may still be demand for the cheaper part. Thus disabling 1 core allows them to continue selling both.

Re:I don't imagine they'll allow it

[91degrees]

I believe they're designed with the idea of disabling a core afterwards, using fusable tracks. Apply a high voltage to the right pins and part of the chip breaks.

software compatability?

[Doppler00]

I think I remember reading an article on Tomshardwareguide where they tried running one dual core, and a single core CPU in the same system for 3 cores. While they got it to boot the OS, a lot of applications failed to run.

I'm guessing there is a lot of code out there that's looking for power of 2 number of cores. A program might run fine with 1,2,4,8, or 16 cores, but if you do some kind of odd number I wouldn't be surprised if several applications just refused to run. It will be interesting to see what kind of compatibility testing AMD has done with this new processor.

In the end though, this just seems like another last ditch attempt by AMD to marginally compete on the lower end market with Intel. Intel says they have no need for 3 core chips since their yields are so much higher.

Re:software compatability?

[Anonymous Coward]

If you read the damn article YOU mentioned, you'd know that the processors weren't only dual and single. They had different versions of SSE and revisions. It's a testament to the platform's versatility by working at all with such differences.

dumbass.

Re:software compatability?

[flyingfsck]

That may well be true with DOS or Windows ME, but certainly not with any version of Unix.

Re:software compatability?

[Anonymous Coward]

Yeah, I echo what the other AC said (although a little more politely). I had enough of a problem getting a dual Opteron board to POST with different steppings of the same 246 (IIRC) CPU, so putting two completely different CPUs in a two socket board somehow seems like it shouldn't work at all. The fact it's even semi-reliable astounds me. As it happens the dual Opteron is bang on 100% reliable (I've Prime95ed it and all sorts trying to induce it to crash) so the POST warnings were purely cosmetic and we got lucky. Sounds like TH were the other way round, the mobo probably should have stopped at the BIOS and asked "Are you SURE you want to do that? It's never going to work..."

I can't find a link to the article at the moment, but I'm certainly going to dig it out and read it.

Re:software compatability?

[Fweeky]

A lot of apps which depend on such things probably only check CPUID and capabilities of a single CPU, and assume it goes for all available ones; this would be Bad if, say, one of your CPUs had SSE3 and one didn't - an app which can make use of it would only work if it happened to only be scheduled on the more capable CPU (so SSE3's always available), or happened to be scheduled on the less capable one when it did its capabilities check (so it never uses it).

k8temp is a good example; if you have one really old Opteron without a thermal sensor, and one with it, you'd have a 1 in NUM_CORE chance of it refusing to give a reading every time you ran it, since I use the cpuid instruction to detect those capabilities, and that is local to just one CPU.

Core count is unlikely to be an issue in this way; it's easier and more reliable to just ask the OS if that matters to you; it's one thing to use cpuid to check the SSE3 capability bit, it's quite another to use it to find the core count on all the CPUs you might run on now and in the future.

Re:software compatability?

[six]

A program might run fine with 1,2,4,8, or 16 cores, but if you do some kind of odd number I wouldn't be surprised if several applications just refused to run. It will be interesting to see what kind of compatibility testing AMD has done with this new processor.

This is wrong, an application has nothing to do with how its threads end up on which cpu on a smp system, this is all done by the OS scheduler.

Re:software compatability?

[Anonymous Coward]

I'm guessing there is a lot of code out there that's looking for power of 2 number of cores.

Why the hell should a program - a user level application - be "looking" for cores or even be concerned about such things? It has its threads which the OS has to care about.

Are you stuck in DOS times or something?

Re:software compatability?

[Animats]

I think I remember reading an article on Tomshardwareguide where they tried running one dual core, and a single core CPU in the same system for 3 cores. While they got it to boot the OS, a lot of applications failed to run.

That was just some idiot overclockers plugging two mismatched CPUs they had lying around into a dual-socket motherboard and expecting the OS to figure out that they had different capabilities. One CPU lacked some feature (SSE3?) and some applications didn't handle that properly. An app would start on a CPU with the feature, sense it was present by testing the current CPU, then be switched to a CPU without it and fail.

That's not a setup worth supporting. Detecting it at boot time, maybe.

Re:software compatability?

[ill stew dottied ewe]

I also read that but I believe that their problem was that no part of the system was made to work in that way. The processors and motherboard were designed to work with identical processors, not an arbitrary set chosen from "what we had laying around." They had different memory management, cache, and SSE support. That said, the benchmark section showed that it worked surprisingly well, only failing on two of the dozen or so tests.

Re:software compatability?

[GreyWolf3000]

fork() and clone().....fork() and clone().....you'd have to go out of your way to screw over non-2^n core chips.

Re:software compatability?

[toddestan]

Actually, quite the opposite. The flaw with their tests is that the CPUs had different capabilities, and most programs only chech one CPU and assume the rest are identical. As such, many or most versions of Unix would probably barf too, unless they explicitly tracks the capabilities of each CPU. On the other hand, Windows ME and DOS would run just fine, as those OSes have no concept of multiple CPUs and would run entirely on just one of the cores.

Re:software compatability?

[ocbwilg]

I think I remember reading an article on Tomshardwareguide where they tried running one dual core, and a single core CPU in the same system for 3 cores. While they got it to boot the OS, a lot of applications failed to run.

I'm guessing there is a lot of code out there that's looking for power of 2 number of cores. A program might run fine with 1,2,4,8, or 16 cores, but if you do some kind of odd number I wouldn't be surprised if several applications just refused to run. It will be interesting to see what kind of compatibility testing AMD has done with this new processor.

Wow, you're an idiot. You obviously aren't aware of this, but from a hardware perspective you should only use a multi-socket configuration when you have the same model CPUs installed in all sockets. Otherwise you are going to get all sorts of errors, much like Tom's did in their test. They even say right in the article that you shouldn't run two different CPUs in a dual socket config. The motherboard was throwing errors about CPU mismatches. They couldn't even get the motherboard to post with two different CPUs installed without re-jiggering things, so you can be sure that the issues weren't related to the OS or applications.

Everyone together now, "The applications don't care how many cores are installed. The applications just pass off threads to the OS, and the OS schedules those threads across all available cores." If you don't know what you're talking about then don't waste our time with your ignorant posts.

What's "defective" about them?

[Joce640k]

You're sold a three core chip, it has three working cores.

Which part of that is "defective", misleading, or unfit for purpose?

How many dual core chips are really four core chips with two failed cores? Do you know? Face it, it's just the number three which bugs you, and that's pretty childish...

Re:What's "defective" about them?

[Anonymous Coward]

>How many dual core chips are really four core chips with two failed cores? Do you know? Face it, it's just the number three which bugs you, and that's pretty childish...

From Intel? None of them. I know.

To sell 3 core chips is an open admission by AMD that their yield really sucks.

Re:What's "defective" about them?

[Anonymous Coward]

How many dual core chips are really four core chips with two failed cores?

Almost none.

AMD fabs dual core and quad core chips separately. And while they get the occasional defect that falls in one core's area, the defects large enough to affect two cores are very rare; so rare that it's not worth the extra bother to productize those dies. AMD pumps out enough native dual cores to render that extra supply irrelevant.

Intel hasn't even fabbed a mainstream quad core yet; the quad core products have two chips in same package. Defective dual-core chips have gone into the rare "Core 2 Solo" offerings or in the trashcan -- rare especially because they have had very good yields with the (by nature easier to fab than quads) duallies.

Re:What's "defective" about them?

[toddestan]

Intel's "Quad Core" chips are nothing but two Core 2 Duo's stitched together in the same package. When Intel has one of the two cores bad on a piece of silicon, they throw it in the "Core 2 Solo" bin, which while rare, are out there. Since AMD's quad cores are actually one piece of silicon, they are currently the only ones that have a situation where making a 3 core chip makes sense.

Re:What's "defective" about them?

[Andy Dodd]

"How many dual core chips are really four core chips with two failed cores? Do you know? Face it, it's just the number three which bugs you, and that's pretty childish..."

Probably few if none.

As another poster said, most if not all of Intel's current quad offerings are two dual core dies stitched together in a package. Duals with a failed single core will likely become solos, and are probably not worth ever creating a triple.

AMD's quads are single-die units. Thus it makes sense to be able to sell units with a single core failure.

As to two cores dead on a single die being marketed as a dual - that's highly unlikely. If, for example, one core in 100 is a dud due to a dust particle or whatever during manufacturing (Pfail = 0.01), then the chances of two cores on a single die being duds at the same time is one in 10,000 (Pfail = (0.01)^2 = 0.0001). Such two-failure dies will be so rare that there won't be any point in making plans for them, especially since if you have two dead cores, even if the other two initially pass testing their reliability might be called into question.

Re:so.....

[Anonymous Coward]

Is that a cheap attempt at humor?

Or maybe you don't understand manufacturing.
Not a shyster; no suckers.
(It would be interesting to pit an AMD Triple-core against Intel's Quad-core.)

Computer chips have billions of transistors, capacitors, resistors, and interconnects. All of them have to work to make the chip work.

Even in the says of tubes (valves), the manufacturers tested their product, then set aside the best to sell at a premium.

Intel used this technique on their 486SX processors. When the FPU on a 486DX tested defective, they could disable it and sell it as a 486SX. They probably still use the technique with multi-core processors. It would be stupid and wasteful not to.

Hard drives hold billions, even trillions of bits. All have to work. Drive makers have always mapped out defective sectors. Now they do it transparently. Flash disks too.

MacDonald's advertises "Billions Served." Imagine if they could say, "Billions served without a mistake."
When is the last time you were able to produce millions of items without a defect?

There is a known problem with current Phenom...

[ELiTeUI]

There are a couple known problems with the first spin of the Phenom die (codename Agena).

The first (and less relevant) problem is the TLB errata. The second (and more relevant to this discussion), is a problem in which core #2 (out of [0,1,2,3]) is lower yielding than the first three. For example, on the same CPU die, cores [0,1,3] may work fine at 2.6Ghz, but core [2] yields only at 2.0GHz. This is a widespread problem, mostly found out through failed overclocking attempts.

Google it yourself and find out..

Re:There is a known problem with current Phenom...

[Anonymous Coward]

[citation needed]

Multicore cpus and threaded games and applications

[redstar427]

As I have stated before:

Many of the newest Operating Systems, applications, and games are multi-threaded. Multiple cpu cores just allow modern systems to take advantage of them, when available.

I have a dual quad-core computer, that dual boots Windows Vista Ultimate, 64-bit, and Fedora 8 Linux, 64-bit. Many programs do take advantage of this system, including modern PC games, such as Crysis and Unreal Tournament 3. UT3 does use all 8 cpu cores during parts of the game.

So, even though multiple cores are not necessary, I find it helps in many ways, and many programs. The system seems to perform very smoothly.

God, Dell is NOT dropping AMD

[WarlockD]

I hate it when people tell me this. They have dropped WAY to much effort into the whole 6950 and SC1435 lines. Hell, the new 2970's are out if not already.

My personal opinion is that they still need to be fleshed out though. I am not sure why, but all the AMD systems we have only accept DDR2 unbuffered as well has having issues with very large amounts of ram ( More than 64gigs). I will admit however, they use ALLOT less power and much quieter.

Re:God, Dell is NOT dropping AMD

[owlstead]

Breaking news: Weird sparking coming from basements all over the US.

People have reported that sparking and loud screams have been reported all over the US. It has been thought that a posting on Slashdot caused the sparking when thousands of nerds drooled over their laptop computers. In other unrelated news, the amount of rugged laptop sales has skyrocketed.

Obligatory Onion Article

[SirSlud]

Just making sure your references are noted ;)

Re:Obligatory Onion Article

[Hal_Porter]

http://encyclopediadramatica.com/EXTREME_ADVERTISING

We're doing five cores

[symbolset]

For reference, see The Onion reference, "... We're doing five blades". (Rough language. If you're at a school maybe NSFW). From February, 2004. For the record, the Gillette Fusion with five blades and two lubricating strips was introduced in early 2006.

Hilarious though:

Here's the report from Engineering. Someone put it in the bathroom: I want to wipe my a?? with it. They don't tell me what to invent--I tell them. And I'm telling them to stick two more blades in there. I don't care how. Make the blades so thin they're invisible. Put some on the handle. I don't care if they have to cram the fifth blade in perpendicular to the other four, just do it!

You're taking the "safety" part of "safety razor" too literally, grandma. Cut the strings and soar. Let's hit it. Let's roll. This is our chance to make razor history. Let's dream big. All you have to do is say that five blades can happen, and it will happen. If you aren't on board, then .... you. And if you're on the board, then .... you and your father. Hey, if I'm the only one who'll take risks, I'm sure as hell happy to hog all the glory when the five-blade razor becomes the shaving tool for the U.S. of "this is how we shave now" A.

People said we couldn't go to three. It'll cost a fortune to manufacture, they said. Well, we did it. Now some egghead in a lab is screaming "Five's crazy?" Well, perhaps he'd be more comfortable in the labs at Norelco, working on #### electrics. Rotary blades, my white #!

I'm a big AMD fan but three cores are barely better than two. Buy it anyway - AMD needs to live if the computer market is to be bearable at all in ten years. Via makes some interesting stuff too - and they're not afraid to cut the watts and make them small. You can do some very neat stuff with a low watt CPU on a small board.

It doesn't take a great deal of insight to see we're going to 8 cores per processor on the desktop sometime in the next few years. Dual 16 core processors will happen within ten if competition keeps the pressure up. Personally I don't care if every core is on a separate slab of silicon as long as they integrate in the package well. Yields are better that way I imagine. Somebody tell them to get the watts down. Electricity is mostly made from CO2 emissions:

PCs worldwide consume about 80 billion kilowatt-hours of electricity every year.

Re:We're doing five cores

[Luyseyal]

I'm a big AMD fan but three cores are barely better than two.

And, depending on workload, slightly better than four. Three is the new two.

-l

Re:We're doing five cores

[Luyseyal]

... although to correct myself, this is not that design

-l

Dell is dropping 25% of AMD

[flyingfsck]

With one dead core dropped per processor, that would explain the rumours.

Graphics cards too...

[Joce640k]

I've hacked a couple of graphics cards by moving a resistor on the top of the chip. One was a GeForce and it came up afterwards as a "Quadro". The other was an ATI 9500 which came up afterwards as a 9700 (more shaders). Both cards worked perfectly for years.

Un No. Well, Not even close...

[killmofasta]

The new Phenom Tri-Core, is NOT a quad core with a core disabled/broken.
If it was, then it would have the cache of a quad-core wouldnt it?
It would also have most of the power consumption of a quad-core woulnt it?

Its a dual-core with an extra core, hense it has the cache of a dual-core,
not a quad-core.

If you took all your backround processes, and ran them on CPU-2( The third Core)
you could run multi-threaded stuff, on two cores, with no OS slow down.

btw, NT magizine has benchmarked stuff with 3CPUs and 6CPUs.

Its designed to be a Dual-core killer... DUH!

Re:Un No. Well, Not even close...

[TheRaven64]

The new Phenom Tri-Core, is NOT a quad core with a core disabled/broken. If it was, then it would have the cache of a quad-core wouldnt it? Unlike Intel, AMD use a per-core cache and so disabling one core would disable one quarter of the cache too. Beyond that, cache is also a used as a differentiator. The amount of cache in both product lines varies because cache accounts for well over half of the die size and disabling a few banks of cache around a defect lets them sell a chip that would otherwise be scrapped. Often the large cache and small cache chips are exactly the same, but the small-cache versions have a flaw (typically a tiny bit of dirt on the wafer) somewhere in the cache and so have part of it disabled.

It would also have most of the power consumption of a quad-core woulnt it? No, it would have slightly under 3/4 of the power consumption, the difference being accounted for by the fact that the other cores would need fewer interconnects.

Re:Un No. Well, Not even close...

[dhanson865]

The new Phenom Tri-Core, is NOT a quad core with a core disabled/broken. If it was, then it would have the cache of a quad-core wouldnt it?

Unlike Intel, AMD use a per-core cache and so disabling one core would disable one quarter of the cache too.

You are living in the past on that quote.

AMD used a per core cache on older designs. On the new design they use both a per core cache AND a shared cache. So on a quad core that has 512k per core and 2m shared the cache for a chip with one core disabled is (512x3)+2048/(512x4)+2048 or 7/8. So instead of disabling 1/4 of the cache they are disabling 1/8th, but because they disable 1/4 of the cores when disabling 1/8 of the cache it actually helps the cache per core ratio instead of hurting it.

Tri core Phenoms get 1195k of L2/L3 cache per core in that example. Quad core Phenoms get 1024k. So the tri core gets 16% larger cache based on that logic.

Besides that math is wrong/too simplistic because you are only considering L2 and L3 cache. Each core also has 128KB L1 but it seems in vogue to ignore it. It makes the math simpler especially when you get to 45nm and below when you bump that L3 cache up every time the process improves. 6MB L3 plus 512kb L2 on a tri core vs 6MB L3 plus 512kb L2 on a quad core gives you a 15/16 ratio vs the 3/4 ratio. The bigger the L3 the better the advantage for the tri core.

2560 vs 2048 in the 6MB L3 cache scenario, the 16% advantage becomes a 25% advantage at that node.

Re:Un No. Well, Not even close...

[killmofasta]

Ok. I looked at the pictures of the core.
Yep, your math is right, and proves my point about it NOT being a quadcore,
but you brought up the much more important point of WHY the tri-core phenom is designed as a Core-Duo killer:

"2560 vs 2048 in the 6MB L3 cache scenario, the 16% advantage becomes a 25% advantage at that node." EXACTLY.

Mod parent +2, Mod grandparent -2

Re:Un No. Well, Not even close...

[StikyPad]

That depends on your idea of "most" then, doesn't it? If you ate just under 3/4 of my cookies, I'd say you ate most of them, and in fact, I'd probably not be very happy about it!

Erlang concurrency

[Anonymous Coward]

I've been playing a bit with things like Erlang, which should be able to scale arbitrarily

Really? Correct me if I'm wrong, it's been some time since I played with erlang.

Re:Erlang concurrency

[Anonymous Coward]

Replying to self; "yes Dorothy, Erlang does support SMP these days".

Re:Erlang concurrency

[SanityInAnarchy]

I think you got it with that link, but just in case...

The green threads are a necessity, as most native OS threads won't handle the sheer number of Erlang "processes" that might be running.

But you can specify an arbitrary number of "real" threads to load-balance the green threads against.

Erlang also has ludicrously easy (and insecure) "native" RPC, so it scales easily to a cluster of (trusted) computers. It also has reasonably easy socket programming, but it's generally not as good as the native RPC, when it's an option.

This is what we're waiting for!

[chelsel]

Forget 3 cores, aren't we all just waiting for this baby http://techfreep.com/intel-80-cores-by-2011.htm to fit inside our laptops!

Finally

[Anonymous Coward]

About damn time! One core for my virus, one core for Norton, and one for my real work

Re:Finally

[repvik]

Uh, no. One core for Nortons user-interface and all that crap, one core for the scanning service and one core for your virus (which hardly uses cpu) and Real Work (TM)

My next Christmas wish...

[vrmlguy]

IIRC, somebody designed and sells a three socket mobo where all the data paths are also equal. (Ah, here it is: http://hardware.slashdot.org/hardware/07/08/13/1749213.shtml, a three socket Opteron machine with two PCIe slots and two Infiniband 4x ports.) I'd like to see a version for the Phenom 3-core CPUs; even better would be building some sort of Beowulf cluster using three of them, each using a pair of cross-over cables for the interconnects. That would give you one sweet 27-way cluster.

Give him a break

[r_jensen11]

How many dual core chips are really four core chips with two failed cores? Do you know? Face it, it's just the number three which bugs you, and that's pretty childish... The number 3 pisses off a lot of people. I like/tend to attribute it to Mr. Owl's amazing ability to consume Tootsie Roll Pops.

AMD "Peg Leg" Huh?

[Anonymous Coward]

Pirates will love it! "Avast me hearties, make that core walk the plank!". The rest of us will just think it odd...

AMD is surely paying the price for their "4 cores on die, or die" strategy.

Main question: Will it run Linux?

[strredwolf]

Seriously. Will the 3 core Phenoms work with Linux? I'm very excited to see what develops here.

Re:Main question: Will it run Linux?

[k8to]

It's going to be a programmable microprocessor in the x86-64 architecture. How could it *not* run linux?

If for some craaazy reason linux doesn't already work with it, this will be resolvable with a very small amount of work.

Re:Main question: Will it run Linux?

[RiotingPacifist]

wait i can trim that comment for you

It's going to be a microprocessor, How could it *not* run linux?

Re:Main question: Will it run Linux?

[strredwolf]

I'm just not sure if Linux is only tuned to a power-of-two number of processors (aka 1, 2, 4, 8...)

Re:Main question: Will it run Linux?

[k8to]

It doesn't care.

There might be some performance analysis situations you could contrive where the current algorithms for thread migration are better on 4 cores than 3, or something. I wouldn't bet on that though.

Re:Main question: Will it run Linux?

[Ihlosi]

I'm just not sure if Linux is only tuned to a power-of-two number of processors (aka 1, 2, 4, 8...)

Linux runs on the XBOX360, which has a three-core processor (not x86-compatible, though, but that doesn't really matter).

Doesn't negate his statements...

[Junta]

Those are facilities for programs to request particular behavior changes of the way the system scheduler does thing. Overwhelmingly, there is next to zero reason to adjust this in most applications. A good scheduler makes the best choices for the vast majority of cases.

That said, depending on the implementation, optimizations may be missed by certain vintages of particular schedulers. For example, a process might be suboptimally put on a core without access to the L2 cache that it had last go around. In a more esoteric case, if you are doing something highly IO intensive on a dual socket AMD system, it may be helpful to scehdule it on a core on the socket wired to the system chipset rather than one a hope away. In a NUMA machine, tending to run your process on the processor where your allocations are local is healthy in general, but most NUMA-aware schedulers explicitly know that basic optimization.

His point though was that applications don't have to do anything all that exotic to see the bulk of the benefit from reasonable number of cores. The affinity mechanisms given in most scenarios a developer may actually shoot themselves by thinking they know better than the scheduler, and even for cases where a programmer *does* know something about the system/application the kernel does not, the gain for the esoteric stuff is generally in the single digit percentages. Even on single threaded applications, under typical desktop load, quad core can help. I just checked at random and I had three processes in run state, but it's not uncommon for more processes with greater demand to peak concurrently.

Really?

[EdIII]

That may be the stupidest thing I have ever heard come out of Dell and AMD.

Why go through all the effort actually manufacturing the 4th core only to disable it? They can't sell it for the same price as the 4 core model, and they don't make any more profit since the manufacturing costs for that 4th core are already included.

This sounds like some weird marketing tactic learned from Sun Dip Shit, Sun Tzu's younger and mentally challenged cousin.

I guess the article may be wrong or something. Probably "missing" instead of "disabled". I hope so, since I think I would have to laugh out loud if a salesman tried to sell me that.

Re:Really?

[ZachPruckowski]

They can sell it for more. If you have 3 cores that can handle 2.6 GHz, and 1 that can handle 2.0 GHz, your options are:

A) Quad 2.0 GHz
B) Triple 2.6 GHz

There are a lot of applications for which (B) beats out (A), and you can probably sell a high-speed Triple-Core at a slight premium to a mid-range Quad-Core.

Re:Really?

[Anonymous Coward]

That's for sure if you want a "Peg Leg" CPU. Come on, the thing is crippled beyond belief. Is this rotting corpse their competition for the slick Core Dual/Quads? Oh AMD, I really had hope...

Re:Really?

[EdIII]

Forgive me, I am little confused here.

Is Quad 2.0GHZ a total of 8GHZ?

Is Triple 2.6 GHZ a total of 7.8GHZ?

You say a "1 that can handle 2.0GHZ" right after you mention 3 cores. I assume you meant 1 unit with 3 cores being compared to 1 unit with 4 cores.

If you are saying that the total processing power represented by a triple core is greater than a 4 core model for a comparable price, then yes that would make sense. However, that is not what the article says. The article says a 4 core unit with the 4th core disabled, not missing. So I still must ask, why go through all the hassle of manufacturing the 4th core, just to disable it?

According to your logic:

1) They can manufacturer a 4 core model.
2) They disable the 4th core.
3) After disabling the 4th core, they still possess more processing power then a competitors 4 core model.
4) They sell the resultant 3 core model for slight more then the competitor.

Well if that is true, why not leave the 4th core enabled, beat the competitors processor by an even larger margin, and still sell it for the same "premium"?

Re:Really?

[ZachPruckowski]

Cores don't add. That's problem number one with your confusion. You can't add clock speeds together because you have multiple cores. There's a lot more logic involved, and speed is dependent on a lot of other things in hardware (RAM, bandwidth, etc.). How effective multiple cores are depends on how threaded an application is, and on the quality of the operating system's scheduler. In some workloads, a dual-core might be twice as fast as a single-core, and quad core twice as fast as a dual core. In other workloads, a quad-core may only be 50% faster than a dual-core, and a dual-core might be only 50% faster than a single-core. Again, it depends on a plethora of hardware bottlenecks and software factors.

There's also the fact that clockspeed isn't the only metric - an AMD chip at the same clockspeed as an Intel one may actually be slower overall (or faster at some things and slower at others). This is because what you're interested in is work/second, not clocks/second. Assuming you get the same amount of work done per assembly instruction (since it's all x86 with only minor differing extensions, that's not an outlandish assumption), instructions/clock is a crucial metric. Because of various factors, Core2 Duos can do more instructions per clock than Phenoms. Previously, Athlons were beating Pentium4s at instruction/clock. So clockspeed isn't the only metric, and in fact isn't the most crucial one.

Additionally, most CPUs have only one clock and one voltage setter. So either the entire chip runs at 2.6 GHz, or the entire chip runs at 2.0 GHz. You can't mix and match them currently. Because you need a stable processor, you're only as strong as your weakest link - if one core can only hit 2.0 GHz at a set voltage, you have to make the entire processor 2.0 GHz. If disabling that core lets you hit 2.6 GHz with the 3 "healthy" cores, that may be a more attractive option, depending on the workload. Because a lot of software isn't multithreaded, 3 faster cores are sometimes superior to 4 slower ones. Heck, a 3.2 GHz dual-core is sometimes better than a 2.4 GHz quad-core (for some limited workloads).

Processors aren't designed individually, they're made by the thousands. They start out as silicon wafers. Then they get put in a machine with a whole bunch of lasers and stuff I don't even pretend to understand, which etches a few dozen processors on the wafer. Because of a variety of factors (manufacturing process issue, stray pieces of dust, impurities in silicon, whatever), some cores wind up testing better than others. A processor which can meet the 2.6 GHz benchmarks gets sold as a 2.6 GHz chip. The chip next to it may fail the 2.6 GHz tests, but meet the 2.2 GHz benchmark, and so gets sold as a 2.2 GHz chip. If a dual-core chip has one busted core (some kind of massive defect in one core but not the other), it gets the bad core blasted off and lives life as a single core chip. If a chip has an issue with some of its cache, then it gets half the cache disabled and is sold as a Celeron.

It's not a hassle to manufacture this extra stuff, whether its cache or cores. It's actually more of a pain in the butt to completely re-tool all the machines to make a pure triple-core. If you look at the economics of it (and I've only done that from the homework standpoint), most of the cost is the fixed cost of buying the machines and setting them up just right. After that, the goal is to get as much out of the chips you manufacture as possible. The choice you're making is between selling a chip with features disabled for a lower price, or tossing it in the trash.

Each chip has 4 cores, but with the slower core enabled, the chip can only hit 2.0 GHz. Without having to deal with the slow core, the other 3 can run faster (at 2.6 GHz). Obviously, AMD would prefer to sell the chip as a quad-2.6, but they can't. They can sell it at the speed it can hit with 4 cores (2.0 GHz), the speed it can hit with 3 cores (2.6 GHz) by disabling a core, or throw it out as defective.

Re:Really?

[EdIII]

Well thank you for that incredibly in depth and lengthy instruction. I do not say that sarcastically either. I already knew everything you told me, with the exception of the voltages being a limit on how fast you can make the entire processor. Thank You.

Also thank you, for not implying again that my questions deserved laughter from the "audience".

I never stated that core speeds could add. The poster seemed to state that by his use of "math". I was asking for a clarification. My use of "total processing power", was not meant to imply that cores could add either. I understand that the workload has to be distributed, and that operating systems and applications have to be written correctly to do so.

Those considerations of a single core, dual core, and quad core, are actually irrelevant. Although they may each have benefits depending on the application being run, what I am talking about is the "perception".

If I am going to make a choice about what processor to buy, the only information being presented to me (at least from the article) is that they are disabling a perfectly healthy core. Your statement about it being a faulty core that they "blast off" or disable is not something that is stated in the article. I don't think it would be advertised on the box.

The average person having a conversation with the salesman is going to want an answer to why the 4th core is disabled. Your statement about selling a fast tri-core versus a slow quad core is interesting. One would only know that if they understood what you had said about voltages limiting the overall speed. What you say makes a lot of sense.

Perhaps you could have said that last post?

Re:Really?

[BOFHelsinki]

Forgive me, I am little confused here.

Yup.

Is Quad 2.0GHZ a total of 8GHZ?

No, it's quad 2.0 GHz.

Is Triple 2.6 GHZ a total of 7.8GHZ?

No, it's triple 2.6 GHz.

Which configuration is faster depends on the properties of the total workload under execution at any given time. But with the majority of apps out there still unoptimized for more than one core, the triple 2.6 GHz is likely to beat the quad 2.0 GHz in quite many instances (of varied "home computer" use) simply because it completes a single thread in less wallclock time.

All in all you just can't (sanely) boil it down to a simple case of "add up all the GHz", unless you are processing nothing but NOPs. In any real use there is a myriad of factors at play; so you have to look at it case by case and look at the details and characteristics of your combined worload.

(Caches and core interconnects and other relevant stuff omitted from discussion for simplicity.)

Re:Really?

[Jesus_666]

Why go through all the effort actually manufacturing the 4th core only to disable it?

Yield. No fabbing process gives you 100% yield. You always end up with small imperfections that can cause an area of the chip to fail at high speeds/temperatures or not work at all. Most of the time you can disable that part of the chip and sell the chip as a lower-spec model instead of just throwing it away.

Also, an entire separate manufacturing line just for tri-core chips is expensive. You generate tri-cores from your quad-core lines automatically and if tri-core demand is high it's probably still cheaper to just build quad-cores and disable one core.

That's exactly how, well, the entire hardware industry has been operating for years. Whether NVidia disabled rendering pipelines or Intel downclocked Pentium IIs in order to get Celerons, the basic idea was always that imperfect dies translate into a lower-end product line.


By the way, that kind of stuff generates interest in the product by itself - people like the idea of buying a low-end product and turn it into a high-end one. Of course it's always a bit of a lottery, but it does attract people.

Re:Really?

[RiotingPacifist]

By the way, that kind of stuff generates interest in the product by itself - people like the idea of buying a low-end product and turn it into a high-end one. Of course it's always a bit of a lottery, but it does attract people. How is the last core disabled? is it physical or firmware. It would be quite interesting if the triple core demand gets so high that they're probably shipping quad cores.

If its hackable, it would even be interesting to see how the defective cores perform. For example if i have a 2.6 tricore because the last core cant go above 2.0 ( im sure marketing would do this sort of thing ). For multithreaded stuff my computer could run in quadcore mode at a low clock rate (4*2 > 3*2.6) but when the programs running cant really multithread the last core could be switched of to allow the clock to be increased ( 2.6 > 2.0).
Is this possible or is the last core disabled physically?

p.s i dont know why i care, as my laptop runs fast enough for everyday stuff with a 1.6 single core since i got more than 256 ram(it uses a whole 390MB now). Is there a demand for this anywhere outside the server/gaming market?

Re:Really?

[ZachPruckowski]

On voltages - the idea is that the processor passes a stability test with a set voltage and within a set thermal envelope. The highest clock speed at which they pass that test is how they're sold. Over-clockers who are willing to change voltage and deal with increased heat can get a processor to go faster (there are limits on that too, though). Some mobile processors have settings which adjust the clock settings, multiplier, and voltage simultaneously to reach a low power mode. My point is that in most cases, it's all or nothing in that you either are running at full speed on all cores, or at reduced speed everywhere. Some newer processors can do the cores independently, but for the most part, the speed has to be consistent core-to-core. And that down-adjustable clockspeed stuff is limited to mobile chips.

You're right that a lot of people are going to look at the "one processor disabled" and have qualms (which are probably unreasonable). And that might chase away some people. But I don't think it'll come up. Celerons sold well, and they were "disabled" Pentiums. Some Athlons were Opterons with fewer working HyperTransport links in a different package. Every mid-range GPU ever is a "disabled" version of the high-end one. There's even software to "softmod" some upper-mid-range chips to their full glory (apparently, this is now less common). While it's an issue for consumers, historically there's not a lot of evidence that it's a major one, and it's not one that a lot of people know about.

The conversation with the sales person probably won't even touch on the design of the processor. On the consumer side, the consumer and the Best Buy sales guy won't know anything about it, and on the business side, most companies will do enough research to rule it out as a major factor. The real issue is at the intersection where people have enough knowledge to have read the article, but not enough knowledge to recognize that this isn't unusual. This wouldn't stop me from buying a tri-core chip (the fact that Intel is beating the pants off AMD would, though) because I know better, and it wouldn't stop Joe Schmoe, because he'll have no idea about it.

The marketing logic is going to be "Faster than the comparably priced quadcore, more cores than the same price dualcore", and it might make some sales. Personally, I'm not convinced a 2.6 GHz AMD tri-core will beat a Q6600 (2.4 GHz Intel quadcore) in single-threaded benchmarks, so the issue is sort of moot. Pre-Penryn, Intel's chips were competitive with Phenom/Barcelona Opterons, and now Wolfdale/Yorktown/Harpertown are spanking them. In a closer processor preformance race, this would be an interesting idea, but the performance gap makes the tri-core hard to sell, except on the extreme low-end. The cheapest quad-core Yorkfield you can get (when it's out in a few weeks) will be $266 for a 2.5 GHz chip. There will be a 3.16 GHz dual-core at the same price, with a 3.0 GHz dual-core below $200 (source). To come in between them, you'd have to a 2.6-2.8 GHz tri-core between $225 and $250. That just doesn't make AMD money.

Finally, disclaimer: I am a college student in a Computer Architecture class who has read a bit about this sort of stuff. I am not an expert on this at all. I also own a Mac Pro, which is an Intel workstation.

Re:Really?

[ZachPruckowski]

What you're proposing would be ridiculously complex, and if it's possible, isn't worth it. If it was possible to switch without physical access (changing something on the board), it'd probably require a restart. It'd only be worth it to a tiny group of people. In most cases, people know what workload will max out their computer, and build around that (graphics workstation, server, gaming, whatever). Either the workload will be single-threaded or multi-threaded. In the remaining time when the processor isn't at full utilization, it really doesn't matter if you're using 3 or 4 cores, since you're only using 20%-25% of the processor anyways.

It also wouldn't work under Windows, because you'd have to reauthorize WGA every time you switched.

Re:Really?

[RiotingPacifist]

I realize it would be complex but would it be possible?

it'd probably require a restart. Linux can be compiled to be hotplugable, if i understood correctly it means this isnt true.

people know what workload will max out their computer, and build around that I was looking for the desktop market, were one minute ill be running everyday stuff (mail + web browser, want as many slow cores as i can get so i save power),
then ill edit some pictures ( I dont know much about graphics but i think multicores are generally good for this)
then ill play some games ( some games are better at threading than others).

It also wouldn't work under Windows, because you'd have to reauthorize WGA every time you switched. true but i was looking at it from a purely technical point of view, if it became practically useful im sure windows would allow you to pay for WGA-flexy-core that gets around this.

Re:Really?

[ZachPruckowski]

It's one thing to hotplug an external hard drive, quite another to swap processors while running.

then ill edit some pictures ( I dont know much about graphics but i think multicores are generally good for this)
then ill play some games ( some games are better at threading than others). It's pretty rare that you're going to be using 100% power in the first case and probably not in the second case. Unless you're doing professional work (like with Photoshop or Aperture) or batch work on a dozen photos, you're not going to max out even a 2.0 GHz dual core. At least, you won't save enough time with the quad set-up to justify altering the settings. And with a decent CPU, either way your CPU won't be the bottleneck (unless you have $2k+ in graphics cards and 8 GB of RAM) gaming. And even threaded games generally thread out to 2 or 3 processors. There's no such thing as n-core scaling. Supposedly some games will see a benefit from 4 cores, but that's few and far between.

Most consumer applications don't max out a processor. Having a switchable processor would be worth it only in really specialized situations. As a result, no one would code the software for it.

Finally, the power draw on the desktop isn't something that's really an issue. The differences would be noticeable as a dollar or two on your electric bill. Batteries in laptops are measured in tens of watt-hours, while home electric prices are in the pennies/kilowatt-hour range. So if you save 50 watts in a desktop low-power mode on a computer you use 8 hours a day (it's sleeping most of the time), that's 50*8*30 = 12,000 watt-hours, or 12 kilowatt hours. At 10 cents per kilowatt-hour (admittedly, that's a year-old US residential average), you save $1.20 a month. One degree on the thermostat or better sealed windows save more. However, in a laptop with 60-90Wh battery, every watt counts.

Re:Really?

[RiotingPacifist]

It's one thing to hotplug an external hard drive, quite another to swap processors while running. I meant CPU hotplugable, i think it was originally developed purely for a few highend servers that allow hotplugable CPUs, but now its main application (AFAIK) is in visualization.

Most consumer applications don't max out a processor. Having a switchable processor would be worth it only in really specialized situations. As a result, no one would code the software for it. The software would simply have to be multithreaded the OS would take care of the rest, the software wouldn't need to do anything special.

I will concede that i cant think of an application for switching between modes( perhaps compiling? or gaming (old games dont multi thread well but then again old games wont max out cpu)? or if a core is known to fail at high temp (but then again you'd just throttle the cpu usage to keep it from failing) ), but if disabled cores are not disabled physically then at least if quadcores were being shipped people would be able to enable the last core.

Re:Really?

[ZachPruckowski]

Most consumer applications don't max out a processor. Having a switchable processor would be worth it only in really specialized situations. As a result, no one would code the software for it.
The software would simply have to be multithreaded the OS would take care of the rest, the software wouldn't need to do anything special.

There's more than that. For the performance gain to be noticeable, I need to need the extra processing power. If OS+RSS+email+browsing+itunes only takes up 50% of a core (as you'd expect with even a low-end current chip), then it doesn't matter if I have 1 core, 2, 3, or a 8 cores. The milliseconds of lower latency aren't noticeable to the end user. Only uses where processor usage hits 80%+ from time to time will see any benefit. Processes which aren't CPU bound or already occur faster than the user really notices won't benefit from multiple cores unless the background processes eat a lot of CPU. If you're not stressing the machine, you won't notice a difference between a dual-core and a tri-core and a quad-core.

Re:Really?

[Jesus_666]

Linux can be compiled to be hotplugable, if i understood correctly it means this isnt true.

As far as I know CPU hotplugging requires that you use a multiprocessor (with more than one socket) system and that prior to doing something to a processor you need to tell Linux about it. In a single-socket system you'd need to completely switch off your only processor in order to tweak it, which obviously wouldn't work. That's what I think I now about the topic, though; doesn't need to actually be true.

Generally, you'd probably be better off with 3x2.6 than with 4x2.0, though. The latter is only useful if you have many small threads and you need the parallelism. If you do anything that requires heavy lifting, it's still more likely to have few big threads.

As for WGA: WGA doesn't care about the number of cores; Microsoft defines "processor" as "socket", at least for Vista.


To get back to your original queation: Everything is possible. Might be that certain BIOSes can override the procesor's opinion on what the processor can do. Might be that it's set in stone. Might be that you need to connect two pins in order to nullify the processor's capability lock. We've already had any of those scenarios.

Nothing magical about three

[Junta]

The reason for the three socket server being able to boast the direct connection is an artifact of AMD's design. The processors in question had only two coherent HT links, and thus a processor with more coherent links could be used to construct fully connected designs with more members (i.e. 3 coherent links allows a fully connected quad socket). Anyway, as nice and symmetric as it sounds, the problem is overwhelmingly, the performance penalty of the occasional two hop access pales in comparison to having 33% more processor available to crunch in the scenarios where you would care about the minor degradation of a two hop access. Now all this was presuming it would be possible to build such a system with a Phenom, but it simply isn't. It isn't until the third tier of Opteron (single socket capable (1000 series), dual socket capabable (2000 series), 'more' socket capable (8000 series) that the number of HT links usable for inter-processor links permits that design.

It has no relevance to AMDs quad-core design internally, the cores are no worse off communication wise than the triple cores. It has no relevance to a cluster, where it's hard to imagine *any* node interconnect that would care about having 3 vs. 4 nodes in it.

Re:Nothing magical about three

[vrmlguy]

It has no relevance to a cluster, where it's hard to imagine *any* node interconnect that would care about having 3 vs. 4 nodes in it. Go back and read my post. Node interconnects can be standard switches, where communications between one pair of nodes can delay all of the other nodes, or you can use a cross-bar, where distinct pairs can communicate, but one code can only talk to one other system at a time. Both require additional hardware external to the nodes, which costs money and power.

Or you can use direct connections, wherein a node can always talk to the other end of a wire with no delay. If your mobo has two Ethernet ports, then each node can talk to two others simultaneously, while if it has four then each can talk to three, etc. Unfortunately, each port costs you both money and real estate, so you can't continue the process indefinitely. The mobo that I was describing has two ports, which in a full mesh means that you wind up with a three node cluster.

Yeah, if you have an infinite budget, then by all means buy as many nodes as you can fit into your closet. Those of us in the real world, unfortunately, have limits to our purchasing power, so we need to find the best cost/performance ratio that we can.

Re:Nothing magical about three

[Junta]

The problem with your switchless proposal is that you presume two ports of network connectivity per node and that all can be dedicated to inter-node communication. It's then hardly useful as there is no way to uplink it to transfer meaningful work/results in and out. I guess your answer would be to slap an ethernet card, but at three nodes, why bother, particularly if you are advocating on board NICs as the interconnect.

In any event, the penalty of an ethernet switch at small scale is negligible (latency increase on a decent swich would maybe 2 usec when the system latency of the two nodes in ethernet is commonly in the 40 usec range, and only really contrived situations will be meausurably impacted, and even then the difference will be low. There are interconnects that get in the 2 usec range total for latency penalty on those contrived cases, but that's far more expensive than the onboard NICs.

The system mentioned has infiniband ports, and you could ignore the ethernet, so you could use those instead. But considering the exorbitant cost of Infiniband cables and your stated limited budget restriction, it's going to be hard to use those with or without a switch Further, if using the IB ports, the fabric would tolerate an additional hop, so the relative penalty of two hop communications isn't bad there either.. The same can be said of bridging the ethernet ports so each node is also a low-port count switch, but I can't speak to the performance characteristics of that. Especially with a mere three nodes, the workload of clustered applications won't even notice the difference in your convoluted node interconnect vs. something more generally configured.

In other words, a three-socket motherboard with infiniband is going to cost you a lot to get not significantly better performance than cobbling together something of more mainstream nature that will scale to 8 or 24 nodes (depending on if you want an 8 or 24 port switch, 48 port starts getting pricier).

Re:Nothing magical about three

[vrmlguy]

The problem with your switchless proposal is that you presume two ports of network connectivity per node and that all can be dedicated to inter-node communication. It's then hardly useful as there is no way to uplink it to transfer meaningful work/results in and out. I guess your answer would be to slap an ethernet card, but at three nodes, why bother, particularly if you are advocating on board NICs as the interconnect. You're certaining devoting a lot of energy to discrediting a spur-of-the-moment design (you did notice that the post was titled "My next Christmas wish", didn't you?), however it was based upon typical Beowulf clusters. For example, Microwulf (http://www.calvin.edu/~adams/research/microwulf/design/) has just four nodes and uses $40 T-base/1000 for internal communications and a single $15 T-base/100 card installed on one of the ndoes to talk to the outside world. A year ago, the prototypical Microwulf provided 4 dual-core clusters for under $2,500; I was suggesting a similar design supporting 27 cores at a hopefully comparable cost.

Switchs may be cheap, but they ain't free: they cost money, they draw power, and they occupy space. Infiniband doesn't use cross-over cables, so there's no extra cost there; you just need to reconfigure one end of the connection in the software. It's always better to configure your nodes as similarly as possible, so if I were actually going to use Infiniband as an interconnect, I'd probably enable the subnet manager on the first port on all nodes, and disable it on the other port. This would allow easy expansion to a larger loop topology if my hypothtical budget ever allowed for the purchase of more of my fictitious three-socket mother boards.

Yes, Really

[BalorTFL]

In all likelihood, the fourth core didn't pass the QA tests, i.e., doesn't work. The choice is then between selling it as a 3-core chip (and still making good money) or throwing it away. Further, if it turns out that demand is higher for the cheaper 3-core model, AMD may disable the 4th core on some working 4-core Phenoms and sell them for the cheaper rate. This happens all the time in the CPU world, and even more in the GPU world - not everyone is willing to pay $500+ for a top-of-the-line card, so NVidia has a number of cards that are cut-down versions of more expensive cards that either didn't pass QA completely (or had pipelines laser-cut) to be sold where the demand is. Also, your point about manufacturing costs is completely moot. The real cost in a CPU is not per-unit: a single chip is actually quite cheap to produce, once fab lines are up and running - it's the design and testing that cost the real money, and by not designing a separate 3-core model and supporting the separate fab process, they can actually *save money*.

While you're laughing at the salesman, the rest of us are laughing at you.

Re:Yes, Really

[EdIII]

Laughing at me? Uh huh.

I made some very valid points that any layperson is going to instantly want answers to. The important part here is making a sale. The first thing I want to know is how much they will charge me to enable the 4th core, and why the 4th core is disabled.

Let us consider your examples derived from that superior logic that you possess. I'll wait for the laughter to die down :)

If they already had 4 core models produced (without errors) and they disable a core to sell it a cheaper rate, it still begs the question why? Do you really think that a consumer will be so enamored over a 3 core model, that they will choose it over a 4 core? The manufacturer will still be losing profit on it with your example. Of course, your point about salvaging profit by blowing them out is perfectly valid. They could still do that with a 4 core model even better. Not to mention, depending on how it is disabled, some consumers might be able to gain the 4th core back anyways.

As for you in depth analysis of the design, testing, and fabrication costs of a CPU, that is actually moot. The article says disabled. It does not say missing. So although you may be correct that design costs are reduced by using a 4 core design, and only producing 3 cores with it, that is not a situation represented by the article. What is interesting is your statement that a CPU failed QA and they are attempting to salvage the whole unit.

Do you really want a CPU that had a part of it fail testing? Do you think that fact should have to be advertised on the box?

Your really laughing at me?

Re:Yes, Really

[BalorTFL]

Yup, sorry, we're all still laughing at you. When you go ask the salesman how much it'll cost you to re-enable that 4th core, he'll either stare at you blankly (BestBuy) or tell you "Well, it's an extra $x to buy the 4-core version instead of a 3-core version." And why might customers prefer to buy the 3-core instead of the 4-core model, you ask? Do you have the fastest processor, graphics card, etc. that money can buy? I doubt it! The savvy customer looks at the prices, considers the performance, and settles for the compromise that meets his needs. Seeing that customers still buy dual-core machines, even though quad-core is available, I think it's safe to say that they'll buy 3-core chips, too, assuming the price is right.

Also, the manufacturer is probably not losing profit overall in my example: Suppose AMD markets the 4-core Phenom, and only the 4-core, at $400. Some people may buy that, but many will look at AMD's offering compared to a less-powerful (but still good) Intel chip for $250, and buy Intel instead. But if there was 3-core AMD model at that price point, AMD wouldn't lose as many customers to their competitor. Not everyone is willing to spend top dollar for a CPU, even if it's worth every penny by the benchmarks.

Finally, your statement:

Do you really want a CPU that had a part of it fail testing? Do you think that fact should have to be advertised on the box?

is complete and utter nonsense. Tech companies have been doing exactly this for years without problems, and it's the most logical way to do things. For RAM you can often find PC2-5400, PC2-6400, even PC2-8000 with exactly the same variety of IC inside! Usually when they test any kind of chips, they see if they'll work at the highest standard, and if so, sell them accordingly - if not, they get sold at a lower standard. If you bought the cheaper version, you didn't get sold a defective product, you got *exactly* what you paid for! There are various CPU models already on the market that are exactly the same as more expensive ones but weren't stable at higher clocks or had some L2 cache disabled. For example, the B2 stepping Core 2 Duo e6300 and e6400 procs were exactly the same as the more expensive e6600 and e6700, only with half the cache disabled or defective, and clocked slower. Graphics cards have been doing this as well, and there are even some cases in which users have managed to unlock the extra pipelines and overclock, turning their cut-down card into the more expensive version. The manufacturers don't care a whit, as long as people aren't doing it frequently and reliably enough to render the more expensive model redundant. As long as the 3 cores in use have been tested to work reliably, why should you care whether the remaining core was defective or working before it was disabled? You're not using it, you didn't pay for it, so as far as you're concerned, it's as though it never existed - and those 3 cores that you did buy work as advertised!

Re:Yes, Really

[Ihlosi]

Do you really want a CPU that had a part of it fail testing?

Well, give me any CPU and I'll design a test for it that it will fail. You probably have lots and lots of parts in your PC that are "consumer"-grade, i.e. they were never tested or failed some of the harsher environmental tests.

When I buy a CPU, I'm not interested in what it can't do - I want to know what it can do, and that's what I'm going to pay for. If it can't do what the manufacturer says it can (in the datasheet), then it is defective.

The earliest one I remembered was the 486SX

[Anonymous Coward]

Where the math co-processor was disabled. There were probably other examples in many earlier human techs (ie Torg might have sold less perfectly round stone wheels to Grok as the wheel SX)

Rock, paper scissors....

[EmbeddedJanitor]

Three choices, three cores. Everyone's happy!

Re:Rock, paper scissors....

[Jesus_666]

Great. A CPU that automatically deadlocks when someone plays rock-paper-scissors on it.

The Sweet Spot

[Nom du Keyboard]

If you can provide more performance than a dual-core, at less than the cost of a quad-core, then you've found yourself a sweet spot to sell systems into. Few people will ever need true quad-core performance, so let's hope AMD has a real winner here.

I just find it odd...

[thejynxed]

That they are even bothering to announce the triple-core Phenoms when Best Buy already has the quad-core Phenoms on sale... I mean really, unless they are seriously going to undercut the Core 2 chips there is no point in announcing it, because general consumers don't give a rats ass.

In case you are wondering what system Best Buy is selling, it's a Gateway AMD LIVE! Ultimate Digital Entertainment System. Features the AMD Phenom Quad Core 9600. Price $1279.97, with the following:

Computer with 19" HD LCD Widescreen Monitor and Canon All-in-One Printer. Windows Vista(TM) Home Premium, watch and record TV, 3GB DDR2 memory, 1 terabyte hard drive, hybrid Blu-ray Disc(TM) and HD DVD player, reads and writes dual-layer DVDs and CDs, ATI Radeon(TM) HD 2400 XT graphics with 256MB dedicated graphics memory and DirectX® 10, wireless keyboard and mouse, and carbon fiber faceplate. 19" HD LCD Widescreen (GM5664/FPD1976W/MP210). Upgrade to a 22" HD LCD monitor for $110 more.

I hate BB as much as the rest of you, but as of right now, they are the only retailer I've come across selling Phenom-based systems to the mass market.

Re:so.....

[Jesus_666]

There's a lot of such suckers. They're called "overclockers".

You see, production flaws usually don't generate enough hardware to fill an entire low-end line, so there are certain batches that consist entirely of good higher-end ones. If you know the name of the batch you can try to get your hands on one of them and then proceed to unlock its true capabilities. A very nice way to get your hand on processing power without having to pay premium prices.

Terms like "JIUHB" come to mind.

Re:so.....

[toddestan]

Both Intel and AMD have been doing this kind of thing for decades. Nothing new here at all.

The next slashdot poll

[spiracle]

Option 3: Holding Out For 7 Cores.

MOD PARENT DOWN, FACTUALLY INCORRECT

[rsmith-mac]

The above parent needs to be modded down, it's factually incorrect. The idea that Celerons were extremely overclockable is correct, but that's not how things worked. The Celeron 300A's core was Intel's first chip with on-die L2 cache, the Pentium II and Katami P3 lines still used off-die on-PCB L2 cache chips. Intel didn't ship P2 cores as the second generation Celerons*, those were all produced separately.

* The first gen Celerons (266 and 300, not to be confused with 300A and later) had no on-die L2, so technically Intel could do that, but they probably didn't considering those Celerons sold poorly

AMD's reason for 3 cores

[hcdejong]

They're just following the Book of Weapons:

'First shalt thou take out the Holy Pin. Then, shalt thou count to three. No more. No less. Three shalt be the number thou shalt count, and the number of the counting shall be three. Four shalt thou not count, nor either count thou two, excepting that thou then proceed to three. Five is right out. Once the number three, being the third number, be reached, then, lobbest thou thy Holy Hand Grenade of Antioch towards thy foe, who, being naughty in My sight, shall snuff it.'