Quality not quantity

Submitted by quickone on Tue, 03/24/2009 - 6:41am

Intel and AMD are already talking about 6 and 8 core CPUs, looking at my 4 cores sitting idle 90% of the time and only one or two busy for heavy usage programs I don't see a point until the software catches up.  Yeah you can run 6 - 8 apps at the same time but it seems like their time and money would be better spent making 2 and 4 cores more efficient and faster until the software is there.  SSD coming into general use would help things along as well. The CPU is hardly ever the bottle neck these days.

i7 seems to be a step in the right direction.  AMD needs to get a better business model, so much potential piddled away

Login or register to post comments

this qoute says it best

Submitted by almax on Mon, 03/23/2009 - 9:35pm

 

""For decades, hardware engineers designed faster microprocessors while too many software engineers got lazy and hid their sloppy programming behind the blessings of Moore’s law. Now the programmers aren’t getting a free ride any more.""
--Tom R. Halfhill
--Maximumpc--09/19/05

Login or register to post comments

Actually I fail to see why

Submitted by majorsuave on Mon, 03/23/2009 - 7:51pm

Actually I fail to see why apps such as "tax report 2k9" or "MP3 player Z" would ever need more than one core. What is nice to know though is that I can run them all at once and don't suffer any shortage of power like I do regularly at work when I stumble on one of the old p4 1.6G.

Login or register to post comments

Operating Systems

Submitted by Caboose on Mon, 03/23/2009 - 12:53pm

 This may seem like a silly question, but Windows 7 (and Vista) and most recent versions of Linux, are they still programmed for single-core CPU's or have they been written to take better advantage of multiple cores?

 

-= I don't want to be dead, I want to be alive! Or... a cowboy! =-

Login or register to post comments

Parallel Software

Submitted by jwalch.hawk on Mon, 03/23/2009 - 12:51pm

"Unlike the chicken and the egg, in today's multicore environment, we can definitively say the hardware came first"

This is a bit strange of a statement since software can't, uh, actually have multiple cores.  But if you're referring to software parallelism, technically that's been around for a lot longer than multiple cores per se.  Java's supported concurrency/threads from pretty much the onset (which don't actually execute simultaneously, because when they were thought up the hardware didn't exist, but are managed such that they can be viewed as being approximately simultaneous).  But as for as parallelism in general goes, yeah, hardware was definitely there first.  It's almost mind-boggling how much is done in parallel just to do something as trivial as adding 2 + 2 (I'm serious - even simple addition is a parallel operation).  Which brings me to the issue I really wanted to comment on...

Hardware has always been parallel to some extent.  Generally speaking, lots of hardware performance increases have come as a result of doing more in parallel.  So it seems logical and easy to say that software should also benefit from being in parallel...  Except it's not that simple.  We (humans) do not tend to naturally think of operations as happening in parallel.  Most fundamental programming is taught with a sequential (read: not parallel) bias.  It is extremely non-trivial to approach solving a problem with a parallel algorithm.  How often do you think things out in your head and go, "Ok, if these 4 things happen at once then I can do these 8 things at once follow by these 6 things, etc, etc...."  We naturally think A followed by B.  Software is generally written the way we think.

The reason software being sequential wasn't a problem before was because the translation from sequential instructions into parallelism was done "under the hood" in the hardware.  The programmer didn't have to give a shit just how parallel the freaking adder was.  All it needed was for the adder to work.  How it worked didn't matter.  Multicore is fundamentally different.  Yes, the processor controls what instruction goes to which core...  But if the instructions are such that instruction B depends on the result from instruction A, you simply can't run instruction B until instruction A has done its work.  This is a problem because the instructions are the result of what the programmer does and not the hardware.

Yes, it would be ideal if code could be written such that many independent operations could take place at once.  But, first of all, many problems actually have very natural sequential solutions, so you're killing an ant with a nuclear weapon.  Secondly, you can't just flip a switch and turn an entire field that with such a largely sequential foundation on its head and make it embrace parallelism.  It can happen, but it will be a very, very, very long process.  You're talking years.

We need to stop bitching that developers should be multicore.  It's not going to happen soon.  Let's work on a better solution. 

Login or register to post comments

Its really no different than

Submitted by Muerte on Mon, 03/23/2009 - 12:43pm

Its really no different than programming for a console or Mac with the exception that the tools toprogram for these platforma have been around for awhile and just need modificatioin when there is a new model.

 I just can't understand why the tools are not coming faster. 

Login or register to post comments

Us Hardware

Submitted by Dwood15 on Mon, 03/23/2009 - 12:29pm

Us hardware enthusiasts have been waiting for 3+ years for not only 64 bit compliant software but multicore as well. At this point and learning programming myself I think that having an environment that better handles multicore and the way applications interact with the multiple cores would probably work better and more efficiently than the companies who develop the programs get down and dirty. A more self aware environment would be ideal.

Login or register to post comments