Linked by Thom Holwerda on Fri 15th Jun 2007 12:08 UTC, submitted by cragnotil
Intel Researchers at Intel are working on ways to mask the intricate functionality of massive multicore chips to make it easier for computer makers and software developers to adapt to them. These multicore chips will also likely contain both x86 processing cores, as well as other types of cores. A 64-core chip, for instance, might contain 42 x86 cores, 18 accelerators and four embedded graphics cores. In addition, Intel has updated its Itanium roadmap.
Order by: Score:
Multiple core types?
by Almafeta on Fri 15th Jun 2007 12:26 UTC
Member since:

Personally, that's what's most interesting to me, and what seems like has more potential...

Reply Score: 1

RE: Multiple core types?
by Wes Felter on Fri 15th Jun 2007 16:14 UTC in reply to "Multiple core types?"
Wes Felter Member since:

It certainly has potential... for confusion, difficulty of programming, and underutilization of hardware.

Reply Score: 2

RE[2]: Multiple core types?
by bnolsen on Fri 15th Jun 2007 23:33 UTC in reply to "RE: Multiple core types?"
bnolsen Member since:

This really is a stupid attitude.

Build it and they will come. Programmers are lazy and it's a waste to optimize for hardware you can't get because it's not available or you can't afford to buy.

At work we have an 8 core system (total cost $2501) and I develop heavily on it. Right now I'm looking around for a 32 or 64 core system to test on to see where our real bottleneck is. Sadly we've got one third party libary we rely on that isn't thread safe. With 8 cores this library accounts for about 6% of run time, I'd like to see what that goes up to with 32 or 64 processors.

The code is slightly over a year old, was written and tested as single thread until April this year. Back filling threading took about a week and we're getting about 6.85 cores worth of work out of the system.

Of course this is on linux, 64bit. So far testing on dual core windows show solid scalability and we'l get around to installing windows on that box next week or whenever I want to spend a day cursing microsoft.

Edited 2007-06-15 23:37 UTC

Reply Score: 1

RE[3]: Multiple core types?
by flanque on Sat 16th Jun 2007 00:26 UTC in reply to "RE[2]: Multiple core types?"
flanque Member since:

You've gone slightly off topic, but I do agree the original poster's attitude is stupid.

Reply Score: 2

RE[3]: Multiple core types?
by Wes Felter on Mon 18th Jun 2007 18:39 UTC in reply to "RE[2]: Multiple core types?"
Wes Felter Member since:

It sounds like you are actually agreeing with me. Multiple identical cores (like your 8-core system) are good; multiple cores of different types are bad (the more specialized, the worse they are). If an application can't use those specialized cores, then you have silicon that is just sitting idle when that app is running.

Reply Score: 2

How long will this policy last?
by lemur2 on Fri 15th Jun 2007 12:55 UTC
Member since:

The policy is here:
One wonders how long that would last in the face of a single 64-core chip.

Then there is the Linux policy on this, which goes:
"Of cores it's free!".

Reply Score: 5

RE: How long will this policy last?
by flanque on Sat 16th Jun 2007 00:29 UTC in reply to "How long will this policy last?"
flanque Member since:

I think Microsoft will have to change their attitude to licensing as multi-core becomes vastly popular, as well as the limitations they put into their products, particularly home end-user Windows releases.

If I am limited due to Microsoft's code or licensing models I will certainly be looking elsewhere for an OS.

Reply Score: 2

'bout time :)
by helf on Fri 15th Jun 2007 13:06 UTC
Member since:

Sweet! I can't wait for these.

Reply Score: 2

This is...
by suryad on Fri 15th Jun 2007 13:10 UTC
Member since:

Nehalem apparently but with 8 cores as a starting point from what I understand.

Reply Score: 1

Not convinced
by ecko on Fri 15th Jun 2007 13:56 UTC
Member since:

I'm still not convinced that this massive number of cores is going to be the right way to go from here on out. Transferring scheduling complexity into software is a concept that hasn't worked well for Intel before and it makes me wonder why they're doing this again.

If we look back at the Itanium we see one of it's major drawbacks was that to get the full power out of the chip, you needed to have 3 instructions running at any given time. Anyone who's written for the Itanium will tell you that keep the thing running at 100% capacity was nearly impossible unless you were talking about crunching raw numbers in an easily parallelized way.

I'm also curious to see how Intel is dealing with the massive amounts of traffic that are going to be traveling across the CPU bus. Cache synchronization between that many cores must be a nightmare.

I saw the justification for 2 cores and even 4 cores. Ok I'll even stretch it to 8 for very specialized applications and high def video encoding.

Reply Score: 4

RE: Not convinced
by MightyPenguin on Fri 15th Jun 2007 14:46 UTC in reply to "Not convinced"
MightyPenguin Member since:

You're absolutely right.

Let's not take this hardware thing too far, after all, "640K is more memory than anyone will ever need"

(no, supposedly Gates never said that)

Reply Score: 1

RE[2]: Not convinced
by Kroc on Fri 15th Jun 2007 14:55 UTC in reply to "RE: Not convinced"
Kroc Member since:

If so, can I go on the record in saying "Two cores is more than anyone will ever need". I'm more likely to be remembered for saying something wrong, than something right.

In other news, a man got stuck in his toilet when he forgot to put the seat down. He said that he wouldn't have done it, if he had hindsight.

Reply Score: 2

RE[3]: Not convinced
by Michael on Fri 15th Jun 2007 16:54 UTC in reply to "RE[2]: Not convinced"
Michael Member since:

Sorry. In order to be remembered, you have to have not said it, but let a myth get about that you have said it.

Reply Score: 1

RE: Not convinced
by Marcellus on Fri 15th Jun 2007 14:52 UTC in reply to "Not convinced"
Marcellus Member since:

Anyone who's written for the Itanium will tell you that keep the thing running at 100% capacity was nearly impossible unless you were talking about crunching raw numbers in an easily parallelized way.

Isn't number crunching why you'd go Itanium?

Aside from that, it's not like Intel is not doing anything (developer tools wise) to help take advantage of more cores, etc.

Reply Score: 2

RE[2]: Not convinced
by ecko on Mon 18th Jun 2007 13:52 UTC in reply to "RE: Not convinced"
ecko Member since:

Isn't number crunching why you'd go Itanium?

It is but that's not what it was designed for. Intel originally wanted the Itanium to take over the server market first and move on to desktop chips in the future. It didn't work out that way and for a while it looked like Intel was going to lose it's shirt on the chip. If you want to crunch lots of numbers in a specialized scientific app you can use some sort of vector processor(Cell, Alitvec) which is designed to work on multiple pieces of data at once not a general purpose CPU that can run 3 instructions at once.

I'm not saying that multiple cores are a bad thing, far from it, I'm saying that software has a long long way to go and I don't think we'll get there until long after these chips are out and we have some time to play. Parallelism is something we(Computer Scientists) have been trying to do forever and there's just some things that can't be done in parallel.

There are lots of bottlenecks in CPU architecture right now, memory bandwidth is the most obvious.

Reply Score: 1

RE: Not convinced
by Luminair on Fri 15th Jun 2007 15:35 UTC in reply to "Not convinced"
Luminair Member since:

"Right way", more like "only way".

Intel and AMD can see the chip frequency ceiling, and it isn't very far ahead of what we have now. They are doing the multicore thing now because their business would be damaged if they ran out of frequency increases to sell people, but they still have to innovate and increase performance. So they are pacing themselves on the core speeds, and multiplying the number of cores.

And today, multiple cores are the best alternative way to increase total chip performance.

PS: Desktop users can easily find uses for 2-4 cores. These will prevent lockups when Outlook takes all the CPU time from IE, for example. But using 128 or 500 cores is a huge problem to solve, so we are trying to solve it ASAP. Imagine programming in a language "easier" than Java but is faster than C because it runs on 64 cores. That is the kind of dream that some computer scientists would like to see become a reality, but it is a very hard thing to do ;) ;)

Reply Score: 2

RE: Not convinced
by Silent_Seer on Fri 15th Jun 2007 18:08 UTC in reply to "Not convinced"
Silent_Seer Member since:

It's simple, use a compiler that exploits parallelism in the code and distribute the tasks across the cores, just like MIPS did. Trouble is, one must use a recompiled software for such a processor (using a compiler specifically targetted for such processors). With the emphasis being on compatibility, (meaning old software) yes, keeping all the cores busy is problem. And Intel by the way does have native compilers which can do the above task mentioned.

More is simply better, in my opinion. Let the native software for these chips arrive, along with improvements (not that they are already not there) in OSes to take advantage of the multiple cores. I am sure they will blow away everthing there was before. And this is just in case of Intel, but also Ultrasparc, Cell etc.

Reply Score: 1

Don't get caught up in the numbers...
by cmost on Fri 15th Jun 2007 15:06 UTC
Member since:

Much like the days when Megahertz was the prominently featured specification (and selling point) on desktop PC's, now cores seem to be the new marketing buzz word. Evidenced in part by Intel's switch to "Core 2 Duo" as its new CPU moniker as opposed to simply "Pentium 5." This is all just a marketing ploy to get home users to upgrade more frequently. How many cores does one need to type an e-mail, balance the family budget and monitor Ebay? Sure, many home users are editing video, streaming multimedia and playing high tech games in higher numbers than before but today's processors can already handle those tasks with aplomb. Users should use their common sense when purchasing new computers or considering an upgrade. Get a machine that does what you need and don't be concerned about multiple cores that won't likely be used by day to day activities anyway. For software developers thinking of utilizing multiple cores to effect fancy effects and implement useless features, try instead to make a bug free product that simply works and works well.

Reply Score: 5

Excel Hearts Choi Member since:

True, but operating systems seem to require more and more resources do do simple tasks. Office suites are growing and growing, Firefox is using more and more memory, indexing software (Beagle) slows the computer from time to time, etc. Software is playing into the hands of hardware vendors.

Reply Score: 2

Luminair Member since:

Writing software without bugs is a bit like being a healthy human being: We know the solution, its just that not everyone is mentally capable of choosing to do the right things ;)

Highly concurrent computing (the programming part of this especially), though, is a problem we have yet to solve super well.

Reply Score: 2

JonathanBThompson Member since:

For most tasks, you're absolutely correct, adding more cores will just mean that much more of the chip real estate is wasted 99% of the time (which is probably the average idle time on most personal computers 99% of the time).

What Intel may be hoping for is perhaps a paradigm shift that only makes some sense when using multiple cores. I can actually think of something that they may try to push along the development of that can take advantage of more cores than they can hope to ever manufacture and put under the hood of a PC:

Neural networking....

Granted, as far along as it is, it doesn't come close to working as well or as fast as even a lot more primitive creatures for doing many tasks, and part of that is simply we don't have a sufficient understanding yet of how everything works at such a low level, and the other part of that is, that while there is specialized hardware available that is designed to simulate a bunch of neurons and synapses, it's very specialized, and for all I know, no longer being made, since I read about it many years ago, because they couldn't find enough commercial market for it. However, with what's available today in fabricating general purpose multi-core processors at several Ghz clocks, there's suddenly a huge capacity available compared to what exists in past technology, and even better yet, it leads to easy integration with more traditional computer tasks.

Will people start pushing neural networking to take advantage of all it may offer (real or perceived, and I acknowledge there's been statements for several decades about artificial intelligence coming of age "Soon!") or will they just continue on with what's been done in the past? Time will tell if people are willing and able to expend the time and energy towards that, or if they've seen too many sci-fi movies like the "Terminator" series where SkyNet takes over ;)

Reply Score: 1

drfelip Member since:

I realize AI has a lot of potential, but in a world where even a word processor behaves unexpectedly from time to time, I'm afraid the Skynet scenario is not the worse it could happen... Maybe, just maybe, AI could learn how to create bug-free software, teach us, and thus avoid the creation of a mad ultracomputer.

Reply Score: 1

lemur2 Member since:

This is all just a marketing ploy to get home users to upgrade more frequently. How many cores does one need to type an e-mail, balance the family budget and monitor Ebay?

Speaking for myself, I want to get into virtualization, so that I can run two OSes at the same time. Not dual boot ... but run two OSes at the same time.

My current machine is getting long in the tooth, it has served its purpose well but it won't last forever.

I want Linux to be the host OS, because of security. I want Windows XP to be the guest OS, for those odd applications that are still mired in a Windows-only world of yesteryear. I want to have Linux as the host OS so that the frail Windows guest OS would be protected as far as possible.

Ubuntu 7.04 supports KVM for the kernel. What I need then is as stated here:
... I need a processor capable of supporting KVM. I'm looking at a Core 2 Duo E6300 processor.

I'm also looking at a machine with an Intel GMA graphics chip, so I can have an open source native 3D graphics driver.

I'm looking at a GMA 950 or GMA X3000.

Get a machine that does what you need and don't be concerned about multiple cores that won't likely be used by day to day activities anyway.

The above machine does what I want.

With a machine like that I should be able to boot Kubuntu (especially later this year when I hope to be able to run KDE4), have a stable full 3D "all the bling" sexy desktop, and still run the odd Windows applications at the same time if I want to.

Edited 2007-06-17 10:58

Reply Score: 2

steverez1 Member since:

I have both of those chipsets in use with different pc's if it helps the 950 seems more stable (at least with the current drivers) in Ubuntu, Suse & Vista. The X3000 has better preformance with games on Vista such as FSX(If thats a concern)but I get lockups

Reply Score: 1

Reason software bloat
by Eric Martin on Fri 15th Jun 2007 17:09 UTC
Eric Martin
Member since:

Is because harddrives are slow and people want every stupid POS loaded up and ready. Think of every button and action as a program.

Why is there no emphasis on Parallel processing like Cell? Graphics and media would benefit. Compilers not there yet?

Reply Score: 1

RE: Reason software bloat
by ThanhLy on Fri 15th Jun 2007 18:07 UTC in reply to "Reason software bloat"
ThanhLy Member since:

There absolutely is an emphasis on parallel processing. What makes you think there isn't?

The graphics and media industry is full of software and tools that take advantage of multiple cores. My favorite example being Newtek's Lightwave 3D model/animation package. The rendering engine lets you pick how many threads you want working on rendering. Lots of rendering engines have this feature as well, but Lightwave is the only one I've seen so far that supports up to 16 threads.

Reply Score: 2

nice but ....
by antwarrior on Fri 15th Jun 2007 19:37 UTC
Member since:

It's taking longer than everyone has expected, updating applications to take advantage of multi core chips. When you make more "processors" available to an application the complexity increases incredibly, beyond the skill of most programmers out there. It takes more than just throwing a task to a thread , you have to change so many things and monitor so many others so that things don't go horribly wrong.The architectural and algorithmic changes are not trivial, neither is debugging or bug fixes. This is one of the reasons i did not rush to get a multi core chip, IMHO, it is going to take several years before we get anywhere near maximising the potential of this technology.Application vendors will need to maintain applications design to work on single and multi core cpus. Do you see any company doing this anytime soon? How hard was it to get Photoshop's next release working, as Mac made it's transitions. The changes that Intel announced are a step in the right direction but let's face it folks, it's not going to do much to bring the power to desktop applications sooner.

Reply Score: 1

Requires a new way
by akauppi on Fri 15th Jun 2007 19:42 UTC
Member since:

I recently playd around with parallelizing Lua, a small embedded language, to see how easy it would be to make _any_ program hugely parallel in nature. It is / can be.

As stated here, the current tools don't really reach further than 2- maybe 4-cores. Having a locking infrastructure never felt that good anyways, we need message passing and seamless parallelism.

My Lua Lanes approach allows any function or a set of functions to be made into a "lane", run as an OS side thread, but seemingly like any other function would be. There is no locking involved, Lanes takes care of that. If you wait for your function's results before they have emerged, then you will stall for another thread. Only then. I believe this is called "futures" in general language lingo (see Wikipedia).

Another approach that brings seamless parallelism is data flow programming. I've done a small bit of work using LabView, and the concept is truly nice for _certain_ tasks. Anyways, it's parallel in nature the way circuit diagrams are. And the system, not you, spreads the flow over to any number of cores there might be.

In order to utilize tens of cores, we need programming tools that make it easiest to express the problem at hand in a parallel way, to begin with. And the runtime cost of having just a one core shouldn't be too high - on Lanes it's around 5% penalty. Dual core users get around 30-50% benefit.

Oh, one pragmatic way of utilizing multicore in a flow-like environment came to my mind. And this is simple. ;) Use filesystem piping to bind your data processing cycles together, like on a production line. Each process runs in parallel, with multiple cores _truly_ parallel. No locking will be required, no multithreading libraries either. But multicore will certainly benefit - slowest part of the pipeline becomes the speed of the whole line.

Edited 2007-06-15 19:46

Reply Score: 3

RE: Requires a new way
by vegai on Sun 17th Jun 2007 10:48 UTC in reply to "Requires a new way"
vegai Member since:

Hi, a!

I recently playd around with parallelizing Lua, a small embedded language, to see how easy it would be to make _any_ program hugely parallel in nature. It is / can be.

This seems to be a problem that functional languages solve very well. Perhaps you've read of this already.

Joe Armstrong reports a speedup of 3,6 on a four-core processor for an ideally concurrent problem, and a real-world program having a speedup of 1,8. That's without any changes whatsoever to the program, just from building the Erlang system to support SMP.

Of course, all that would be irrelevant if Erlang's concurrency would be hard to implement. Fortunately, it's very simple. Everything is a process and processes communicate with each other solely by message-passing.

All that in mind... what happens with lanes if the function inside has side-effects?

Edited 2007-06-17 10:50

Reply Score: 1

RE[2]: Requires a new way
by akauppi on Sun 17th Jun 2007 17:24 UTC in reply to "RE: Requires a new way"
akauppi Member since:

All that in mind... what happens with lanes if the function inside has side-effects?

Depends on what you mean by side effects.

The function group (like Erlang process) may not have outside references, they simply do not work (= all upvalues are nil). Meaning the "globals" for the lanes are different, they don't share data. In this way, the lanes cannot have side effects.

If you mean C library side-effects, like multiple lanes requiring the same library, and doing things there, the libraries are used as if they would be used from a multithreaded C program. Most popular C libraries are multithreading capable, I guess.

Reply Score: 1

by anonymous-bert on Sat 16th Jun 2007 00:19 UTC
Member since:

I'd like to see greater abstraction provided by hardware, OS's and compilers. In theory, this should also result in more stable, less bloated and less buggy application code.

Reply Score: 1

there is no a need for so many x86 CPU cores
by Radek on Sun 17th Jun 2007 08:47 UTC
Member since:

in a desktop computer. For a better performance there is still some Hz left and IPC will increase too.
What this all development shows is a chip which combines many types (DSPs, vector units, dedicated hardware accelerators for graphics for an example) so usual woes of SMP programming might not apply because those cores will be utilized for parallel processing.

But considering something like 4xCPU@3GHz x86 chips will be available for not that much money in relatively close timeframe it might be there will not be demand from desktop users.

The C2D which I have already is more than enough already for me.

Reply Score: 1