Compiler writers in particular know this, which is why even GCC uses GC. Yes, it's home-built application-specific carefully-applied-and-tuned GC, but it's GC nonetheless.
No it isn't, it's just the Boehm GC with half a dozen small patches applied.
Incorrect. GCC does not use Boehm GC. The boehm-gc you see in the GCC source tree is used by libjava, which is a java runtime library and unrelated to the compiler itself.
There's approximately 20,500 bus stops in Greater London - I have a database (NaPTAN) of them. I'd estimate there's as least 50 lamp posts for every bus stop. So, thats over 1,000,000 WiFI access points to be rolled out by 2012! Wow!
BTW, in day-to-day operations, German's ICE and Japan's Sinkansen often go beyond 300 km/h. Frace's TGV never does, and Canada's Bombaardier doesn't even work well above 200 km/h.
France's LGV Est (this is the line that the 574km/h world speed record was set) has a standard operating speed of 320 km/h. There is no line in Germany capable of speeds over 300km/h (but German ICE trains do operate on LGV Est at 320km/h).
Also, Bombardier isn't the name of a train network in the sense of ICE, TGV, or Shinkansen. Bombardier is a train manufacturing company like Alstom, Siemens, or Hitachi. Canada's passenger rail network is known as VIA and for the most part it isn't regarded as high-speed, though they do use tilting train technology on the densely populated "corridor" between Windsor, ON and Quebec City, QC. This corridor line does boast higher average speeds than on any current passenger rail line in the US.
Its downright uncomfortable/impossible to stand without holding onto something, hence the hand straps to grab. A super fast train is probably much worse. I find it highly unlikely it would take more than 60 secs to go 0-300 or 300-0. That's actually pretty slow acceleration, compared to a car.
I'm thinking one / one / one, total three mins, times 20 is 60 mins station time, leaving two hours, cruise around 300 MPH, it does all work out. Of course there is always marketing BS, such as not counting station time...
You may be confusing passenger trains with freight trains. A couple million pounds of coal does indeed take awhile to accelerate and decelerate.
And you may be confusing subway/metro/commuter trains systems with long distance passenger trains. The ride quality and acceleration of a long distance train is usually much smoother. In my experience Eurostar, Shinkansen, TGV type trains often accelerate so smoothly that you can barely feel the train moving at all if you aren't looking out the window!
1. Performance? My experimentation 6 months ago with compute/object-intensive code showed a fully-optimized GCJ only getting 30% the speed of the latest Sun JVM.
GCJ isn't perfect (yet), but for the most part it produces pretty good code that matches or exceeds JRE performance on most large applications. If you are seeing such a large performance discrepency then most likely there is some bottleneck in the libgcj runtime/class libraries that your code is tripping over. We are fixing such problems regularly, but can't do so if we don't know about them. If your code runs poorly on GCJ then *please* send a message to java@gcc.gnu.org describing what you are doing or, better, with a test case/sample code. We'll do our best to help.
2. Popular applications? Can Jakarta Tomcat with JSP, etc., a common open source Java-based web server be run on it? If not, there is a clear list of what it is missing.
Tomcat runs great on GCJ. The issue today is not so much what GCJ can run, but making it easier for folks to build & run large scale applications like Tomcat and J2EE servers. The "native compiler" compilation and execution paradigm is substantially different from that of the traditional JVM, and this means it can be a lot of work to convert everything from an ant/javac build system to a native one. Solutions to this issue are a big focus for the GCJ development community right now.
3. Web applications sandbox? How about loading untrusted applications over the internet and running them in a security sandbox?
Infrastructure for the java security model is largely in place in libgcj already. There are a few bits remaining to be sorted out, but we should have a completely functional java.security AccessController/SecurityManager within the next few weeks. This will allow you to securely run a) untrusted bytecode, and b) untrusted bytecode compiled to native in a trusted compliation environment.
4. Is GTK or QT really ready to be the free cross-platform Java standard for UI?
Absolutely. Just look at java-gnome. The day will soon come when many of your native linux desktop applications are written in Java, and you won't even notice the difference.
Is there licensing preventing bundling of IBM's Eclipse UI toolkit with GCJ?
Unfortunately, it appears so. IBM's CPL, although a certified free software license, has been decreed incompatible with the GPL. This doesn't stop you writing SWT applications with GCJ, of course - many do. But the SWT itself will need to be distributed with your application or at least in a separate shared library.
Is relicensing under GPL possible?
Better ask IBM. I certainly hope a solution can be found to this problem.
It runs very nicely! The native-compiled eclipse is noticably more snappy and responsive than it is on the JRE 1.4.2 on my (XP 1800) machine. It also seems quite stable - I stress-tested it for about half an hour last night and couldn't produce any bugs or crashes.
I could show you plenty of examples of benchmarks that run significantly faster with GCJ than on the IBM JDK. Its true that there are still some occasions where GCJ will run slower - due to bottlenecks in the runtime or missed optimizations in the compiler. But if you have a simple application that runs significantly slower with GCJ, please write to java@gcc.gnu.org and tell us about it. We can't fix performance problems we don't know about.
However, attention must be drawn to the plight of the poor, unfortunate GCC hackers, who are still having to put up with an inferior bug tracking system, despite a
flurry
of
activity
earlier in the year, it seems that little progress has been made on implementation. Lets all hope that GCC hackers don't have to continue to suffer the pain of crappy bug tracking for too much longer.
I'm still regularly using the original USRobotics Pilot 1000 that I bought in 1996!
It runs PalmOS 3.3, and has an upgrade card giving it 2MB RAM (up from 128k) and an infrared port.
Aside from most of the paint wearing off the buttons, and having to recalibrate the digitizer 2-3 times a week, its still works as well as the day I bought it - and even runs most current PalmOS apps!
Maybe they don't make them as well as they used to?
Altivec support has been in the Linux kernel for some time, and altivec assembler code has been supported in binutils for a while also.
GCC 3.1 has support for altivec extensions in C/C++ code, however the syntax is a little different from Motorola's altivec extensions which are used in MacOS. Apple are apparantly going to support both the old and new altivec syntax in their GCC 3.1 based compiler. This means that altivec code written with the new syntax should work unmodified on both Linux and Dawrin/MacOS X.
GCJ's I/O performance is pretty good in my experience. If you have some code that runs significantly slower with GCJ vs JVM, the least you could do is write to java@gcc.gnu.org and tell us about it. We can't fix performance problems that we don't know about.
GCJ is slower than IBM's JDK. THis is because IBM's JDK is fucking fast. It depends on your application. gcj is faster for some code, but the IBM JDK is still faster for others (but gcj is improving quickly). There is allways less startup overhead with gcj because It is true that some optimizations can only be made at runtime by a dynamic compiler, however others (due to high computational cost) can only be reasonably be done in a traditional, ahead-of-time compiler. The solution to this and other problems with ahead-of-time java compilers (like TowerJ and gcj) lies in providing a mixed-mode environment, where application code is dynamically loaded and compiled against pre-compiled libraries. If the standard java libraries are precompiled, you avoid a large amount of application startup overhead. But with application code running on a JIT, the advantages of dynamic compilation and the platform-independent bytecode format are maintained.
Slashdot Mirror
\ \
___> \
(__O) \
(____@) \
(____@) \
(__o)_ \
\ \
Verizon likes this!
\ \
___> \
(__O) \
(____@) \
(____@) \
(__o)_ \
\ \
Facebook likes this!
Compiler writers in particular know this, which is why even GCC uses GC. Yes, it's home-built application-specific carefully-applied-and-tuned GC, but it's GC nonetheless.
No it isn't, it's just the Boehm GC with half a dozen small patches applied.
Incorrect. GCC does not use Boehm GC. The boehm-gc you see in the GCC source tree is used by libjava, which is a java runtime library and unrelated to the compiler itself.
how many lamp-posts there are in London?
There's approximately 20,500 bus stops in Greater London - I have a database (NaPTAN) of them. I'd estimate there's as least 50 lamp posts for every bus stop. So, thats over 1,000,000 WiFI access points to be rolled out by 2012! Wow!
BTW, in day-to-day operations, German's ICE and Japan's Sinkansen often go beyond 300 km/h. Frace's TGV never does, and Canada's Bombaardier doesn't even work well above 200 km/h.
France's LGV Est (this is the line that the 574km/h world speed record was set) has a standard operating speed of 320 km/h. There is no line in Germany capable of speeds over 300km/h (but German ICE trains do operate on LGV Est at 320km/h).
Also, Bombardier isn't the name of a train network in the sense of ICE, TGV, or Shinkansen. Bombardier is a train manufacturing company like Alstom, Siemens, or Hitachi. Canada's passenger rail network is known as VIA and for the most part it isn't regarded as high-speed, though they do use tilting train technology on the densely populated "corridor" between Windsor, ON and Quebec City, QC. This corridor line does boast higher average speeds than on any current passenger rail line in the US.
Its downright uncomfortable/impossible to stand without holding onto something, hence the hand straps to grab. A super fast train is probably much worse. I find it highly unlikely it would take more than 60 secs to go 0-300 or 300-0. That's actually pretty slow acceleration, compared to a car.
I'm thinking one / one / one, total three mins, times 20 is 60 mins station time, leaving two hours, cruise around 300 MPH, it does all work out. Of course there is always marketing BS, such as not counting station time...
You may be confusing passenger trains with freight trains. A couple million pounds of coal does indeed take awhile to accelerate and decelerate.
And you may be confusing subway/metro/commuter trains systems with long distance passenger trains. The ride quality and acceleration of a long distance train is usually much smoother. In my experience Eurostar, Shinkansen, TGV type trains often accelerate so smoothly that you can barely feel the train moving at all if you aren't looking out the window!
1. Performance? My experimentation 6 months ago with compute/object-intensive code showed a fully-optimized GCJ only getting 30% the speed of the latest Sun JVM.
GCJ isn't perfect (yet), but for the most part it produces pretty good code that matches or exceeds JRE performance on most large applications. If you are seeing such a large performance discrepency then most likely there is some bottleneck in the libgcj runtime/class libraries that your code is tripping over. We are fixing such problems regularly, but can't do so if we don't know about them. If your code runs poorly on GCJ then *please* send a message to java@gcc.gnu.org describing what you are doing or, better, with a test case/sample code. We'll do our best to help.
2. Popular applications? Can Jakarta Tomcat with JSP, etc., a common open source Java-based web server be run on it? If not, there is a clear list of what it is missing.
Tomcat runs great on GCJ. The issue today is not so much what GCJ can run, but making it easier for folks to build & run large scale applications like Tomcat and J2EE servers. The "native compiler" compilation and execution paradigm is substantially different from that of the traditional JVM, and this means it can be a lot of work to convert everything from an ant/javac build system to a native one. Solutions to this issue are a big focus for the GCJ development community right now.
3. Web applications sandbox? How about loading untrusted applications over the internet and running them in a security sandbox?
Infrastructure for the java security model is largely in place in libgcj already. There are a few bits remaining to be sorted out, but we should have a completely functional java.security AccessController/SecurityManager within the next few weeks. This will allow you to securely run a) untrusted bytecode, and b) untrusted bytecode compiled to native in a trusted compliation environment.
4. Is GTK or QT really ready to be the free cross-platform Java standard for UI?
Absolutely. Just look at java-gnome. The day will soon come when many of your native linux desktop applications are written in Java, and you won't even notice the difference.
Is there licensing preventing bundling of IBM's Eclipse UI toolkit with GCJ?
Unfortunately, it appears so. IBM's CPL, although a certified free software license, has been decreed incompatible with the GPL. This doesn't stop you writing SWT applications with GCJ, of course - many do. But the SWT itself will need to be distributed with your application or at least in a separate shared library.
Is relicensing under GPL possible?
Better ask IBM. I certainly hope a solution can be found to this problem.
Try something like -O2 -ffast-math for your GCJ compile - this should improve the math scores significantly.
It runs very nicely! The native-compiled eclipse is noticably more snappy and responsive than it is on the JRE 1.4.2 on my (XP 1800) machine. It also seems quite stable - I stress-tested it for about half an hour last night and couldn't produce any bugs or crashes.
I could show you plenty of examples of benchmarks that run significantly faster with GCJ than on the IBM JDK. Its true that there are still some occasions where GCJ will run slower - due to bottlenecks in the runtime or missed optimizations in the compiler. But if you have a simple application that runs significantly slower with GCJ, please write to java@gcc.gnu.org and tell us about it. We can't fix performance problems we don't know about.
Its great that the kernel is getting a bugzilla.
However, attention must be drawn to the plight of the poor, unfortunate GCC hackers, who are still having to put up with an inferior bug tracking system, despite a flurry of activity earlier in the year, it seems that little progress has been made on implementation. Lets all hope that GCC hackers don't have to continue to suffer the pain of crappy bug tracking for too much longer.
My USR Pilot 1000 (1996) says "Made in Singapore".
I'm still regularly using the original USRobotics Pilot 1000 that I bought in 1996!
It runs PalmOS 3.3, and has an upgrade card giving it 2MB RAM (up from 128k) and an infrared port.
Aside from most of the paint wearing off the buttons, and having to recalibrate the digitizer 2-3 times a week, its still works as well as the day I bought it - and even runs most current PalmOS apps!
Maybe they don't make them as well as they used to?
Altivec support has been in the Linux kernel for some time, and altivec assembler code has been supported in binutils for a while also.
GCC 3.1 has support for altivec extensions in C/C++ code, however the syntax is a little different from Motorola's altivec extensions which are used in MacOS. Apple are apparantly going to support both the old and new altivec syntax in their GCC 3.1 based compiler. This means that altivec code written with the new syntax should work unmodified on both Linux and Dawrin/MacOS X.
Mozilla is a bit slow on OS X. But, Mozilla on Linux on my G4 Powerbook is much faster than IE on OS X on the same Powerbook.
Your C++ version is not comparable. A "long" in Java is 64 bits. A "long" in C++ is 32 bits. The Java code is doing far more work.
Change the Java code to use "int" or the C++ to use "long long" for a fairer comparison.
GCJ's I/O performance is pretty good in my experience. If you have some code that runs significantly slower with GCJ vs JVM, the least you could do is write to java@gcc.gnu.org and tell us about it. We can't fix performance problems that we don't know about.
Bryce.
GCJ is slower than IBM's JDK. THis is because IBM's JDK is fucking fast. It depends on your application. gcj is faster for some code, but the IBM JDK is still faster for others (but gcj is improving quickly). There is allways less startup overhead with gcj because It is true that some optimizations can only be made at runtime by a dynamic compiler, however others (due to high computational cost) can only be reasonably be done in a traditional, ahead-of-time compiler. The solution to this and other problems with ahead-of-time java compilers (like TowerJ and gcj) lies in providing a mixed-mode environment, where application code is dynamically loaded and compiled against pre-compiled libraries. If the standard java libraries are precompiled, you avoid a large amount of application startup overhead. But with application code running on a JIT, the advantages of dynamic compilation and the platform-independent bytecode format are maintained.
Check this URL for gcj (the gcc java compiler) and libgcj : http://sourceware.cygnus.com/java/