If you think that I and many many other people are going to forcibly throw away all their home equipment in 2009, you are drinking something good:-) I don't need HDTV or a home cinema, so why should I pay for them ? I just need to be able to watch the news or a movie occasionally and believe it or not 480 lines are sufficient for an enjoyable experience.
There is no law of nature, so to speak, that mandates buying new technology periodically. While my analog TV continues to work and let me watch my DVD movies, I am not replacing it unless it is a _free_ upgrade.
No Steam spyware on my machine, thank you. I don't need a service (esp. written by a game company) connecting to the Internet in the background and downloading software.
Also I don't think I should need an Internet connection to play a single-player game. It may seem like a worthwhile trade off for now - it is convenient, the game is not bad and most of all do have Internet connections after all. However we are giving up our freedoms one by one and I won't be surprised when the next version of Steam charges 25c each time you start the game.
So yes, I would gladly pay full price for a hacked version of the game - one that doesn't require a Steam account, social security number, zip code and good credit rating.
At least on my machine under Linux, Swing is definitely faster than SWT. Sounds almost absurd, but is true. I did a search some time ago and found posts claiming that IBM's official positions was that they were not interested in improving the speed of SWT-GTK. They can kiss my a** then:-)
SWT-FOX (http://swtfox.sourceforge.net/) looks like a good idea and is supposed to be faster, but I have never been able to get it to work satisfactory (font problems, crashes). AFAIK, it is being maintained by a single person in his free time. Perhaps RedHat or Novel should support the project.
Don't get me started on SWT anyway - I think the design is terrible; it looks like a somewhat cleaner port of MFC.
OK, I'll bite. What is the definition of a micro-kernel according to this book ? I've thought about it some and the only useful definition that I can think of is the one I know - separate address spaces. Everything else is too fluid and can be applied to to many other things.
Also, I am curious what is the name of the book and who is the author (and what are his credentials) ?
We see this misconception way too often. Modular design, well defined interfaces, etc. have nothing to do with a microkernel. You can apply those excellent design principles in a monolithic kernel, you can even apply them in regular applications:-) The one distinguishing feature of a microkernel is the separation of address spaces of its components.
Don't take the meaning of a "name" literally - it doesn't have to be a combination of letters (cats are notorious with spelling:-). Technically speaking the two syllables pronounced with a certain inflection, by a voice that it recognizes, _is_ the cat's name and it does recognize it.
To make an example, as far as I know in languages like Chinese intonation plays a tremendous role - two completely different words might sound exactly the same to us - one might be our name, the other someting else, but that doesn't mean that we don't know our names.
I have had many pets and have came to the conclusion that animals are much closer to us than we are used to assuming. They can think (albeit very primitively), they have memory, they make plans, etc - to say that it is all instinct and mimicking would be a vast oversimplification. This is a dangerous line of thinking though - a pig is as smart as a cat, but I do love eating pork chop.
I think semantics is pretty important in a story entitled "Microkernel: The comeback", involving Andrew Tanenbaum, who happens to be very clear on this subject, don't you think ?:-) NT is not a microkernel by Tanenbaum's definition, and by almost anybody's definition, as far as I can tell. I have seen some misguided journalistic attempts to label it as such, but there is no point in continuing the confusion.
Further, we don't have to look at NT's code to judge its architecture. The design is pretty clear and has been explained in depth. Then there are projects like ReactOS. There also exist real microkernels, so we can compare. In short, there isn't lack of information on the subject, so we don't have to speculate.
The most I have seen in books is that NT "borrowed" some aspects from a microkernel design, and I think that even such a claim is misguided. Perhaps part of the confusion stems from NT having loadable drivers, and another part from using messages - both of these are usually present in a microkernel design but they are not the distinguishing features of one. It is like saying that a car borrows its design from a train because they both have windows.
To wrap up: here is the defition of a microkernel in Wikipedia: http://en.wikipedia.org/wiki/Microkernel . It clearly confirms my point. However I am happy to discuss opposing points of view, if there is some evidence to support them. After all, that is why we are hear on Slashdot - to chat (and I mean it:-)
I am sorry but you are wrong. NT was _never_ a microkernel. It does use messages for userland->kernel calls and interdriver calls, however this does not make it a microkernel. The purpose of the messages (IRPs) is not to achieve isolation between modules, but to facilitate an universal implementation of asynchronous operations. An operation is started, then it waits in a queue somewhere and is completed asynchronously by an interrupt - any implementation would require something similar, but NT enforces it all over, even for synchronous operations for consistency. An IRP contains direct pointers to data, to callback functions, etc - nothing to do with a microkernel at all.
Ironically, this design makes kernel programming for NT fairly difficult (although I do not think it can be avoided), causing lots of instability. It is very easy to "damage" an IRP by writing garbage, do something with it when it is in the wrong state, completely lose it, etc - all leading to an OS crash. Again, the opposite of what we would see in a microkernel.
What you are saying about "object brokering" is technically true, but sounds like pure marketing speak to me:-) There is a directory of named object in the kernel and it provides lookups etc, but this is by far not its primary function.
NT is not and was never a microkernel and it was never intended or claimed to be, including by its creator Dave Cuttler. This is especially true in the context of this story, because Tanenbaum's definition of a microkernel is very clear.
Isn't he saying that you don't need to use J2EE _at all_ ? If you ask me J2EE is a pile of crap, but Java itself is a very usrful language. Yes, I agree it can be slow in absolute terms, but there isn't anything faster offering the same ease, so for now it is a good compromise.
Windows XP Embedded lets you do a thing similar to what you are describing - you can create an image only with the components you select and the tool keeps track of component dependancies so it prevents you from creating a broken image by requiring the missing dependancies.
This is where the fun starts. There are dependancies you wouldn't imagine. I wanted to create a very minimalistic XP image with basic API functionality and TCP/IP networking. Impossible. The DHCP component requires the SNMP component, which requires the HTML Help component, which requires, yes you guessed it, Internet Explorer !!!! DHCP client -> Internet Explorer : it makes perfect sense.
Then I foolishly wanted to add SP2's firweall support. The firewall required all kinds of COM and DCOM components, including Microsoft Transaction Server (!!!) or similar crap and of course Internet Explorer as well. Why, oh, why, does a network firewall require Microsoft Transaction Server ?
Of course these dependancies are not always critical - I am sure I could have deleted IE from the image and DHCP would still have worked - but nevertheless it is funny that MS claims IE is not a part of the OS, while it must be present in the simplest OS image:-)
Getting back to the subject - I definitely wouldn't use a tool like nLite - you end up with an unsupported custom version of Windows and you never know what is going to break, which service pack or update is not going to install, etc. It is not worth the hassle.
While the English translations are trully brilliant, Lem should be read in a Slavic language to be fully appreciated. He constantly plays with words and makes up new ones, which IMHO are not translatable to English.
It is difficult to explain - a language expert would do it much better than me. In English Lem is still interesting and funny, but something subtle is missing. It bugs me that there is no way for English readers to ever fully enjoy it.
In all honesty I don't speak Polish, although I can understand some, but I have read Lem in Bulgarian, Russian and English.
Now look who is trolling. Proclaiming yourself for a Windows guru is not going to earn you points on Slashdot, but lets ignore that:-)
Being written in an interpreted language doesn't really have anything to do with anything - although I am open to reading insightful comments on the subject.
Your complaint about an "additional piece of software" also doesn't make a lot of sense to me. Everything is an additional piece of software in Linux - even the X server. That is why Linux is so flexible and configurable. Why is installing a package a problem ? BTW, if you are scared of reboots - don't - they are not necessary in Linux:-)
Last but not least, Registry hell is a lot worse than config file hell.
However, the professor in question wants people to switch from laptops to paper, basically making them less efficient at note-taking, giving them even less time to pay attention to what she's saying.
Less efficient ? I don't know about other people on/. , but I find it a lot easier to write down random text with pen and paper than using a keyboard. I can type C code very fast (I've been doing it for the last 15 years), but I would need to take typing lessons if I had to enter arbitrary text.
I agree a 100% about providing the material ahead of time.
Sadly this shows once again that "pure" OSS cannot make money on its own. By "pure" I mean not relying on hardware sales and support contracts. Don't get me wrong - I use OSS, love OSS and I want OSS to be able to make money - but I cannot understand how that could possibly happen. Especially with the BSD license.
All the jokes are funny, etc, but, come on guys, you do realize that this is complete nonsense, right ? RIGHT ????
Programming is hard enough without adding absurd layers of abstraction and indirection. This reminds me of the ridiculous 3D "programming environments" in movies like Swordfish (which I though was a very enjoyable movie, btw).
Very interesting read, thanks. It does show that in practice Java is fast enough, but it doesn't address my point. Too many things are omitted - restricted pointers, manual cache control, etc. I could delve into the specifics but I doubt anyone would read that om Slashdot.
For one the paper doesn't even mention the pointer chasing problem, which is inherent in the definition of the language. In Java almost everything is an object reachable through a pointer - accessing the object means stalling the CPU until the memory load of the pointer itself has completed. In loops this leads to easily measurable slowdown of at least 10x. A not that uncommon worst case scenario is an array of complex numbers or 3D coordinates. It is possible to work around the problem by using separate arrays for each component, but doing that in a high-level language like Java is a shame, not to mention extermely inconvenient.
As I said earlier, matrix calculations do not necessarily have this problem since they most likely use single-dimension arrays of primitive values. When the range checking is eliminated, there is no fundamental reason why accessing an array of primitive values should be any slower in Java compared to pure C. It all depends on how expensive optimizations can be done by the JITter at runtime. I doubt a JIT will do complex code reorganization optimizations, but it is possible.
Generally speaking, achieving high performance always requires fine-tuning, which is all but impossible in Java. You can't examine the generated code, you can't affect how the GC allocates memory, you can't selectively use assembler (JNI is too expensive), you can't selectively enable optimizations, you can't manually insert prefetch or cache control instructions in the generated code. You are stuck with what the current JIT does and there is no way to improve that. If experience has taught us anything, it is that there is always room for improvement. The problem is when you can't get to it.
All the performance problems specific to "C" mentioned in the referenced paper - e.g. aliased pointers, cache unfriendly memory allocation, etc - are solvable in C using restricted pointers, a custom memory allocator, etc. On the other hand the problems specific to Java cannot be fixed without modifying the language or at least the JIT compiler.
Let me put it another way. A hypothetical situation. Assume that you are an expert in both C and Java. You are given the task to write the fastest possible implementation of some algorithm. You are given plenty of time compared to the complexity of the algorithm. You can use either Java or C. When you are done, your implementation will be benchmarked against others (e.g. mine) and the author of the slower one will be killed. Which language would you choose ?
For the fanatics I would like to point that this has nothing to do with liking or disliking Java or saying that it is too slow. Java is a lot more robust and cost effective than C/C++.
Am I really wrong about complex optimizations like cache blocking and prefetching ? I might be - however unless you provide a verifiable reference I am disinclined to believe you. Many static compilers don't even do those.
To answer your question about why C++ would be faster. Examine the C++ declarations below and think about how fast a sum of the entire array would be in each case. If you like to look at the bigger picture, think about memory consumption too.
I shouldn't really be replying, since you already said that all the specific instances which prove Java is slower don't matter - how could I argue with that ? However I would like to benefit from your obvious knowledge of the matter.
Also, please note that I didn't say "C/C++ is best", which you seem to be implying in your last paragraph - I was commenting in the context of the thread about Java vs C/C++ performance for matrix computations. I don't care about language wars, because obviously everyone who disagrees with me is wrong...:-)
I have seen many claims about Java's performance, ranging from reasonable to absurd and ridiculous. For example:
Java is as fast or faster than C for everything
Java is as fast or faster than C for everything that Java is normally used for
Java is slower but fast enough for most things
Java's performance doesn't matter because everything is IO and network bound anyway
etc
I would love to share my opinion on these subjects some other time, but for this post they are irrelevant.
So, getting back to the subject. Obviously you agree that for the scenario I am describing, Java is slower than C. You contend that this results from "translating line by line from C into Java syntax". OK, enlighten me then. What is the Java-specific solution for keeping complex numbers in an array ? You can go wild - use any Java tool and technology. This is not an artifical scenario. The same problem exists for arrays of 2D or 3D coordinates, actually arrays of anything except primitive types, so if you present a solution I will be very grateful and even offer to buy you a beer ot two (or a dozen!).
Sorry, but you are wrong. For some things Java can never be as fast as C/C++ due to the definition of the language itself - things like lack of value objects, specifics of method dispatching, late binding, etc.
I don't want to go into details here, but as a good example of Java's inefficiencies think about an array of complex numbers in Java and C/C++. Java is at least an order of magnitude slower in this particular example and no JIT can ever fix that unless the language itself is changed. If you don't believe me and you know C and Java you can even try it - write a small program performing a simple operation with the array - for example sum of the elements.
Admittedly matrix algorithms do not necessarily exhibit the problems I am talking about. However I sincerely doubt that the current generation of JAVA JITs do complex optimizations like loop reshaping, cache blocking, prefetching, etc.
This only goes further to show my point that it is not as easy as simply "rubbing the clit". Your experience with the g-spot does sound very exciting (and fulfilling)
I for one salute our clit-rubbing and g-spot-hitting overlords:-)
Slashdot Mirror
If you think that I and many many other people are going to forcibly throw away all their home equipment in 2009, you are drinking something good :-) I don't need HDTV or a home cinema, so why should I pay for them ? I just need to be able to watch the news or a movie occasionally and believe it or not 480 lines are sufficient for an enjoyable experience.
There is no law of nature, so to speak, that mandates buying new technology periodically. While my analog TV continues to work and let me watch my DVD movies, I am not replacing it unless it is a _free_ upgrade.
No Steam spyware on my machine, thank you. I don't need a service (esp. written by a game company) connecting to the Internet in the background and downloading software.
Also I don't think I should need an Internet connection to play a single-player game. It may seem like a worthwhile trade off for now - it is convenient, the game is not bad and most of all do have Internet connections after all. However we are giving up our freedoms one by one and I won't be surprised when the next version of Steam charges 25c each time you start the game.
So yes, I would gladly pay full price for a hacked version of the game - one that doesn't require a Steam account, social security number, zip code and good credit rating.
At least on my machine under Linux, Swing is definitely faster than SWT. Sounds almost absurd, but is true. I did a search some time ago and found posts claiming that IBM's official positions was that they were not interested in improving the speed of SWT-GTK. They can kiss my a** then :-)
SWT-FOX (http://swtfox.sourceforge.net/) looks like a good idea and is supposed to be faster, but I have never been able to get it to work satisfactory (font problems, crashes). AFAIK, it is being maintained by a single person in his free time. Perhaps RedHat or Novel should support the project.
Don't get me started on SWT anyway - I think the design is terrible; it looks like a somewhat cleaner port of MFC.
Instead of saying anything rude, here is the f*cking link:
/ java2/download.html
:-)
http://wwws.sun.com/software/communitysource/j2se
That said, the license is somewhat less than free
OK, I'll bite. What is the definition of a micro-kernel according to this book ? I've thought about it some and the only useful definition that I can think of is the one I know - separate address spaces. Everything else is too fluid and can be applied to to many other things.
Also, I am curious what is the name of the book and who is the author (and what are his credentials) ?
We see this misconception way too often. Modular design, well defined interfaces, etc. have nothing to do with a microkernel. You can apply those excellent design principles in a monolithic kernel, you can even apply them in regular applications :-) The one distinguishing feature of a microkernel is the separation of address spaces of its components.
Don't take the meaning of a "name" literally - it doesn't have to be a combination of letters (cats are notorious with spelling :-). Technically speaking the two syllables pronounced with a certain inflection, by a voice that it recognizes, _is_ the cat's name and it does recognize it.
To make an example, as far as I know in languages like Chinese intonation plays a tremendous role - two completely different words might sound exactly the same to us - one might be our name, the other someting else, but that doesn't mean that we don't know our names.
I have had many pets and have came to the conclusion that animals are much closer to us than we are used to assuming. They can think (albeit very primitively), they have memory, they make plans, etc - to say that it is all instinct and mimicking would be a vast oversimplification. This is a dangerous line of thinking though - a pig is as smart as a cat, but I do love eating pork chop.
What exactly does "inspired" mean in this case? I am "inspired" by John Holmes but that doesn't mean I have a 12" cock does it?
LOL, dude ! If that isn't moderated funny, I don't what what should be!!!
You read funny books :-)
:-) NT is not a microkernel by Tanenbaum's definition, and by almost anybody's definition, as far as I can tell. I have seen some misguided journalistic attempts to label it as such, but there is no point in continuing the confusion.
:-)
I think semantics is pretty important in a story entitled "Microkernel: The comeback", involving Andrew Tanenbaum, who happens to be very clear on this subject, don't you think ?
Further, we don't have to look at NT's code to judge its architecture. The design is pretty clear and has been explained in depth. Then there are projects like ReactOS. There also exist real microkernels, so we can compare. In short, there isn't lack of information on the subject, so we don't have to speculate.
The most I have seen in books is that NT "borrowed" some aspects from a microkernel design, and I think that even such a claim is misguided. Perhaps part of the confusion stems from NT having loadable drivers, and another part from using messages - both of these are usually present in a microkernel design but they are not the distinguishing features of one. It is like saying that a car borrows its design from a train because they both have windows.
To wrap up: here is the defition of a microkernel in Wikipedia: http://en.wikipedia.org/wiki/Microkernel . It clearly confirms my point. However I am happy to discuss opposing points of view, if there is some evidence to support them. After all, that is why we are hear on Slashdot - to chat (and I mean it
I am sorry but you are wrong. NT was _never_ a microkernel. It does use messages for userland->kernel calls and interdriver calls, however this does not make it a microkernel. The purpose of the messages (IRPs) is not to achieve isolation between modules, but to facilitate an universal implementation of asynchronous operations. An operation is started, then it waits in a queue somewhere and is completed asynchronously by an interrupt - any implementation would require something similar, but NT enforces it all over, even for synchronous operations for consistency. An IRP contains direct pointers to data, to callback functions, etc - nothing to do with a microkernel at all.
:-) There is a directory of named object in the kernel and it provides lookups etc, but this is by far not its primary function.
Ironically, this design makes kernel programming for NT fairly difficult (although I do not think it can be avoided), causing lots of instability. It is very easy to "damage" an IRP by writing garbage, do something with it when it is in the wrong state, completely lose it, etc - all leading to an OS crash. Again, the opposite of what we would see in a microkernel.
What you are saying about "object brokering" is technically true, but sounds like pure marketing speak to me
NT is not and was never a microkernel and it was never intended or claimed to be, including by its creator Dave Cuttler.
This is especially true in the context of this story, because Tanenbaum's definition of a microkernel is very clear.
Isn't he saying that you don't need to use J2EE _at all_ ? If you ask me J2EE is a pile of crap, but Java itself is a very usrful language. Yes, I agree it can be slow in absolute terms, but there isn't anything faster offering the same ease, so for now it is a good compromise.
Sorry, but this is ridiculous.
:-)
apt-get install java-package
fakeroot make-jpkg jdk-1_5_0_06-linux-i586.bin
sudo dpkg -i sun-j2sdk1.5_1.5.0+06_i386.deb
If this took you a whole hour, you are in BIG trouble my friend
What is the factual error precisely ?
But that was the point wasn't it ? You did not really think that DHCP actually requires DHCP to work, didn't you ?
Definitely don' delete IE :-)
Windows XP Embedded lets you do a thing similar to what you are describing - you can create an image only with the components you select and the tool keeps track of component dependancies so it prevents you from creating a broken image by requiring the missing dependancies.
This is where the fun starts. There are dependancies you wouldn't imagine. I wanted to create a very minimalistic XP image with basic API functionality and TCP/IP networking. Impossible. The DHCP component requires the SNMP component, which requires the HTML Help component, which requires, yes you guessed it, Internet Explorer !!!! DHCP client -> Internet Explorer : it makes perfect sense.
Then I foolishly wanted to add SP2's firweall support. The firewall required all kinds of COM and DCOM components, including Microsoft Transaction Server (!!!) or similar crap and of course Internet Explorer as well. Why, oh, why, does a network firewall require Microsoft Transaction Server ?
Of course these dependancies are not always critical - I am sure I could have deleted IE from the image and DHCP would still have worked - but nevertheless it is funny that MS claims IE is not a part of the OS, while it must be present in the simplest OS image :-)
Getting back to the subject - I definitely wouldn't use a tool like nLite - you end up with an unsupported custom version of Windows and you never know what is going to break, which service pack or update is not going to install, etc. It is not worth the hassle.
While the English translations are trully brilliant, Lem should be read in a Slavic language to be fully appreciated. He constantly plays with words and makes up new ones, which IMHO are not translatable to English.
It is difficult to explain - a language expert would do it much better than me. In English Lem is still interesting and funny, but something subtle is missing. It bugs me that there is no way for English readers to ever fully enjoy it.
In all honesty I don't speak Polish, although I can understand some, but I have read Lem in Bulgarian, Russian and English.
Now look who is trolling. Proclaiming yourself for a Windows guru is not going to earn you points on Slashdot, but lets ignore that :-)
:-)
Being written in an interpreted language doesn't really have anything to do with anything - although I am open to reading insightful comments on the subject.
Your complaint about an "additional piece of software" also doesn't make a lot of sense to me. Everything is an additional piece of software in Linux - even the X server. That is why Linux is so flexible and configurable. Why is installing a package a problem ? BTW, if you are scared of reboots - don't - they are not necessary in Linux
Last but not least, Registry hell is a lot worse than config file hell.
Less efficient ? I don't know about other people on /. , but I find it a lot easier to write down random text with pen and paper than using a keyboard. I can type C code very fast (I've been doing it for the last 15 years), but I would need to take typing lessons if I had to enter arbitrary text.
I agree a 100% about providing the material ahead of time.
Sadly this shows once again that "pure" OSS cannot make money on its own. By "pure" I mean not relying on hardware sales and support contracts. Don't get me wrong - I use OSS, love OSS and I want OSS to be able to make money - but I cannot understand how that could possibly happen. Especially with the BSD license.
All the jokes are funny, etc, but, come on guys, you do realize that this is complete nonsense, right ? RIGHT ????
Programming is hard enough without adding absurd layers of abstraction and indirection. This reminds me of the ridiculous 3D "programming environments" in movies like Swordfish (which I though was a very enjoyable movie, btw).
Very interesting read, thanks. It does show that in practice Java is fast enough, but it doesn't address my point. Too many things are omitted - restricted pointers, manual cache control, etc. I could delve into the specifics but I doubt anyone would read that om Slashdot.
For one the paper doesn't even mention the pointer chasing problem, which is inherent in the definition of the language. In Java almost everything is an object reachable through a pointer - accessing the object means stalling the CPU until the memory load of the pointer itself has completed. In loops this leads to easily measurable slowdown of at least 10x. A not that uncommon worst case scenario is an array of complex numbers or 3D coordinates. It is possible to work around the problem by using separate arrays for each component, but doing that in a high-level language like Java is a shame, not to mention extermely inconvenient.
As I said earlier, matrix calculations do not necessarily have this problem since they most likely use single-dimension arrays of primitive values. When the range checking is eliminated, there is no fundamental reason why accessing an array of primitive values should be any slower in Java compared to pure C. It all depends on how expensive optimizations can be done by the JITter at runtime. I doubt a JIT will do complex code reorganization optimizations, but it is possible.
Generally speaking, achieving high performance always requires fine-tuning, which is all but impossible in Java. You can't examine the generated code, you can't affect how the GC allocates memory, you can't selectively use assembler (JNI is too expensive), you can't selectively enable optimizations, you can't manually insert prefetch or cache control instructions in the generated code. You are stuck with what the current JIT does and there is no way to improve that. If experience has taught us anything, it is that there is always room for improvement. The problem is when you can't get to it.
All the performance problems specific to "C" mentioned in the referenced paper - e.g. aliased pointers, cache unfriendly memory allocation, etc - are solvable in C using restricted pointers, a custom memory allocator, etc. On the other hand the problems specific to Java cannot be fixed without modifying the language or at least the JIT compiler.
Let me put it another way. A hypothetical situation. Assume that you are an expert in both C and Java. You are given the task to write the fastest possible implementation of some algorithm. You are given plenty of time compared to the complexity of the algorithm. You can use either Java or C. When you are done, your implementation will be benchmarked against others (e.g. mine) and the author of the slower one will be killed. Which language would you choose ?
For the fanatics I would like to point that this has nothing to do with liking or disliking Java or saying that it is too slow. Java is a lot more robust and cost effective than C/C++.
Am I really wrong about complex optimizations like cache blocking and prefetching ? I might be - however unless you provide a verifiable reference I am disinclined to believe you. Many static compilers don't even do those.
To answer your question about why C++ would be faster. Examine the C++ declarations below and think about how fast a sum of the entire array would be in each case. If you like to look at the bigger picture, think about memory consumption too.
double arr1[10000];
double * arr2[10000];
I shouldn't really be replying, since you already said that all the specific instances which prove Java is slower don't matter - how could I argue with that ? However I would like to benefit from your obvious knowledge of the matter.
Also, please note that I didn't say "C/C++ is best", which you seem to be implying in your last paragraph - I was commenting in the context of the thread about Java vs C/C++ performance for matrix computations. I don't care about language wars, because obviously everyone who disagrees with me is wrong ... :-)
I have seen many claims about Java's performance, ranging from reasonable to absurd and ridiculous. For example:
I would love to share my opinion on these subjects some other time, but for this post they are irrelevant.
So, getting back to the subject. Obviously you agree that for the scenario I am describing, Java is slower than C. You contend that this results from "translating line by line from C into Java syntax". OK, enlighten me then. What is the Java-specific solution for keeping complex numbers in an array ? You can go wild - use any Java tool and technology. This is not an artifical scenario. The same problem exists for arrays of 2D or 3D coordinates, actually arrays of anything except primitive types, so if you present a solution I will be very grateful and even offer to buy you a beer ot two (or a dozen!).
Sorry, but you are wrong. For some things Java can never be as fast as C/C++ due to the definition of the language itself - things like lack of value objects, specifics of method dispatching, late binding, etc.
I don't want to go into details here, but as a good example of Java's inefficiencies think about an array of complex numbers in Java and C/C++. Java is at least an order of magnitude slower in this particular example and no JIT can ever fix that unless the language itself is changed. If you don't believe me and you know C and Java you can even try it - write a small program performing a simple operation with the array - for example sum of the elements.
Admittedly matrix algorithms do not necessarily exhibit the problems I am talking about. However I sincerely doubt that the current generation of JAVA JITs do complex optimizations like loop reshaping, cache blocking, prefetching, etc.
This only goes further to show my point that it is not as easy as simply "rubbing the clit". Your experience with the g-spot does sound very exciting (and fulfilling)
I for one salute our clit-rubbing and g-spot-hitting overlords :-)