"With all the modern systems using multi-core and multi-processor systems, tapping this new power is an interesting challenge for developers. It also fundamentally starts the shift on how your 'average Joe' interacts with a computer and things that he/she expects to be able to. First, check out the 'Manycore Shift' paper from Microsoft. Second checkout the Parallel Extensions to .NET 3.5 which is a programing model for data and task parallelism. It also helps with coordination on parallel hardware (such as multi-core CPU's) via a common work schedules. There is also a new Parallel Computing Dev Center on MSDN. Before you download the December 2007 CTP, make sure you have the RTM bits of the .NET 3.5 runtime. There are also a number of bugs fixed in this new CTP. If you want a quick introduction then check out a few videos available."
Post a Comment
Member since:
2005-07-13
Member since:2005-07-06
What will decide how well Java goes with the amount of cash which Microsoft is throwing at the problem is whether the Java 'community' actually start addressing long standing performance issues with Java.
Its open sourced, are we going to see vendors finally put their money where their mouth is and assign resources to develop it?
PS. According to CNBC right now, rumour is that SAP might be a take over target, possibly by Microsoft. If it means a Microsoft take over, it'll be the defection of a very large player in the Java market to the .NET world, assuming Microsoft decides to go that route.
Member since:2006-03-23
Member since:2005-07-06
Member since:2005-07-06
There are several goodies with Java and concurrent programming. Actually first,
Java 5 already came with a new set of concurrent API, like ThreadPools, Queues, Concurrent collections, Executors, Locks, Semaphores etc.
In java 7, there will be the new Fork library. some info can be found here:
http://www.ibm.com/developerworks/java/library/j-jtp11137.html
Also, sun is working on transactional memory on their Rock chip. once it is out, i believe it will support Java virtual machine.
they are thinking of adding some small language features for making the locks easier too.
But ultimately, the programming part is still not as easy as it should be.
There is a new language called Fortress, currently it's alpha version is running on jvm in interpreted mode, it has impressive concurrency features.
Member since:2006-01-06
I'm using the new Concurrency library in Java 5 extensively. It's making coding this multi-threaded application a breeze.
Whenever MS does something, though, they pay their heralds to laud it with golden trumpets like it's the coming of the Messiah. *yawn* Time to get back to work.
Member since:2005-07-06
"Whenever MS does something, though, they pay their heralds to laud it with golden trumpets like it's the coming of the Messiah"
Not to get nitpicky, but the features new to Java 5 that the parent poster mentioned have been in .Net for 5+ years now in the System.Threading namespace.
Member since:2005-07-06
partially, yes. also "for 5+ years" is not really correct.
for a comparison:
http://java.sun.com/javase/6/docs/api/java/util/concurrent/package-...
Edited 2007-12-04 00:16
Member since:
2005-07-06
Anyone who has done any sort of multi-threading development in any language (not just .Net) knows firsthand just how much of a PITA it is to write a properly threaded application. I've long been wondering when the language writers were going to start baking stuff like this into the respective toolkits.
Threading should be something that you don't have to worry about except in edge cases, i.e. an app I write should be able to automatically scale itself based on the number of processors available, thread scheduling/signaling should take place automatically, and manual synchronization needs to be a thing of the past. I was actually trying to explain these concepts to a friend of mine recently (making a case as to why quad cores just aren't worth the extra money quite yet since most apps won't utilize all the cores), and how each new thread in an app increases complexity exponentially which is why the majority of consumer apps simply aren't truly multithreaded.
I look forward to seeing what MS comes up with.
Edited 2007-12-03 02:26
Member since:2006-03-24
I wonder if you will ever see this coming. Think about it, when you need to develop multithreaded program, what things that you worry most? race condition. language or platform will never able to forcast race condition based on what you code because data model can be extremely complicated when involving business rules.
Member since:2005-07-06
I disagree: while it's true that the problem won't ever be fully solved by language/platform features, some software construct like STM or Erlang-style|CSP (never understood the difference) looks easier to use for parallel programs that using thread and locks manually.
Member since:
2006-03-01
I think that microsoft has frameworkitis. There are some huge performance problems in the CLR, and a lot of opportunity for further optimization.
But instead of fixing the core, they just add layer upon layer of framework code on top of it to make trivial things even more trivial.
The .NET framework is on version 3.5, while the CLR is still stuck on 2.0.
Anyway: Here is how to write multithreaded code in a nutshell:
-Do not use locks.
-Use immutable objects and referentially transparent methods whenever possible.
-Use message passing.
-Follow the rule: everything that is mutable stays on one thread, while everything that shares threads is immutable.
Member since:2006-06-03
Member since:2005-07-29
i.e. Reinvent Lisp (or some other functional language). :-)
Note also that the immutable object approach is suggested by one of Microsoft's main developers on PLINQ, one of the Parallel Extensions for .NET:
http://www.bluebytesoftware.com/blog/PermaLink,guid,58392086-9f4c-4...
http://www.bluebytesoftware.com/blog/PermaLink,guid,bae6ac13-2a95-4...
Member since:2005-07-06
"The .NET framework is on version 3.5, while the CLR is still stuck on 2.0."
The CLR version is the same as the .Net version: http://msdn2.microsoft.com/en-us/library/ms230176(VS.90).aspx This is because .Net is the umbrella term for CLR + BCL + CLI (actually, the CLR is MS's implementation of the CLI). Regardless, we are now on v3.5 of the CLR.
"-Do not use locks."
For non-functional languages, locks are an (if not THE) imperative part of multi-threaded application design, unless you want race conditions and deadlocks all over your application.
I'd also love to know what these performance problems are that you speak of. It has been shown on numerous occasions that a properly designed .Net app has performance approaching that of unmanaged code.
Edited 2007-12-03 13:13
Member since:2005-07-06
Member since:2005-07-06
Not if you're using message passing. I'm not going to claim that locks are not required at all, but good design and message passing can help eliminate them.
Member since:2005-07-06
Member since:2006-03-01
Message passing between threads does not involve any serialization. You just create a (preferably immutable) message object on the source thread and enqueue it into the message queue of the target thread.
If you want message passing between different processes or even different machines, then of course serialization gets involved.
Member since:2005-07-07
Member since:2007-11-16
Member since:
2006-03-01
No. If you run a low level program such as http://www.codeproject.com/dotnet/DetectDotNet.asp to enumerate the available CLRs on a machine where .NET framework 3.5 is installed, you get the following:
Is .NET present : Yes
Root Path : C:WindowsMicrosoft.NETFramework
Number of CLRs detected : 2
CLR versions available :-
1.1.4322
2.0.50727
Press any key...
If you use shared mutable state for communication between threads, you have not much choice but to use locks.
But there are safer alternatives such as message passing. Of course somewhere deep in the message queue code there will still be a lock or some other low level synchronization primitive. But an application programmer will never have to mess with that. See the BeOS API for pervasive use of message queues.
The biggest performance problem is this: http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.asp.... This can lead to a factor 5 to 10 performance degradation compared to C++ when doing numerically intensive code. Still much better than java though, since java does not have structs at all.
Fortunately, this will be addressed in the next (3.0) release of the runtime.
But there are various optimizations that java VMs have been doing for ages that the CLR does not do, such as virtual method inlining. And the CLR also does not even attempt to vectorize code on CPUs with SSE3.
Edited 2007-12-03 14:03
Member since:2005-07-06
Interesting, and thanks for correcting me. I've always been under the impression that CLR = MS's implementation of the CLI, which in turn = a good part of the .Net Framework and therefore the same version. MS's versioning scheme is cryptic to say the least, ala according to your info the following is true:
- We're on v3.5 of the .Net Framework
- We're on v2.0 of the CLR
- C# is in v3.0
Are you sure about Java inlining virtual methods? I just did a quick Google and wasn't able to confirm that. I thought that by definition, a virtual method cannot be inlined which is why a lot of folks were concerned about all methods being virtual in Java by default. I'm by no means versed in compiler theory, but I don't see how a virtual method can be inlined.
Member since:2005-07-07
http://portal.acm.org/citation.cfm?id=353191
Method devirtualization has been around in the JVM for quite a while. That paper (sadly requires a subscription) does a moderately good job of covering the various techniques used.
Member since:
2006-03-01
- We're on v3.5 of the .Net Framework
- We're on v2.0 of the CLR
- C# is in v3.0
That is correct as far as I understand it. But I would not bet my life on it, since as you mentioned the MS versioning scheme is a tad confusing.
(Java is not much better in that area though. The current version is called Java SE 6, but internally it is called 1.6)
See for example
http://java.sun.com/products/hotspot/docs/whitepaper/Java_HotSpot_W...
It is a neat trick. Often a virtual method gets called only on one or a small number of types. So you specialize the method for each possible type and then can inline it just like a non-virtual method.
This requires some knowledge which is often not available at compile time. Therefore the java hotspot compiler analyzes the code while it is running and then optimizes only the parts that can profit most from optimizations (so-called hotspots, hence the name).
Of course since in C# methods are not virtual by default, the pressure to do something about the virtual method invocation overhead is not as high as in the case of java. Nevertheless it would be nice for microsoft to tackle this problem.
Member since:
2007-07-13
As others have mentioned, the recent Java concurrency libraries (building on the work of Doug Lea) are quite usable, but like everything, you still have to know at least something about what you are doing.
There is another way of getting great parallel performance, without warping languages further. I guess the earliest posters were alluding to this. This is putting as much of the concurrency as possible into the library implementations of the runtime.
As an example of how this is done, consider the OpenGL model for GPU interaction with vertex and fragment shaders. You write the small piece of code that is to be run in parallel (in the OpenGL Shading Language) and the OpenGL driver is completely responsible for distributing it between the streams (vertex/fragment/or unified shader units) of the GPU. The programmer never has to worry about load-balancing between the shader units in GPUs with differing architectures. The driver does all that and the developer only needs to supply the custom code to be executed. That is quite a nice way of working for a limited class of problems. However, plenty of work can be done in libraries to utilise parallelism in a manner transparent to the user.
As another example, in Java 1.6u5 (in the testing stage) *all* of the drawing is done using DirectX on Windows. Many operations (such as convolutions) are done in parallel on the video hardware (using pixel shaders) and are around 30 times faster than the software equivalent (on common hardware). All of this is transparent to the end user (zero code changes required to benefit from this), can't fault Java for that.
Quite often putting the parallesim in the libraries can make enough of a difference to users, in certain situations, so that the developers don't jump through hoops to achieve better performance through multithreading.
Member since:2006-03-18
Yeah, sure, I can see a good case for this when you are doing CPU intensive graphics operations that are easily to parallelize, but I find it hard to imagine another simple use case.
Parallelize the Collections framework? Meh. Maybe you could find some sort of parallelized sorting algorithm that would improve sorting of large datasets - at the cost of making smaller sorts slower. I just don't see any quick wins here.
Member since:2007-07-13
My point was that the libraries should be parallelised, where possible and sensible. This can make enough of a difference that the developer might not then have to parallelise their own code to improve performance.
Some things, such as the Collections framework are trickier to parallelise, as you point out - but if this package is too difficult parallelise effectively then how many users would do the multithreading themselves (and if users started to, then you will have the inefficiency of each application doing the multithreading rather than a single expert implementation by the library maintainer).
I would be surprised (after running profiling) that a single collections sort would be the largest source of time spent in most applications. Multithreading is usually used to get around blocking I/O or the delays caused by human interaction.
Member since:2006-03-18
In the comments here somebody linked to an article for similar parallel extensions to Java targeted for Java 7. This article presented an example of a parallelized recursive algorithm that finds the maximum value of all of the element in a list.
Now, obviously there is a minimum list size threshold below which the concurrency overhead swaps any possible performance increase, and you are better off single threading. The example tested with a variety of thresholds on a variety of platforms, including a P4 with CMT, all the way up to a 64 thread Niagara. What struck me was the fact that performance was all over the place depending on the platform. The "sweetspot" varied from architecture to architecture, quite significantly.
This is a real problem for anybody who wants to parallelize their framework. How do you come up with a general purpose solution that performs well everywhere?
Member since:
2007-04-29
grr. i could not see the pdf or the wmv files (i'm running a mac) but as far as i could see they addressed the wrong problem. writing multithreaded code is not hard, but writing multithreaded code with no deadlocks, race conditions or proper locking is hard, did they made that any easier?
i saw some video a long time ago on channel9 about transactional memory, that looked like a real solution.
