Why did anyone rate this as insightful? Neither the poster nor the moderators took the time to try to understand the not so funny but still valid reference to Skype favoring Intel over AMD http://slashdot.org/article.pl?sid=06/02/13/201523 6.
Just Google Slashdot with "AMD VoIP" and voila, there it is at the top.
No wait. What am I complaining about? This is Slashdot.
I have a few issues with this article. Why isn't there any mention of exactly which JVM he is using? Why is there no source code for his tests?
I happen to write a JVM for a living, and there are huge differences between how locks perform in different situations on the different VMs.
When it comes to using synchronized vs Locks, and that synchronized should be implemented with the methods in Lock et.c. people tend to miss two important facts.
Having monitorEnter/monitorExit paired gives you nice possibilities for optimization (like keeping track of recursion depth as a result of the lock operation, since you know which unlock should be the real unlock et.c.).
You can potentially synchronize on every object in Java, and uncontended thread local synchronization should be fast and not introduce memory overhead.
If you think that the implementation of synchronized use O/S or user level mutexes as the implementation for the fast case you should probably read http://citeseer.ist.psu.edu/bacon98thin.html and continue with the articles referencing it.
But then again, this is Slashdot, why would people read anything about the subjects they're commenting on.
Doesn't mean a damn thing unless software is written to take advantage of it. Damn PC developers can't write software to take advantage of HT (with some exceptions, I know), but hopefully this chip's power can be realized fully.
Why is it that people keep stating that you have to write software that targets HT specifically? This is not true. Any multithreaded application will benefit from it. It is up to the OS to present you with the CPUs, real or virtual.
Yes, there are specific issues with handover during tight spinloops et.c., but only people writing locking or timing code should have to deal with those issues. Not your average application programmer.
I may be completely stupid but I happen to work at a company that is developing a server side VM for Java and I really don't understand what you mean with "the branch prediction problem".
Are you assuming that static compilers do some kind of interprocedural or whole program analysis? This is normally not the case.
Do you think that you can't do inlining or method specialization where you take runtime information into account in a JIT? You definitely can.
Our VM does advanced optimizations at runtime that amongst other things take single implementations of methods into account. These optimizations can be undone at runtime when new classes are loaded that invalidate the assumptions that the optimizations are based upon.
This means that you won't do virtual dispatches to methods that only have a single implementation.
Try to do that with a static compiler for a dynamic language.
Slashdot Mirror
Wobbly Windows(TM) and other useful features...
http://compiz.org/
http://beryl-project.org/
In Capitalist America Music Rips You!
Why did anyone rate this as insightful? Neither the poster nor the moderators took the time to try to understand the not so funny but still valid reference to Skype favoring Intel over AMD http://slashdot.org/article.pl?sid=06/02/13/201523 6.
Just Google Slashdot with "AMD VoIP" and voila, there it is at the top.
No wait. What am I complaining about? This is Slashdot.
--
Hi... I'm grumpy.
I have a few issues with this article. Why isn't there any mention of exactly which JVM he is using? Why is there no source code for his tests?
I happen to write a JVM for a living, and there are huge differences between how locks perform in different situations on the different VMs.
When it comes to using synchronized vs Locks, and that synchronized should be implemented with the methods in Lock et.c. people tend to miss two important facts.
If you think that the implementation of synchronized use O/S or user level mutexes as the implementation for the fast case you should probably read http://citeseer.ist.psu.edu/bacon98thin.html and continue with the articles referencing it.
But then again, this is Slashdot, why would people read anything about the subjects they're commenting on.
Doesn't mean a damn thing unless software is written to take advantage of it. Damn PC developers can't write software to take advantage of HT (with some exceptions, I know), but hopefully this chip's power can be realized fully.
Why is it that people keep stating that you have to write software that targets HT specifically? This is not true. Any multithreaded application will benefit from it. It is up to the OS to present you with the CPUs, real or virtual.
Yes, there are specific issues with handover during tight spinloops et.c., but only people writing locking or timing code should have to deal with those issues. Not your average application programmer.
I may be completely stupid but I happen to work at a company that is developing a server side VM for Java and I really don't understand what you mean with "the branch prediction problem".
Are you assuming that static compilers do some kind of interprocedural or whole program analysis? This is normally not the case.
Do you think that you can't do inlining or method specialization where you take runtime information into account in a JIT? You definitely can.
Our VM does advanced optimizations at runtime that amongst other things take single implementations of methods into account. These optimizations can be undone at runtime when new classes are loaded that invalidate the assumptions that the optimizations are based upon.
This means that you won't do virtual dispatches to methods that only have a single implementation.
Try to do that with a static compiler for a dynamic language.
What about parallel gay geniuses? =)