zero.racetime.com.au - Version 6.2a

zero.racetime.com.au/

Zero

You must login to post new threads

Topic: Some more defense for multi-core

Will Harris published a very good article, "In defence of multi-core", which did quite a good job of explaining how a multi core processor - be it dual core, quad core - will benefit consumers in the future, in which I can fully see a lot of the ideas mentioned similar things being put to use.

It's something we see frequently - and we saw a very good example of it when Vertex Shaders came along to GPUs, and later another cycle when Pixel Shaders came along. Graphic intensive applications were being held back as developers tried to get as much eye-candy into their games as they could on the available hardware, but along came the manufacturers such as nVidia and ATI, along with Microsoft, and said "hey, how about we give you this technology, which will help you out greatly". Allowing complex instructions to be done in hardware gave a huge boost, and freed up that processing power being used by the GPU and CPU in other areas to be able to handle it quicker - this time natively.

An example Harris picked on was that people were claiming we'd never use 512MB of video RAM - though by the time we were seeing cards with that much memory on them, games were already well and truly capable of putting that amount of graphics memory to use; professional cards had long been using those kinds of amounts, and were hungry for far more.

There was a side of the argument he hasn't looked at though, again certainly a benefit of going to multi-core systems. The thing that puzzled me is that while he was quick to point out tasks that we could already do, just not well enough, there's tasks that can't be achieved easily on single core or single processor systems. What's really going to be interesting however, is when developers start to jump on this bandwagon. Not consumers, but developers.

The first roadblock or excuse a developer will use to not write an application to be multi threaded is that the systems aren't readily available. Their customers don't have the systems that can take advantage of them, so what is the point of them adding significant complexity to their applications just to maybe get a performance increase for 3% of their customers? That excuse is going to be thrown out very soon, as over the next few years we'll see that figure climb to upwards of 50%, held back by consumers still hanging onto their old systems. Simply having these CPUs available and in use on the market will in itself encourage their support to be increased - a clear contrast to what we've seen in the past whereby successful technology is usually developed in response for a need for better products without completely overhauling the current architectural way of doing things.

Unfortunately, complexity isn't a problem which you can just develop simple patterns to get around. Having a thorough understanding of the issues caused by making an application multithreaded is one thing, but being able to have that ability to consider all those problems as they apply to your application, for each and every line is something far more difficult. The sad fact is that out of all those programmers out there, only a very small portion of the talent pool has the skill to be able to understand and handle these concepts correctly. This alone causes issues, and the only way to increase the talent pool, which is already a mere puddle, is to get as many people into the pool to learn as best they can. This means that those capable absolutely have to be in that space, or their talent will just go to waste.

What will also help significantly though is developers having the CPUs themselves to test against. Developing for hardware you don't have is always a problem - you know it's out there, you have to support it, but you don't have the hardware yourself to test for. Obviously this doesn't often apply when we're talking about big businesses, but certainly with small and independent developers. As developers themselves get hold of this hardware, this won't be so much of a problem, and they'll simply be left with the "it's too complicated" excuse (which in their fairness, it is - multithreaded programming is literally one of the easiest areas to get wrong - it's like pointers for people who "just don't get it" magnified a thousand times).

Where we'll all really be benefited though is where ideas are come up with that haven't previously been thought of. As a result of observing how we can now do things, new ideas are going to start showing up, ones which previously would not have been conceived due to this significantly different way software will be developed. These methods and ideas aren't just going to crop up without developers having exposure however, and it's going to require that paradigm switch to encourage them to think in the vastly different way required to best design software for multiprocessor architectures.

Simply the presence alone of a market sporting multi core processors left, right and centre is going to help fuel this paradigm shift, but refusing to purchase technology because it's not supported, this time around, will only hurt the industry and not encourage development. Where we really need to try to push this though is on developers, as developers are more likely to develop for something they have - and good developers like playing with new toys, technologies and ideas. If we can encourage developers to go this way, or better yet, encourage companies to support this technology and encourage their employees to take this paradigm seriously, the talent pool to support other developers trying to same thing will far quicker accelerate development for all attempting it in a heavily multi-threaded style.

Helix login

Pages

News categories

Affiliates

Links

News

Registered user

Unregistered user

105972 visits. 2645 news articles. 350 journal entries