But you seem to be ignoring the fact that writing CPU specific assembler is still being done by the compiler. Yes, I think writing software directly in C is going to be phased out, but unless the actual architecture of hardware changes I don't see any reason not to store machine code in between runs of the software. That seems to me like you're intentionally hamstringing the system.
Heh. I didn't say you shouldn't store machine code in between runs of the software.
All I am saying is move the compiler to the client machine (which is more trusted by users anyway) add a few safety & runtime features and distribute applications as bytecode or source rather than binary.
Memory allocation leaks, direct memory addressing errors, buffer over-runs and a lack of a good enforced security sandbox for the application, lack of garbage collection.
I can't imagine you really think the recompilation of source code for N different platforms and the need to package separately for all those platforms too is actually a good thing in its-self?
There are many reasons why i'm sure VMs will win out, the performance penulty where there is one is small compared to the quite large gains in development speed and improved code quality in developing large scale apps.
Anyway... we could argue this one all night and I don't disagree that you can write such and such a bit of code more efficiently in C but I stand by my prediction that over the next few years, less and less code will be natively compiled. Compiling code to a native format will be slowly phased out in the same way that these days you don't often see people write CPU specific assembler.
Regardless of the performance issues the future of software development is going to be running non-native code on a virtual machine as this has so many advtantages including portability/distribution, security and efficiency of developing large scale systems.
Most new enterprise server side software is now being developed in Java or.NET. With the release of the next version of windows and Visual Studio most client side software will also run on a VM. Linux is bound to catch up eventually either through the Java, the.NET or another route (python?).
Another thing to note is that it was always possible to write more efficient assembler than C, but it was often easier to write more efficient C than assembler due to better code layout, easier management of libraries, code reuse and the manageability of developing larger apps. A lot of people find the same is true when comparing C to Java - Garbage collection being a good example of this.
why bother kludging around with a language which was meant to be interpreted if you're going to compile it?
Given that we want the security, stability, portability and other benefits that a virtual machine provides and that the virtual machine runs non-native bytecode and that the JIT is nearly as fast as compiled code and faster in some circumstances - compiling java code to native is pointless from a performance perspective in most practical cases.
In fact GCJ compiled java is usually slower than running under a modern JIT. The reasons for compiling to native is probably more to do with the license restrictions on redistributing the Sun JVM. Due to the licensing restrictions most distros won't contain a full java implementation by default and therefore native comilation and the use of classlibrary may be the only way to conveniently redistribture your java on most linux distros.
You can get garbage collection for C/C++ and they have the same benefits/drawbacks as the ones in java, although the java ones are now quite advanced.
I was only pointing out that garbage collection can improve speed over explicit allocate/deallocate calls - therefore the fact that java has garbage collection isn't neccessarily a disadvantage in terms of performance.
To be honest and I know this wasn't the original discussion I don't find the performance of the JIT that bad in terms of CPU. For web serving for example a cheapo dell can server serve well over 1.5k req/sec whilst doing some processing each request on a 1.5 JVM in server mode. This performance is good enough for server side processing. There are of course many advantages such as the excellent class library and jakarta projects.
On the client side java is all but dead anyway due to a combination of the AWT/Swing crapness, microsoft killing it and the memory bloat issues. The one thing that was never an issue client side was the speed of running bytecode under a good JIT. Maybe the apps seemed slow but that was always swing or more likely the fact that your machine was swapping.
Obviously you can't have a garbage collector kicking in on a real time embedded system. The garbage collector issue you mention has long since been fixed in all normal instances probably by the introduction of the better hybrid GCs.
It will be interesting to see what becomes the dominant modern OO, VM based language/platform on Linux. With the java licensing fiasco and.NET being owned by M$ I am seeing a suprisingly large number of command line and GUI apps being written in python. I'm sure the performance of python in CPU/performance terms is way worse than java!
In an absolute sense, sure, C/C++ will always be faster.
Clearly that is not true, as the article points out, repeated malloc calls can be slow compared to a VM allocating large blocks of memory. Deallocation can also be lighter weight.
Also a JIT can somtimes make better compilation optimizations as it has access to runtime information not available to a traditional compiler.
That is not to say C/C++ can't be faster, or that isn't faster most of the time - just that it's not guaranteed to be faster.
Most of the JVM memory issues (memory hogging issues and bloat) I blame on the fact that it isn't well integrated into the OS and tends not to share memory between "instances" issues that I guess won't occur with.NET. I know java 1.5 is suppose to address some of these performance issues on the desktop.
It amused me that to rebel against the Acronym ridden J2EE crap someone coined the phrase "POJO" - Plain Old Java Objects, just to make it sound more sexy.
The only time this is ok is when speed doesn't matter so much.
Which is of course *most* software development.
In a bank if you can complete a 7 month project only 2 months late rather than 5 months late and if maintenance and upgrades are easier you save millions over the lifecycle of a large enterprise application. The cost of the CPU's is negligable.
Most desktop systems are idling 99.5% of the time and slow bits are normally IO-related. Even in game development it's only client side code where you are speed critical and even then only in a tiny percentage of the code. This is all irrelevant anyway for games as directX dominates.
There are massive gains to be got from developing OO code for a modern virtual machine. In terms of security, less bugs and modern features like Garbage collection, etc, (I say modern but of course these basic features have been around for ages in smalltalk etc,).
Almost all apps will end up running on something like the JVM or.NET runtime. I'm sure there were people who said the speed of C was crap compared to assembler. How many assembler programmers do you know today?
I really meant that there was no opensource development environment for a GPL-compatible/linux-friendly opensource language. Since java isn't open enough the fact that eclipse is opensource is pretty much irrelevant to linux developers.
Swing may be slow and crappy, java is definately not. The compromise in speed that you make in a large Java application compared to a large C++ program is negligable for most application development, and of course development in a modern OO language is much easier. Plus the tools for java such as IntelliJ and Eclipse are still a year or two ahead of microsofts intellistudio and about 5 or 6 years ahead of open source development tools.
Java on desktop linux will die unless a good open implementation becomes popular like harmony/GCJ etc. Java is of course firmly entrenched in many banks and large development companies because its the only modern development platform suitable for large scale cost efficient development that isn't tied to Microsoft. It's also become increasingly popular to write large multiplayer online game backends in Java.
To make out that being a modern OO language is a disadvantage is laughable. It's a bit like saying "I'm still going to use my horse'n'cart because cars are just fad and soon we'll all be flying planes." Sure, the java platforms isn't suitable for people who haven't learnt modern development practices of for hacking togethor small or temporary scripts, but that's not it's core market.
I wouldn't declare Java dead yet, given the only viable alternatively currently is the.NET platform.
Another issue is that a lot of the functionality he wants to add is in the plugin system within reiser. Other kernel developers believe it should sit in a virtual layer (VFS) above the actual filesystem so that they could work with any file system.
Mainly I agree with the kernel developers although I have some sympathy with Hans Reiser as his argument is normally that reiserFS is so good why bother with the VFS layer stuff and it is pretty good technically compared to say ext3.
I suspect that ReiserFS is technically superior but may lose out if Hans Reiser doesn't compromise a bit. After all eventually other linux filesystems might catch up technically.
IBM does have software patents and releases Open source code under the IBM public license.
Infact, IBMs open source license the "IBM public license" would seem to me to offer a sensible level of protection against patent abuse.
Firstly it says if you release under this license and patent the same code you are granting royalty-free use of those patents. This might stop microsofts shennanigans of joining open standards groups, releasing software whilst secretly patenting it.
Secondly, to protect against unrelated patent claims against a contributor it says that the royalty free patent grant will be terminated if a contributor is sued for patent infrigement.
In effect this means that if I release a piece of code and patent it, then you use it under the royalty-free-patent-grant and sue me for some unrelated patent infrigement I can counterclaim against you as your right to use my patent is terminated. This seems similar to the GPL copyright protection - in that you can use it for free but if you break the "conditions of use" your right to use it is terminated. In the case of the GPL your right to use it is blocked by copyright law and in the case of the IBM license it is blocked by both copyright and patent law (Assuming you had patented it).
I'm not saying this is sensible, i'd rather that software patents were banned but it seemed a reasonable elegant solution given the current state of affairs but then IANAL...
Entering into Kyoto and carbon trading agreements would not result in the collapse of corporate america and mass unemployment.
This whole "I won't sign up to anything that results in the loss of a single american job" is just nonsense, the real reason Bush doesn't want to sign up is because of where he gets campaign funding from.
Kyoto is very weak and is only a starting point but atleast it shows Europe is willing to admit there is a problem and start tackling it.
Oil is a finite resource, prices will continue to rise it actually makes long term economic sense to start energy conservation, carbon trading and renewable schemes now. This is to avoid exactly the situation you are describing which is almost certain to happen later on if america continues to burn fossil fuels at it's current rate, regardless of the damage you are doing to the global enviroment.
someone thought he looked like someone they were watching Yes, although according to the leaked internal investigation the identification process was based on his "mongolian eyes" not on a photo check.
If that was the case I would suggest 7 shots to the head was a little harsh.
PS This is slashdot. I was under the understanding that lacking basic skills in english and grammar was a signup requirement.
The fundamental problem in my view is that people are installing (or have pre-installed) software (web browsers) that allows companies to track their every move without fully explaining to users that this is going to happen.
I think it's outrageous that IE and Firefox don't ask users explicitly the first time a company tries to set a cookie if they want companies to be able to track them. I don't think if users were forced to choose and understand cookie policys they would allow ANY 3rd party cookie tracking (regardless of P3P policys) and yet by default firefox and IE allow all 3rd party (P3P) cookie tracking on their default medium setting without asking the user!
As soon as the default setting allows 3rd parties to track one 3rd party advertiser sells data to marketeers, then ALL 3rd party ad servers have to do the same to compete.
If another program leaked as much information to companies without your knowledge as IE and Firefox on the default cookie setting the software would be deemed spyware (or worse as it leaks information to thousands of companies!).
The idea that laws should be introduced to force websites to say they are spying using cookieing is a stupid legal solution to the technical problem that users are installing and using software that leaks their data in way that the average user would consider a privacy violation - BY DEFAULT!
I would suggest that the web browser should pop up a one time warning dialog the first time it sees a 3rd party trying to set a cookie. Something like this: "a 3rd party company not 'slashdot.org' is trying to record information on your computer, do you want to allow any 3rd parties to record data about your internet usage?"
Most people would say NO, this would change the cookie acceptance policy on the users browser so that no 3rd party tracking would ever work.
Cookie wiping by anti-spyware companies is just another kludge work around for not forcing users to choose a cookie security policy they are comfortable with.
4) They visit pages that make use of DHTML effects which on firefox would suck all your CPU, cause your laptop to burn a hole in your leg and the menus to become unresponsive.
On IE the same DHTML normally takes 1-4% CPU usage. Fixing the efficiency of DHTML in firefox would be useful. Sometimes I think my computer has gone AWOL and it turns out to be a scrolling dhtml advert in a firefox tab.
Slashdot Mirror
But you seem to be ignoring the fact that writing CPU specific assembler is still being done by the compiler. Yes, I think writing software directly in C is going to be phased out, but unless the actual architecture of hardware changes I don't see any reason not to store machine code in between runs of the software. That seems to me like you're intentionally hamstringing the system.
.Net or Java ;)
Heh. I didn't say you shouldn't store machine code in between runs of the software.
All I am saying is move the compiler to the client machine (which is more trusted by users anyway) add a few safety & runtime features and distribute applications as bytecode or source rather than binary.
Like
Memory allocation leaks, direct memory addressing errors, buffer over-runs and a lack of a good enforced security sandbox for the application, lack of garbage collection.
I can't imagine you really think the recompilation of source code for N different platforms and the need to package separately for all those platforms too is actually a good thing in its-self?
There are many reasons why i'm sure VMs will win out, the performance penulty where there is one is small compared to the quite large gains in development speed and improved code quality in developing large scale apps.
Anyway... we could argue this one all night and I don't disagree that you can write such and such a bit of code more efficiently in C but I stand by my prediction that over the next few years, less and less code will be natively compiled. Compiling code to a native format will be slowly phased out in the same way that these days you don't often see people write CPU specific assembler.
A good JIT is the smarter compiler.
.NET. With the release of the next version of windows and Visual Studio most client side software will also run on a VM. Linux is bound to catch up eventually either through the Java, the .NET or another route (python?).
Regardless of the performance issues the future of software development is going to be running non-native code on a virtual machine as this has so many advtantages including portability/distribution, security and efficiency of developing large scale systems.
Most new enterprise server side software is now being developed in Java or
Another thing to note is that it was always possible to write more efficient assembler than C, but it was often easier to write more efficient C than assembler due to better code layout, easier management of libraries, code reuse and the manageability of developing larger apps.
A lot of people find the same is true when comparing C to Java - Garbage collection being a good example of this.
why bother kludging around with a language which was meant to be interpreted if you're going to compile it?
Given that we want the security, stability, portability and other benefits that a virtual machine provides and that the virtual machine runs non-native bytecode and that the JIT is nearly as fast as compiled code and faster in some circumstances - compiling java code to native is pointless from a performance perspective in most practical cases.
In fact GCJ compiled java is usually slower than running under a modern JIT. The reasons for compiling to native is probably more to do with the license restrictions on redistributing the Sun JVM. Due to the licensing restrictions most distros won't contain a full java implementation by default and therefore native comilation and the use of classlibrary may be the only way to conveniently redistribture your java on most linux distros.
You can get garbage collection for C/C++ and they have the same benefits/drawbacks as the ones in java, although the java ones are now quite advanced.
I was only pointing out that garbage collection can improve speed over explicit allocate/deallocate calls - therefore the fact that java has garbage collection isn't neccessarily a disadvantage in terms of performance.
it's not impossible of course and indeed you might want to do it if you were writing something like a urmm... garbage collector!
To be honest and I know this wasn't the original discussion I don't find the performance of the JIT that bad in terms of CPU. For web serving for example a cheapo dell can server serve well over 1.5k req/sec whilst doing some processing each request on a 1.5 JVM in server mode. This performance is good enough for server side processing. There are of course many advantages such as the excellent class library and jakarta projects.
.NET being owned by M$ I am seeing a suprisingly large number of command line and GUI apps being written in python. I'm sure the performance of python in CPU/performance terms is way worse than java!
On the client side java is all but dead anyway due to a combination of the AWT/Swing crapness, microsoft killing it and the memory bloat issues. The one thing that was never an issue client side was the speed of running bytecode under a good JIT. Maybe the apps seemed slow but that was always swing or more likely the fact that your machine was swapping.
Obviously you can't have a garbage collector kicking in on a real time embedded system. The garbage collector issue you mention has long since been fixed in all normal instances probably by the introduction of the better hybrid GCs.
It will be interesting to see what becomes the dominant modern OO, VM based language/platform on Linux. With the java licensing fiasco and
In an absolute sense, sure, C/C++ will always be faster.
.NET. I know java 1.5 is suppose to address some of these performance issues on the desktop.
Clearly that is not true, as the article points out, repeated malloc calls can be slow compared to a VM allocating large blocks of memory. Deallocation can also be lighter weight.
Also a JIT can somtimes make better compilation optimizations as it has access to runtime information not available to a traditional compiler.
That is not to say C/C++ can't be faster, or that isn't faster most of the time - just that it's not guaranteed to be faster.
Most of the JVM memory issues (memory hogging issues and bloat) I blame on the fact that it isn't well integrated into the OS and tends not to share memory between "instances" issues that I guess won't occur with
I had a server running twiki that got compromised twice.
I agree that it's best to ditch twiki, although SELinux is also good for damage limitation.
It amused me that to rebel against the Acronym ridden J2EE crap someone coined the phrase "POJO" - Plain Old Java Objects, just to make it sound more sexy.
I guess slashdot ad revenues must be down again.
The only time this is ok is when speed doesn't matter so much.
.NET runtime. I'm sure there were people who said the speed of C was crap compared to assembler. How many assembler programmers do you know today?
Which is of course *most* software development.
In a bank if you can complete a 7 month project only 2 months late rather than 5 months late and if maintenance and upgrades are easier you save millions over the lifecycle of a large enterprise application. The cost of the CPU's is negligable.
Most desktop systems are idling 99.5% of the time and slow bits are normally IO-related. Even in game development it's only client side code where you are speed critical and even then only in a tiny percentage of the code. This is all irrelevant anyway for games as directX dominates.
There are massive gains to be got from developing OO code for a modern virtual machine. In terms of security, less bugs and modern features like Garbage collection, etc, (I say modern but of course these basic features have been around for ages in smalltalk etc,).
Almost all apps will end up running on something like the JVM or
I really meant that there was no opensource development environment for a GPL-compatible/linux-friendly opensource language. Since java isn't open enough the fact that eclipse is opensource is pretty much irrelevant to linux developers.
At the moment anyway.
Swing may be slow and crappy, java is definately not. The compromise in speed that you make in a large Java application compared to a large C++ program is negligable for most application development, and of course development in a modern OO language is much easier. Plus the tools for java such as IntelliJ and Eclipse are still a year or two ahead of microsofts intellistudio and about 5 or 6 years ahead of open source development tools.
.NET platform.
Java on desktop linux will die unless a good open implementation becomes popular like harmony/GCJ etc. Java is of course firmly entrenched in many banks and large development companies because its the only modern development platform suitable for large scale cost efficient development that isn't tied to Microsoft. It's also become increasingly popular to write large multiplayer online game backends in Java.
To make out that being a modern OO language is a disadvantage is laughable. It's a bit like saying "I'm still going to use my horse'n'cart because cars are just fad and soon we'll all be flying planes." Sure, the java platforms isn't suitable for people who haven't learnt modern development practices of for hacking togethor small or temporary scripts, but that's not it's core market.
I wouldn't declare Java dead yet, given the only viable alternatively currently is the
Yes.
Another issue is that a lot of the functionality he wants to add is in the plugin system within reiser. Other kernel developers believe it should sit in a virtual layer (VFS) above the actual filesystem so that they could work with any file system.
Mainly I agree with the kernel developers although I have some sympathy with Hans Reiser as his argument is normally that reiserFS is so good why bother with the VFS layer stuff and it is pretty good technically compared to say ext3.
I suspect that ReiserFS is technically superior but may lose out if Hans Reiser doesn't compromise a bit. After all eventually other linux filesystems might catch up technically.
Yes. The single thread thing is really annoying and really makes you realise it's not a "normal" native windows/linux application.
For example, if you leave the betfair website open in a tab, the async updates of odds cause the whole of firefox to lockup.
It's particularly bad on slower connections and means leaving certain websites open can make firefox unbearable.
Quite.
What a naive idea. Imagine British soldiers fighting alongside the French.
We'd kill each other before we even saw the enemy.
IBM does have software patents and releases Open source code under the IBM public license.
Infact, IBMs open source license the "IBM public license" would seem to me to offer a sensible level of protection against patent abuse.
Firstly it says if you release under this license and patent the same code you are granting royalty-free use of those patents. This might stop microsofts shennanigans of joining open standards groups, releasing software whilst secretly patenting it.
Secondly, to protect against unrelated patent claims against a contributor it says that the royalty free patent grant will be terminated if a contributor is sued for patent infrigement.
In effect this means that if I release a piece of code and patent it, then you use it under the royalty-free-patent-grant and sue me for some unrelated patent infrigement I can counterclaim against you as your right to use my patent is terminated. This seems similar to the GPL copyright protection - in that you can use it for free but if you break the "conditions of use" your right to use it is terminated. In the case of the GPL your right to use it is blocked by copyright law and in the case of the IBM license it is blocked by both copyright and patent law (Assuming you had patented it).
I'm not saying this is sensible, i'd rather that software patents were banned but it seemed a reasonable elegant solution given the current state of affairs but then IANAL...
Here is the real list of reasons that Bush didn't enter into Kyoto.
. stm
Enron $1.8m
Exxon $1.2m
Koch Industries $970,000
Southern $900,000
BP Amoco $800,000
El Paso Energy $787,000
Chevron Oil Corp $780,000
Reliant Energy $642,000
Texas Utilities $635,000
source: http://news.bbc.co.uk/1/hi/world/americas/1336960
Entering into Kyoto and carbon trading agreements would not result in the collapse of corporate america and mass unemployment.
This whole "I won't sign up to anything that results in the loss of a single american job" is just nonsense, the real reason Bush doesn't want to sign up is because of where he gets campaign funding from.
Kyoto is very weak and is only a starting point but atleast it shows Europe is willing to admit there is a problem and start tackling it.
Oil is a finite resource, prices will continue to rise it actually makes long term economic sense to start energy conservation, carbon trading and renewable schemes now. This is to avoid exactly the situation you are describing which is almost certain to happen later on if america continues to burn fossil fuels at it's current rate, regardless of the damage you are doing to the global enviroment.
someone thought he looked like someone they were watching
Yes, although according to the leaked internal investigation the identification process was based on his "mongolian eyes" not on a photo check.
If that was the case I would suggest 7 shots to the head was a little harsh.
PS
This is slashdot. I was under the understanding that lacking basic skills in english and grammar was a signup requirement.
Sure. Although this guy wasn't involved in the 7th of July bombings he did go into the same building as a terrorist AND he had "mongolian eyes".
Your right, that is SO much worse, now i can see why he was shot 7 times in the head.
Dark people should be shot 5 times in the head.
Don't laugh about it.
Here in the UK we recently shot someone 7 times in the head for having foreign looking eyes.
The fundamental problem in my view is that people are installing (or have pre-installed) software (web browsers) that allows companies to track their every move without fully explaining to users that this is going to happen.
I think it's outrageous that IE and Firefox don't ask users explicitly the first time a company tries to set a cookie if they want companies to be able to track them. I don't think if users were forced to choose and understand cookie policys they would allow ANY 3rd party cookie tracking (regardless of P3P policys) and yet by default firefox and IE allow all 3rd party (P3P) cookie tracking on their default medium setting without asking the user!
As soon as the default setting allows 3rd parties to track one 3rd party advertiser sells data to marketeers, then ALL 3rd party ad servers have to do the same to compete.
If another program leaked as much information to companies without your knowledge as IE and Firefox on the default cookie setting the software would be deemed spyware (or worse as it leaks information to thousands of companies!).
The idea that laws should be introduced to force websites to say they are spying using cookieing is a stupid legal solution to the technical problem that users are installing and using software that leaks their data in way that the average user would consider a privacy violation - BY DEFAULT!
I would suggest that the web browser should pop up a one time warning dialog the first time it sees a 3rd party trying to set a cookie. Something like this: "a 3rd party company not 'slashdot.org' is trying to record information on your computer, do you want to allow any 3rd parties to record data about your internet usage?"
Most people would say NO, this would change the cookie acceptance policy on the users browser so that no 3rd party tracking would ever work.
Cookie wiping by anti-spyware companies is just another kludge work around for not forcing users to choose a cookie security policy they are comfortable with.
or...
4) They visit pages that make use of DHTML effects which on firefox would suck all your CPU, cause your laptop to burn a hole in your leg and the menus to become unresponsive.
On IE the same DHTML normally takes 1-4% CPU usage. Fixing the efficiency of DHTML in firefox would be useful. Sometimes I think my computer has gone AWOL and it turns out to be a scrolling dhtml advert in a firefox tab.
and he also had a hand in the development of VBScript.
Perhaps thats why he now says companies should hire competant programmers.