... except that the application does have to worry about drawing itself.
Unless the app wants to look like something from 1987, it has to render all its own controls, icons, heck it even has to open the true-type font file, load the true-type interpreter, rasterise all its own font strings and send them as bitmaps to the X-server over a socket. There's so much stuff on the client-side, it's completely braindead. Just think how many times your computer loads bitstream-vera-sans.ttf. How many times should it load it? How many times does libgnome load its gnome icon cache?
Someone needs to make an XGTK extension that puts GTK object rendering in a module in the server. Then the client only needs to worry about making remote GTK objects. For example, gnome-calculator could make a display object, a dozen button objects, and register for clicks. Then all the gnome-calculator *process* needs to worry about is doing sums. It should be helloworld.c in size, not 128 KiB.
The good news is this could be done relatively easily within X's framework. The bad news it, no-one seems to care about fixing it.
This isn't just Ubuntu, I just fired up my 5-year-old laptop with Debian from 2 years ago installed on it (haven't used it in 2 years) and smartctl gives me 184,305 load cycles in 2179 power on hours. The hard drive clicks every 30 seconds or so when idle (I noticed it before but assumed it was something messing around with the disk). hdparm -B 254/dev/hda stops it from going up any more.
It can, in theory, be faster. Sometimes you discover data that turns out to be constant in the end, but you don't know this until your program is running. A JITter can use this additional information to compile to machine code that is a lot simpler and therefore faster. If you then execute this piece of code lots of times, you can earn back the time spent compiling and then start to profit from it. I remember some work being done into some research which did this in C: it generated some C based on a template, fork()-exec()ed gcc to compile it to a shared library, dlopen()ed the shared library and then ran the code. Of course, you had to do this explicitly, but I think since the chances of actually having an algorithm that benefits from this is pretty rare, that's not going to be a problem.
That being said, Java has no way of hinting to the compiler "this is going to be constant for a long while now", or "I'm going to run this loop a couple of million times in a bit, you might want to JIT it real good". Without those, the compiler doesn't really have a hope.
Also, it's not a case of interpreted languages not being cool. Perl, Python and a myriad of other languages are all interpreted (or run as some kind of byte-code), and no-one complains. Then again, I've seen Java out-paced by many of these languages (most of which compile the program to byte-code at start-up faster than Java loads), which suggests to me that Java is just a poor interpreted language. If you've seen how JVMs work internally, I think you'll agree with me.
Presumably because the money that eventually pays for healthcare and roads and other niceties like courts of justice comes out of that big government void.
I don't buy the idea of having to take a significant performance hit now and for the forseeable future for the sake of hypothetically being able to run my program faster in 15 years time on a hypothetical machine that doesn't exist yet.
Besides, I have the source to my program; I can recompile it for the new architecture in 15 years' time.
What's worse about swapping a large* Java program out and back in is when the garbage collector next runs, usually very soon after it gains focus (i.e. when you want to use the program again), it touches near enough every damn page the program is using, checking for objects to cull. This causes the OS to swap the *whole* program back into memory and consequently a whole load of thrashing.
Given that this was an exercise, I'm somewhat tempted to ask whether you aren't counting the JVM startup time on top of a very short problem instance.
C: 30 seconds, Java: 8 hours. No kidding. These were running on the same laboratory machines, the Java programs using the latest Sun JVM at the time. The exercise involved calculating some statistics from a simulation run for one virtual year. Most of the people doing the Java version had to leave it running overnight. Besides, JVM startup time is a performance issue, you can't just dismiss it out of hand.
That, or whether the exercise involved lots of dynamic creation of objects (in which case your program was by definition not doing the same thing as the Java implementations). The exercise you mention sort of sounds like that.
In the Java version, each event was an object. In C each event was a malloc'd struct. These are analagous in that they are the correct way to solve the problem in that particular language. The fact that object creation and destruction is a lengthy process is an important reason why Java is so slow. It's an object-oriented language, its raison d'etre is to create and destroy objects. If it can't do that fast enough then what's the point in it being able to do anything else with speed?
I know at this point the Java apologists will say "just use a pool of pre-created Objects, that'll speed it up". This misses the point in two ways: (1) Java was supposed to obviate the need to perform manual memory handling. Now I have to not only remember to de-allocate my objects when I am done with them, I have to write a Pool class within which to store my not-currently-in-use objects?! (2) I can do that in C, too, if I really want to, and it'll make the C version faster again.
I am well aware of the forte of Haskell and its different interpreter implementations. To the degree that I wouldn't be surprised if the Haskell implementation did better than your C implementation.
They didn't. I was told they took around 10 minutes to run, but I never actually saw them working. When I produced results from a simulation that ran for 1000 years (an overnight run for my C program), the professor was amazed. But yes, in my experience interpreted Haskell is very fast, which makes Java look even more foolish.
I've done this four times now; written a C equivalent of a Java program and found it at least one, often several orders of magnitude faster. I've yet once to be shown a Java program that is significantly faster than its C equivalent.
This does not mean that Java should not be used as a programming language.
The language features (especially those in version 1.5) are useful for working in a collaborative environment with mediocre programmers, and where the raw performance of the application is not critical (such as a GUI front-end to a server application). Just don't bullshit about it being faster than C, or even "fast" and expect me to believe it.
I'm willing to be proven wrong, but until someone can actually show me proof that it can be done, I'm not going to believe the hype, hand-waving and hot air.
It was a discrete event simulation exercise for a simulation and modelling course at university, based on a very simple algorithm:
Take an event off the head of a queue.
Process that event depending on its type, parameters and the current state of the simulated system according to a specification we were given as part of the exercise. This modifies the state of the system and generates new events that will happen in the future.
Insert the resulting future events into the queue.
There were dozens of Java implementations by various students of differing capabilities, and one of them written by the professor teaching the subject as a reference implementation. My C implementation beat all of them and then some. In fact, the Haskell implementations from the previous year did too (and they were run interpreted, not ghc-compiled).
Of course SWT is faster than Swing. SWT interfaces to the native toolkit, which is, of course written in C or C++. In Java, the only fast method is a native method.
I've still yet to be shown an example of a Java program that runs faster than an equivalent C or C++ program, whereas I've had a wealth of experience with things being around the other way (one extreme example was Java: 8 hours, C: 30 seconds).
The Hotspot argument is hot air, since the time you spend re-compiling the whole program (JIT of course, which is closer in actual behaviour to JustTooLate) will in most cases outweigh what tiny improvements you can get in the part of the program that matters for performance. Remember that 90% of CPU time is spent in 10% of the code.
The Java version was well written. The problem was it made quite a bit of use of objects (each Event was an object). Unfortunately Java object creation has such an overhead the simulation was slow (and the flood of stale objects hanging around between gc runs made it a memory hog, too).
And if anyone says "well don't use objects, use a static mechanism or allocate manually instead" has missed the point: if you have to code Java like you code C, then you might as well be using C.
2) Java on a modern hotspot JVM can outperform the equivalent C++ code for stuff that isn't IO limited (ie number crunching stuff)
Bullshit.
The best case scenario for a hotspot JVM is that it produces the same code as the C++ compiler. Since it has to recompile the bytecode and run the same code as the C++ version it's mathematically impossible for it to be faster. You're just buying into the propaganda where they compare fast JVMs with crappy C++ implementation compiled with optimization switched off.
For proof: in a CPU bound simulation written for a course at University, written in different languages, Java took over an hour to run the same simulation that in C took less than 40 seconds. Heck, even interpreted Haskell beat the pants off the Java versions.
The license only requests proper attribution in software and/or documentation like other third parties are getting.
The license doesn't request attribution, it requires it. That is the problem. Can you see what would happen if every time I started my computer, it printed out the names of all the people and organisations that were involved in making it? It could take days to boot:)
Slashdot Mirror
I came back to take a look after all the reddit stuff. Genuinely surprised to see people are still here.
A pace is traditionally two steps. http://en.wikipedia.org/wiki/Pace_(length)
... except that the application does have to worry about drawing itself.
Unless the app wants to look like something from 1987, it has to render all its own controls, icons, heck it even has to open the true-type font file, load the true-type interpreter, rasterise all its own font strings and send them as bitmaps to the X-server over a socket. There's so much stuff on the client-side, it's completely braindead. Just think how many times your computer loads bitstream-vera-sans.ttf. How many times should it load it? How many times does libgnome load its gnome icon cache?
Someone needs to make an XGTK extension that puts GTK object rendering in a module in the server. Then the client only needs to worry about making remote GTK objects. For example, gnome-calculator could make a display object, a dozen button objects, and register for clicks. Then all the gnome-calculator *process* needs to worry about is doing sums. It should be helloworld.c in size, not 128 KiB.
The good news is this could be done relatively easily within X's framework. The bad news it, no-one seems to care about fixing it.
How about: vi is better than emacs?
People who argue about whether science is a meritocracy or a democracy are completely missing the point.
>Logarithm tells us that 2+2 != 4, but rather 3.99 [ad infinitum] - how's that for a bit of confusion.
But,
3.999... = 3 + 0.999... = 3 + 0.333... + 0.333... + 0.333... = 3 + 1/3 + 1/3 + 1/3 = 3 + 3/3 = 3 + 1 = 4.
So logarithms are right. There are more than four ways to write two squared.
We could equate it with boarding a ship at sea, taking its cargo, murdering its crew, and leaving the ship to burn while we sail away.
Oh.
This isn't just Ubuntu, I just fired up my 5-year-old laptop with Debian from 2 years ago installed on it (haven't used it in 2 years) and smartctl gives me 184,305 load cycles in 2179 power on hours. The hard drive clicks every 30 seconds or so when idle (I noticed it before but assumed it was something messing around with the disk). hdparm -B 254 /dev/hda stops it from going up any more.
2x4 refers to the unplaned size. Once planed it becomes a bit smaller.
And two-by-four in metric is five-by-ten.
"'The Web is broken and it's all your fault' says Rasmus Lerdorf, the creator of PHP."
Translation:
"Hello, Kettle? Yes, this is Pot. What colour are you..?"
Really, if Lerdorf wants to know who broke the web, he just needs to look in a mirror.
Sometimes you want to retype what^H^H^H^H^H^H^H^H^H
You don't backspace over just err^H^H^H^H^H^H^H^H^H
The time I spend correcting typos is dwarfed by the time I spend thinking about what I want to type.
I don't see anything morally wrong with moving some polygons around on a computer screen.
Even then I wouldn't make public requests. I'd just give him bad feedback.
Surely requests for money back would be done through private email, not public eBay comments.
It can, in theory, be faster. Sometimes you discover data that turns out to be constant in the end, but you don't know this until your program is running. A JITter can use this additional information to compile to machine code that is a lot simpler and therefore faster. If you then execute this piece of code lots of times, you can earn back the time spent compiling and then start to profit from it. I remember some work being done into some research which did this in C: it generated some C based on a template, fork()-exec()ed gcc to compile it to a shared library, dlopen()ed the shared library and then ran the code. Of course, you had to do this explicitly, but I think since the chances of actually having an algorithm that benefits from this is pretty rare, that's not going to be a problem.
That being said, Java has no way of hinting to the compiler "this is going to be constant for a long while now", or "I'm going to run this loop a couple of million times in a bit, you might want to JIT it real good". Without those, the compiler doesn't really have a hope.
Also, it's not a case of interpreted languages not being cool. Perl, Python and a myriad of other languages are all interpreted (or run as some kind of byte-code), and no-one complains. Then again, I've seen Java out-paced by many of these languages (most of which compile the program to byte-code at start-up faster than Java loads), which suggests to me that Java is just a poor interpreted language. If you've seen how JVMs work internally, I think you'll agree with me.
Port forward to a proxy and set that as your web proxy in your browser.
Presumably because the money that eventually pays for healthcare and roads and other niceties like courts of justice comes out of that big government void.
I don't buy the idea of having to take a significant performance hit now and for the forseeable future for the sake of hypothetically being able to run my program faster in 15 years time on a hypothetical machine that doesn't exist yet.
Besides, I have the source to my program; I can recompile it for the new architecture in 15 years' time.
What's worse about swapping a large* Java program out and back in is when the garbage collector next runs, usually very soon after it gains focus (i.e. when you want to use the program again), it touches near enough every damn page the program is using, checking for objects to cull. This causes the OS to swap the *whole* program back into memory and consequently a whole load of thrashing.
;-) ]
[* is there any other kind?
Given that this was an exercise, I'm somewhat tempted to ask whether you aren't counting the JVM startup time on top of a very short problem instance.
C: 30 seconds, Java: 8 hours. No kidding. These were running on the same laboratory machines, the Java programs using the latest Sun JVM at the time. The exercise involved calculating some statistics from a simulation run for one virtual year. Most of the people doing the Java version had to leave it running overnight. Besides, JVM startup time is a performance issue, you can't just dismiss it out of hand.
That, or whether the exercise involved lots of dynamic creation of objects (in which case your program was by definition not doing the same thing as the Java implementations). The exercise you mention sort of sounds like that.
In the Java version, each event was an object. In C each event was a malloc'd struct. These are analagous in that they are the correct way to solve the problem in that particular language. The fact that object creation and destruction is a lengthy process is an important reason why Java is so slow. It's an object-oriented language, its raison d'etre is to create and destroy objects. If it can't do that fast enough then what's the point in it being able to do anything else with speed?
I know at this point the Java apologists will say "just use a pool of pre-created Objects, that'll speed it up". This misses the point in two ways: (1) Java was supposed to obviate the need to perform manual memory handling. Now I have to not only remember to de-allocate my objects when I am done with them, I have to write a Pool class within which to store my not-currently-in-use objects?! (2) I can do that in C, too, if I really want to, and it'll make the C version faster again.
I am well aware of the forte of Haskell and its different interpreter implementations. To the degree that I wouldn't be surprised if the Haskell implementation did better than your C implementation.
They didn't. I was told they took around 10 minutes to run, but I never actually saw them working. When I produced results from a simulation that ran for 1000 years (an overnight run for my C program), the professor was amazed. But yes, in my experience interpreted Haskell is very fast, which makes Java look even more foolish.
I've done this four times now; written a C equivalent of a Java program and found it at least one, often several orders of magnitude faster. I've yet once to be shown a Java program that is significantly faster than its C equivalent.
This does not mean that Java should not be used as a programming language. The language features (especially those in version 1.5) are useful for working in a collaborative environment with mediocre programmers, and where the raw performance of the application is not critical (such as a GUI front-end to a server application). Just don't bullshit about it being faster than C, or even "fast" and expect me to believe it.
I'm willing to be proven wrong, but until someone can actually show me proof that it can be done, I'm not going to believe the hype, hand-waving and hot air.
Same algorithm, same data structures.
It was a discrete event simulation exercise for a simulation and modelling course at university, based on a very simple algorithm:
There were dozens of Java implementations by various students of differing capabilities, and one of them written by the professor teaching the subject as a reference implementation. My C implementation beat all of them and then some. In fact, the Haskell implementations from the previous year did too (and they were run interpreted, not ghc-compiled).
Of course SWT is faster than Swing. SWT interfaces to the native toolkit, which is, of course written in C or C++. In Java, the only fast method is a native method.
I've still yet to be shown an example of a Java program that runs faster than an equivalent C or C++ program, whereas I've had a wealth of experience with things being around the other way (one extreme example was Java: 8 hours, C: 30 seconds).
The Hotspot argument is hot air, since the time you spend re-compiling the whole program (JIT of course, which is closer in actual behaviour to JustTooLate) will in most cases outweigh what tiny improvements you can get in the part of the program that matters for performance. Remember that 90% of CPU time is spent in 10% of the code.
The Java version was well written. The problem was it made quite a bit of use of objects (each Event was an object). Unfortunately Java object creation has such an overhead the simulation was slow (and the flood of stale objects hanging around between gc runs made it a memory hog, too).
And if anyone says "well don't use objects, use a static mechanism or allocate manually instead" has missed the point: if you have to code Java like you code C, then you might as well be using C.
2) Java on a modern hotspot JVM can outperform the equivalent C++ code for stuff that isn't IO limited (ie number crunching stuff)
Bullshit.
The best case scenario for a hotspot JVM is that it produces the same code as the C++ compiler. Since it has to recompile the bytecode and run the same code as the C++ version it's mathematically impossible for it to be faster. You're just buying into the propaganda where they compare fast JVMs with crappy C++ implementation compiled with optimization switched off.
For proof: in a CPU bound simulation written for a course at University, written in different languages, Java took over an hour to run the same simulation that in C took less than 40 seconds. Heck, even interpreted Haskell beat the pants off the Java versions.
The license only requests proper attribution in software and/or documentation like other third parties are getting.
:)
The license doesn't request attribution, it requires it. That is the problem. Can you see what would happen if every time I started my computer, it printed out the names of all the people and organisations that were involved in making it? It could take days to boot
It's just vanity.