Geolocate this post
Posted with LifeCast
Wednesday, October 29, 2008
Saturday, February 23, 2008
MultiCores - Software Falls Behind
We seem to be in a period, hopefuly fairly brief, where software development is lagging behind the hardware. If you buy a new server or desktop today its probably going to have at least two cores. Four core machines are also available and the number of cores can only increase over time.
However most software we write will not make use of these extra cores. Sure the operating system may run different programs on different cores, but if your software is processor intensive you are losing a lot by having it run on a single core and can be wasting much of your computers processing power.
You can write multi-threaded code in most languages and doing this will enable to use all the processors. However doing this is not trivial and can lead to bugs which happen randomly and are very difficult to find and fix.
DotNet has the ThreadPool with its QueueUserWorkItem method and the InvokeRequired method which you can call to check if its safe to directly run the code or if you need to invoke it via a delegate.
http://msdn.microsoft.com/msdnmag/issues/07/10/Futures/default.aspx
So we are waiting for the tools providers to do more of the hard work for us.
In the dotnet word we have the Task Parallel Library.
This allows you to replace the standard for loop with a call to the method Parallel.For
One of the paramaters is a delegate which should be the logic to run inside the loop.
Of course this logic has to be such that it doesnt rely on being run sequentially.
Theres a lot more to this experimental library which you can look at here :
http://channel9.msdn.com/Showpost.aspx?postid=384229
I think some of the work in here may end up in the core language at some time.
Of course if TPL ( Task Parallel Library Code ) is run on a single processor machine it will run as normal using the single processor. If you have more than one core available a algorithm looks at processor usage on each core to decide which cores to use.
Allen Bauer( CodeGear Chief Scientist ) is looking at implementing the TPL for Delphi : http://blogs.codegear.com/abauer/2008/02/22/38857
DotNet also has the parallel linq extensions :
http://www.microsoft.com/uk/msdn/screencasts/
screencast/292/Parallel-LINQ-PLINQ.aspx
This lets you parallilze your LINQ code.
Predating both of the above is the dotnet reasearch language comega :
http://research.microsoft.com/comega/
So if you need to make full use of the computer there are already some alternatives than getting into the low level world of ThreadPools and race conditions. Hopefully these alternatives will mature fairly quicly and move into the core product, however you are still going to have to do some changes to your code.
We seem to be in a period, hopefuly fairly brief, where software development is lagging behind the hardware. If you buy a new server or desktop today its probably going to have at least two cores. Four core machines are also available and the number of cores can only increase over time.
However most software we write will not make use of these extra cores. Sure the operating system may run different programs on different cores, but if your software is processor intensive you are losing a lot by having it run on a single core and can be wasting much of your computers processing power.
You can write multi-threaded code in most languages and doing this will enable to use all the processors. However doing this is not trivial and can lead to bugs which happen randomly and are very difficult to find and fix.
DotNet has the ThreadPool with its QueueUserWorkItem method and the InvokeRequired method which you can call to check if its safe to directly run the code or if you need to invoke it via a delegate.
http://msdn.microsoft.com/msdnmag/issues/07/10/Futures/default.aspx
So we are waiting for the tools providers to do more of the hard work for us.
In the dotnet word we have the Task Parallel Library.
This allows you to replace the standard for loop with a call to the method Parallel.For
One of the paramaters is a delegate which should be the logic to run inside the loop.
Of course this logic has to be such that it doesnt rely on being run sequentially.
Theres a lot more to this experimental library which you can look at here :
http://channel9.msdn.com/Showpost.aspx?postid=384229
I think some of the work in here may end up in the core language at some time.
Of course if TPL ( Task Parallel Library Code ) is run on a single processor machine it will run as normal using the single processor. If you have more than one core available a algorithm looks at processor usage on each core to decide which cores to use.
Allen Bauer( CodeGear Chief Scientist ) is looking at implementing the TPL for Delphi : http://blogs.codegear.com/abauer/2008/02/22/38857
DotNet also has the parallel linq extensions :
http://www.microsoft.com/uk/msdn/screencasts/
screencast/292/Parallel-LINQ-PLINQ.aspx
This lets you parallilze your LINQ code.
Predating both of the above is the dotnet reasearch language comega :
http://research.microsoft.com/comega/
So if you need to make full use of the computer there are already some alternatives than getting into the low level world of ThreadPools and race conditions. Hopefully these alternatives will mature fairly quicly and move into the core product, however you are still going to have to do some changes to your code.
Friday, February 22, 2008
Many months ago I wrote a post on AJAX toolkits for ASP.NET. Things have moved on a bit since then. Mainly Microsoft ASP.NET Ajax was released.
OK I still have concerns that Microsofts AJAX solution is overweight. However thats what the cache is for ! Overall I think that I would use Microsofts AJAX solution because its likely to be ubqitous so you are plugging into a community of code and Microsofts continuing development and integration into Visual Studio.
The UpdatePanel is great in that it makes it very quick and easy to ajaxify a website, the downside is network traffic may be much higher than you expect. So the updatepanel is great to impress your boss and get something working quickly, but I really recommend reading a copy of ASP.NET Ajax in Action. Its got a foreword and quote from Scott Guthrie and you cant really get a better recommendation than that. It tells you how to use the Microsoft JavaScript library - so maybe you can replace your use of JQuery/Prototype and standardise on Microsoft functions a lot more.
One of the best things I have found so far is AJAX Control Extenders. That JavaScript function you wrote that adds some functionality to a textbox ( for example ). You can now easily wrap it up inside a Control Extender. Now any developer in your company can attach your JavaScript behaviour to any TextBox, by clicking on smart tags inside Visual Studio 2008. I have done one of these extenders myself and its really very quick to do.
Even better theres a free library of controls and extenders, with source code, that anyone can contribute to. You can find it here : http://www.asp.net/ajax/ajaxcontroltoolkit/samples.
This is a collobration between Microsoft and the community.
I am little vexed by Microsofts determination to make the clientside look more like the serverside. Do we really want a page event cycle on clientside as well as serverside ? Maybe this will grow on me though. I would really hope developers would take the time to learn the differences between client and serverside and get some reasonable understanding of how to write their own JavaScript which doesnt rely on Microsofts library without being informed of the choices.
AJAX.NET Professional is still out there but development has now stopped.
Find it here : http://ajax.schwarz-interactive.de/CSharpSample/
Michael Schwarz did a great job on this in his free time and I enjoyed using this.
I havent used http://ajaxwidgets.com but have looked at a couple of demos and it looks really slick. Last time I looked it wasnt free but looks like they may have now changed the licencing model. Main issue its not Microsoft so not sure how it will survive long term. With this system you write what looks like serverside code, e.g. in an onclick event for a button, but its actually automatically actually run via AJAX call. I am sure there is more to it than that though ...
As I say my recommendation would currently be to use Microsoft ASP.NET Ajax for projects, though if you only want to use a little AJAX and want more control I still have a fondness for Ajax.Net
OK I still have concerns that Microsofts AJAX solution is overweight. However thats what the cache is for ! Overall I think that I would use Microsofts AJAX solution because its likely to be ubqitous so you are plugging into a community of code and Microsofts continuing development and integration into Visual Studio.
The UpdatePanel is great in that it makes it very quick and easy to ajaxify a website, the downside is network traffic may be much higher than you expect. So the updatepanel is great to impress your boss and get something working quickly, but I really recommend reading a copy of ASP.NET Ajax in Action. Its got a foreword and quote from Scott Guthrie and you cant really get a better recommendation than that. It tells you how to use the Microsoft JavaScript library - so maybe you can replace your use of JQuery/Prototype and standardise on Microsoft functions a lot more.
One of the best things I have found so far is AJAX Control Extenders. That JavaScript function you wrote that adds some functionality to a textbox ( for example ). You can now easily wrap it up inside a Control Extender. Now any developer in your company can attach your JavaScript behaviour to any TextBox, by clicking on smart tags inside Visual Studio 2008. I have done one of these extenders myself and its really very quick to do.
Even better theres a free library of controls and extenders, with source code, that anyone can contribute to. You can find it here : http://www.asp.net/ajax/ajaxcontroltoolkit/samples.
This is a collobration between Microsoft and the community.
I am little vexed by Microsofts determination to make the clientside look more like the serverside. Do we really want a page event cycle on clientside as well as serverside ? Maybe this will grow on me though. I would really hope developers would take the time to learn the differences between client and serverside and get some reasonable understanding of how to write their own JavaScript which doesnt rely on Microsofts library without being informed of the choices.
AJAX.NET Professional is still out there but development has now stopped.
Find it here : http://ajax.schwarz-interactive.de/CSharpSample/
Michael Schwarz did a great job on this in his free time and I enjoyed using this.
I havent used http://ajaxwidgets.com but have looked at a couple of demos and it looks really slick. Last time I looked it wasnt free but looks like they may have now changed the licencing model. Main issue its not Microsoft so not sure how it will survive long term. With this system you write what looks like serverside code, e.g. in an onclick event for a button, but its actually automatically actually run via AJAX call. I am sure there is more to it than that though ...
As I say my recommendation would currently be to use Microsoft ASP.NET Ajax for projects, though if you only want to use a little AJAX and want more control I still have a fondness for Ajax.Net
Subscribe to:
Posts (Atom)
