OSNews

Um, where do you think the 4-core AMD chip is going to be introduced first? The high-end server market, of course. Since the Opteron, all of AMD's cool stuff appears in the server realm first, and only later trickles down to use regular-folk.

"Note of course that Sun are shipping 8 core sparc cpus now. (And each of those 8 cores support 4 threads)"

Nice, yes, but two things:

1) it's not really consumer oritented, and it's pricing reflects it.

2) "And, instead of the much-critizised one floating point unit per processor, the Niagara II will feature one floating point unit per core. "

From: http://www.osnews.com/comment.php?news_id=12909

1 FP unit in an 8 core processor hardly sounds impressive.

1) it's not really consumer oritented, and it's pricing reflects it.


I missed the bit where it said they had to be consumer
oriented. If you look at the pricing you will see that
it's very competitive, starting from $3000


1 FP unit in an 8 core processor hardly sounds impressive.


Well, it really depends on what you find impressive.
It's only an issue if you run FP code. You'd be
surprised how little application code on a server
needs an FP unit.

Except each of these AMD cores will be easily twice as fast as each of those SPARC cores.

Except each of these AMD cores will be easily twice as fast as each of those SPARC cores.
They'll completely suck at some stuff, there's no doubt about that, but that's not what they're designed for.

Niagara is possible for Sun because a lot of their systems run apps which are easily multithreaded and don't require super low latency. They also don't benefit from complex multi-issue cores so the distinct lack of issues (1 per cycle per core) is in these cases an advantage. On those sorts of apps (Java app server based stuff, database, etc) Niagara is an absolute killer, outgunning a 4 way Xeon system at under 1/4 of the power consumption.

If you're in the market for a machine to run a business Java app or you already do and want to save on your power bill you'd be a fool not to look at a Niagara machine.

They'll suck at workstation stuff and scientific computing stuff as well. Heck, even for integer stuff they'll suck, it's just the suckage will be mitigated by the sheer number of cores.

That said, my statement about the speed is based simply on a theoretical comparison of the performance. Niagra comes out at 1.2GHz. If the quad-core K8 comes out at the speed of the current dual-core Opteron (2.4GHz), each core will be at least twice as fast as a Niagra core. The only case in which Niagra would win would be a completely memory-bandwidth limited task.

If the quad-core K8 comes out at the speed of the current dual-core Opteron (2.4GHz), each core will be at least twice as fast as a Niagra core.

In theory yes, but seemingly not given the benchmarks shown so far (Java appserver stuff, TCP-H). All the systems it's been compared against (Xeons, Itaniums, Opterons) *should* be faster but the Niagara is still winning, it's even winning some against POWER5 systems which is pretty startling.

A lot of server stuff like this has very low IPC figures (below 1) so OOO cores are no help, a high clock doesn't seem to help much either as it would appear cache runs out and the CPUs just run from RAM. The thread switching overhead may also be more of a problem for some processors wereas this can be hidden on Niagara.

I think the devil is in the details: the advantages of multicore designs is really in the shared memory topologies and efficiency of core - core task coordination which is built into the hardware (this may be the Niagra advantage as well other design features that are more efficient and more easily achievable on a single die design.

The previous comment about SMP is well taken and the point of my previous post. For general purpose uses, an SMP design is usually more practical and efficient than a similar one with a faster single CPU. To some extent this is also because of effectively larger memory bandwidth with multiple CPUs in most designs as well. The multicore CPUs take this concept several steps further.

Every now and again Sun pulls a rabbit out of their freaking huge R&D hat. It was the super cool ( in temperature and size ) Galaxy units and then the multi-core Niagara. The thing to watch is the trend with Sun. They did this sort of thing way back, a decade ago with the 64-bit UltraSparc processor and were the only people around running 64-bit. It took them very little time to kick out the UltraSparc II that really dominated internet based services for the next five years. Now they introduce the Niagara at 1.2 GHz to start with. You need to fully expect that there are 32-way Opteron machines in the pipeline as well as faster Niagara like processors complete with multiple FPUs and other cool features, like a fully optical bus.

Just look to the past to see the trend in a company like Sun. It is best to think of their past trends before talking about the lack of features in some new product. Also keep in mind that HP has no real R&D at all and they are stuck waiting for Intel to do something brilliant. When is the last time HP invented anything worth looking at twice? Not since they had cool RPN calculators.

Why are you so upset that the FX-60 is clocked slower?

CLOCK != PERFORMANCE !!!

If its faster, its faster, regardless of clock, and AMD calling it the FX-60 leads me to believe the FX-59 will not beat it.

Actually, AMD decided to skip 59 and go directly to 60. AMD is not making anymore single cores FXs anymore apperantly. Just dual cores, if not more. What I'm saying is that the performance of the 60 did not live up to the 57. I'll look up the article and post it.

--ZaNkY

The government would be better off with ten thousand 1Ghz (low power and very cool) processors than any red hot 10Ghz ones. After all the governement just needs to scan all information constantly about every individual to keep up with everyones activities and relationships; otherwise they could never maintain an effective police state to protect us all from the enemies of democracy.

That depends, if they need to do independent calculations that not influence each other for most of time and that rarely need to excange small amount of data, then grid computing is the solution.
If they need to do tasks that could be easily parallelized but need heavy and constant data excange, they will need a supercomoputer that will not only feature many CPU's but also very fast access to shared memories.
If they need to do non parallelizable tasks (each step determine the next) they will really need "simply" a super CPU with high clock and high efficiency per cycle, and maybe a fast bus to an useful amount of local memory if the task is even memory hungry.

Each chip architecture leapfrogs its competitors for a while. Multi-core could be a big deal for Sun. The SPARC archetecture had a lot of challenges keeping up with competitors; it took a lot of work to get the UltraSPARC out the door and the Ultra only put Sun on top for a little while and they have been falling farther and farther behind as each new generation of chip has been too little too late. One advantage Sun has is that a SPARC core can be much smaller than its competitors so they should be able to cram more of them on their chips. I've heard discussions of putting 40 SPARC cores on a chip. Still, I'd put my money on IBM's Power archetecture as the best technology.

To a certain extent, BeOS/Haiku/Zeta do make better use of multiple cores without extra effort from the developer to do so, when running GUI applications. However, that's a qualified "without extra effort from the developer" because writing a BeOS GUI application with a visible window absolutely forces the application to have a minimum of 2 threads to manage: the application object with its thread of execution, and one for each window (in BeOS, a window contains one or more views, which are not treated identically to windows, as in Windows, and each view in BeOS only works in the message loop of the window it belongs to/renders on) without doing anything extra for other things. In other words, while there's no extra effort to utilize SMP in BeOS for the developer, exactly the same amount of effort is expended to develop an application for a single processor, because there's no choice but to have at least 2 threads for a GUI application and deal with the thread management associated with that. This does not apply to command line/console applications, though.

While BeOS makes it the default to utilize more than one thread (and processor as a result) it can't do anything to help it be easier to write software in an SMP manner that isn't naturally suited for that in the first place, so unless you have enough separate processing threads in the same application active at the same time, or have enough other processes with threads to keep the processor cores active, it really doesn't matter how many cores you have: most will be quite idle. This will be true of any OS.

In addition to all of that, no matter how many cores can be kept busy, the ultimate bottleneck for throughput is a function of how much the CPU L1/L2 cache is thrashed, combined with the latency and throughput of the memory FSB. Once you reach those limits, no number of additional cores will improve performance, and you'll be better off with fewer cores consuming less power, because even idle cores consume a certain amount of power, and thus generate waste heat. As effective as modern CPU's can be for heating a room (I keep my computer room/bedroom heated with my old dual p3-450 system by itself) they aren't efficient heaters in terms of BTU/kw hour...

Jonathan Thompson

You'd actually be surprised how little bandwidth the Opteron architecture can get away with. In most tests, for example, a dual-core Opteron is just as fast as a dual single-core Opteron, even though the former has only half the bandwidth. The Opteron is a much more latency-sensitive design, so DDR2 isn't going to help there, at least not until the DDR2-800+ designs start becoming more common.

And SATA has been on dedicated busses for quite awhile now.

"Browser: Links (2.1pre11; Linux 2.6.10-gentoo-r6 i686; 80x40)"

Wow, you are f--king cool.

The problem is, it's not really possible with current technology. There is a limited ability for the compiler to find parallelism within a sequential program, but its hard to get good technology that can seperate entire threads of execution. Stuff like OpenMP directives help, but those are really just the programmer specifying threading in a different way.

Agreed.

In fact, I think the future of parallel programming is not with compilers that convert sequential code into parallel code. But with easier to use languages for parallel programs.

While there has been a lot of work done in this area before, I believe that we are going to now see even more work done since desktop programs will HAVE to be multithreaded.

We will probably need to make it `easy' for the `average programmer' to create programs that can scale across a large number of cores as time progresses. Fortunately, we have some time yet.

We still have these problems:
1) memory gap - latencies, latencies, latencies
2) lack of parallelism in many programs
3) disk drives speeds are still magnitudes slower.
HDD are very important because that's where
all your data lives, and it's nonvolatile.

1) Overcome this by having a dedicated memory controller per core. In that way each core will have it's own path to the memory. (just like existing MP Opteron systems do)
2) So? Most programs that need more crunching power than exiting CPUs are easily ported to multi-core. Think about it. Fluid simulation, raytracing, particle simulation, database servers, web servers, etc. All can use as many cores as you ccan throw at them.
3) Use more memory, or a faster HD array. I was just seeing that some drives are up to 76MB/sec. If you really need that much speed, make a array of 10/15 of these for a perfomance of close to 1GB/sec. Even editing film resolution video rarely needs that much bandwidth.

Personaly, I welcome our new multi-core CPUs.

Not only that, but Windows will balance the load to the processers per application.

So you literally can burn a DVD while playing an intensive video game (DVD burning process will be on core 1, game will be on core 2).

Why put more cores into the chip??

They've no other choice. Chips used to decrease power consumption by a large amount each generation, due to physical limits that no longer happens to the same degree.

There's no longer any other real way of boosting performance with current designs. Boosting the clock on a complex chip makes it ever hotter and they've hit the limit of what can be reasonably cooled.

So, you can either add more cores at roughly the same clock rate, or simplify the cores and add more cores. Pushing the clock rate can still be done but it's very difficult, only IBM are trying this but they've had to simplify the architecture in order to do this.

We still have these problems:
1) memory gap - latencies, latencies, latencies

It's worse than that, latency is increasing.

2) lack of parallelism in many programs

...and the number of people who know how to parallelise is very limited.

3) disk drives speeds are still magnitudes slower.
HDD are very important because that's where
all your data lives, and it's nonvolatile.

There is hope there, Flash is catching up fast in $ per byte. Other types of RAM (FRAM, MRAM) are on the way which

--

The biggest problem is one nobody is talking about: Amdahl's law.
Doubling your cores does *not* double your power.

The next generation Pentium 4 (Cedar Mill) is supposed to have the VT extensions, so I should presume that any multi-core Pentium X would also have them. Pacifica is supposed to come out sometime next year and, like most of AMD's other extensions, I would imagine that it will be introduced across all the lines (like SSE3 was put on the Athlon 64's with the Venice/San Deigo core and on the X2 line at the same time. http://en.wikipedia.org/wiki/Virtualization_Technology has some useful information on the subject.

I managed to pick up an X2 3800+ processor and an nForce4 motherboard for $279 at Fry's on Black Friday.

Tell me THAT isn't a steal!

I was looking at a relatively low-end prebuilt computer the other day (can't remember the URL right off hand) it had a dual-core processor and if I remember correctly it was between $800 and $900. (I consider that to be relatively low-end, since I'm used to $2000 - $4000 computers.)

While that isn't really REALLY cheap. That's still awfully good for a prebuilt computer.

Most of those processes are asleep. A better figure is:

$uptime
0:05 up 11:56, 2 users, load averages: 0.19 0.08 0.03

Note the loadavg of less than 1.0.

I agree that most of the processes are asleep. The point I am trying to make is that if you are running one resource hungry process, there are still a LOT of other processes running on the system and each one of them requires CPU time at some point or another.

> I agree that most of the processes are asleep. The
> point I am trying to make is that if you are running
> one resource hungry process, there are still a LOT of
> other processes running on the system and each one of
> them requires CPU time at some point or another.

Yes, at some point or another. Let's say you have one resource hungry process that keeps one cpu busy, and a bunch of little processes that keep the second cpu busy 1/10 of the time. If the big process properly supported multiprocessing, both cpus would be busy all the time (minus communication overhead, which approaches zero if the multiprocessing support is "done right").

- Morin

I agree, and will push the point further. Obviously, the era of routinely coded intrisically multithreaded applications has not yet arrived. Yet even with conventional applications coded for single CPU environments, there are very clear performance improvements and advantages to a garden variety SMP environment which extends also to the newer multicore CPUs.

I've been running this sort of thing on my desktop for years, long before it was routinely fashionable. I've found that a machine running say two SMP 1GHz CPUs is at least as subjectively fast as an otherwise identical system running a single 2GHz CPU of the same family and generation. Further, I've usually spent no more, and ofter less for the SMP system using this stategy.

For most desktop applications, the feel of the system speed is based on the latency at the mouse-keyboard-screen to a user action. Once i86 CPUs passed 700MHz point, latency for most desktop users became a faily insignificant point. Most users see the latency increase and the system feel sluggish then several applications are competing for CPU cycles concurrently. With an SMP environment, one applications can continue to feel responsive on one CPU while another compute intensive application fully consumes the resources of the second CPU in the background (e.g. rasterization of a vector graphic file for printing). One CPU even at twice the clock speed would feel substantially slower.

For example, my main system on my desktop is an old Sun Ultra 60 with two 450 MHz 64bit SPARC CPUs, 1.5 GHz memory, and dual video cards on the UPA dedicated video bus in dual head config. It is an aging machine by any definition, but it does not feel slow, and remains very useful as a desktop. Aside from the SMP advantages, the video and memory buses are fast and wide. The CPU speed ultimately determines the absolute system throughput which by today's standards are very modest, but for routine desktop tasks, this is not apparent to the user.

Most of the "speed" issues were previously with realtime graphical ( e.g. gaming ) applications that often were more bound by the memory bandwidth and speed of graphics subsystems than the system CPU. Now, with very high memory and graphics bus bandwidth and very fast graphics subsystems, the CPU is usually the determinant of system speed for these applications. Until the gaming programmers and others what use system resources in "Von Neumann" single thread style are developing for multithread multiCPU systems, systems with single system CPUs at maximum clock speed are going to provide them the best performance.