Bravo for the effort... but, methinks they could do this more cheaply (although, not 64-bit) with stock PC hardware.
Pundits say the machine is actually cheap. For a 64-bit machine with all the I/O and bus trimmings it is priced nicely. The only thing I'm amazed at is that VT didn't wait for headless cluster-only Xserves. Rack mounting the G5 case looks like it would be a hassle and a shame.
I can compress Windows 95 into a 1 bit file, hell a 0 bit file! I just need to decompress it with my special program that has all of Windows 95 as a hard-coded byte array.
Yes, it has a predictive compiler; compiles as you write.
How does it apply optimizations then? A compile-as-you-write compiler would be about as efficient as interpreting code in-place, which sucks. There must be some recompilation done later on or it compiles code in compilation units that aren't currently being modified, possibly the CU's that are the oldest in terms of last modified time.
It could be something as simple as a product naming/trademark issue.
It's not. Connectix paid FWB off to stop making SoftWindows so VirtualPC would be the only game in town. When MS bought VirtualPC from Connectix, this agreement was null and void from FWB's point of view. Apparently MS differs.
The best benchmark is to see how well something runs doing exactly what it will be doing when you buy it. When you can't do that just know that the size of your penis increases proportionally with the Ghz rating of your CPU and how many buzzwords are associated with the system you run: HT, DDR, 8x AGP, etc.
Some of these things are certainly nice (typesafe enums...) - but wouldn't it be nice to try and keep the java language *simple*?
Type-safe enums were added to eliminate previously verbose and obfuscated code. It simplifies the code without complicating the language.
There are iterators for doing stuff like foreach-looping... varargs? Why? It is an object-oriented language - take use of that polymorphism!
What does polymorphism have to do with an enhanced the for-loop or variable arity functions? The enhanced for-loop ensures that collections are properly iterated across (no out of bounds exceptions). You honestly think that
for (int i = 0; i < C.length; ++i) {/*... */}
is more complex than
for (int i : C) {/*... */}?
Also look at what you can do with variable arity functions. Say you have a constructor for a collection class and you want to be able to initialize a variable number of default values. Well, now you can. Apple's Cocoa (Foundation) library uses this to allow easy construction of NSDictionary objects.
id d = [NSDictionary dictionaryWithObjectsAndKeys:@"foo", @"bar", @"biz, @"baz"];
The other way to do it would have been
id d = [[NSMutableDictionary alloc] init]; [d setObject:@"foo" forKey:@"bar"]; [d setObject:@"biz" forKey:@"baz"];
Aside from Cocoa's long parameter naming scheme, the first method is a shorter and a lot easier. It also uses fewer messages.
The only complaint I have is the new format for the for loop... for (int x : b) isnt really easy to read. foreach x in b or something like that, while a little more verbose would be a cleaner
Introducing new keywords may break old programs if they have a variable with a name identical to that of one of the new keywords. Using the colon sidesteps this.
Zero-time is nicer than constant time any day. Depending on the scope of the loops, your solution is about the equivalent of declaring everything globally.
You're forgetting where the real work is done: in the loop body. The allocation of a single object prior to doing the real work is negligable. Also, as for the comment about global declarations, huh? If your loop body is so large that you cannot see a variable declaration as well as the entire body, your code has issues.
You missed note 2 in the text.
The generics in GJ provide more backwards compatability. Pizza is another story.
Your comments on 4 ignore what Jelovic wrote: "For example, in C++ one can implement schemes that improve the locality of reference. Or allocate and free many objects at once. Or play pointer tricks to make member access faster. Etc. None of these schemes are available in Java. "
I don't understand your comment about allocating and freeing objects in tandem. Also, I'm curious as to how accessing a data member can be made faster via a tool of memory indirection, a pointer.
And finally, about 5, I've seen some neat things done with template meta-programming. You don't like it because it's not elegant. And that's fair. But it still doesn't make Java faster.
Templates are hardly a panacea. You can't treat them the same way everyone has treated XML. "Oh, well let's see if we can use XML to fix this problem with our refridgerator." Their most potent use as a generative programming tool can be duplicated by hand, which honestly is sometimes easier than developing large amounts of groundwork with a template-savvy library. In this respect it doesn't make C++ any faster than Java, only easier in some situations.
This issue is debatable. The example the author gives is a bad one.
What small objects? For me these are iterators. I use a lot of them in my designs. Someone else may use complex numbers. A 3D programmer may use a vector or a point class. People dealing with time series data will use a time class. Anybody using these will definitely hate trading a zero-time stack allocation for a constant-time heap allocation. Put that in a loop and that becomes O (n) vs. zero. Add another loop and you get O (n^2) vs. again, zero.
Don't create a new object each time through the loop. Reuse the object to sidestep allocation/deallocation. In a tight-loop where performance matters this will help. In a situation where performance doesn't matter, then this doesn't matter at all.
2. Lots of Casts
Java 1.5 will have generics.
3. Increased Memory Use
Well let's look at the three points the author tries to make.
3.1. Programs that utilize automatic garbage collection typically use about 50% more memory that programs that do manual memory management.
What's a typical program? This one can be ignored.
3.2. Many of the objects that would be allocated on stack in C++ will be allocated on the heap in Java.
See above. This can be minimized.
3.3 Java objects will be larger, due to all objects having a virtual table plus support for synchronization primitives.
I'll admit ignorance on this issue, although my gut reaction is that hard facts need to be presented on the issue. As the original article said, Java has come a long way since 1.0.
4. Lack of Control over Details
This is a mixed bag. You could say that a language without pointers, and consequently direct memory access, will never be as powerful as a language without. But we know this isn't true. Functional languages are as powerful (from a programmatically expressive point of view, not computationally expressive), if not moreso considering the other features they offer: closures, anonymous functions, first-class functions, etc.
5. No High-Level Optimizations
The whole concept of template-metaprogramming is entirely orthogonal to the intended style of C++ programming. Meshing template-metaprogrammed code with regular code is a daunting task (on the large scale). It's a hack to get features that aren't in the language, such as a more computationally inclined macro system, lazy evaluation, etc. With that said, it is useful. However, I would rather see those features actually put into C++ and/or Java rather than having to resort to the abuse of C++'s generic programming facilities. A counter to this could be that templates allow for unbridled extention to C++, but that is most definitely not the case. Until C++ has a macro system that rivals Common Lisp's that assertion cannot be made.
But the reality of regular high-end computing is that people don't have the time to optimize their software for the latest oddball hardware platform. And even something like a hand-coded vectorized BLAS library doesn't help because most scientific software still doesn't use such libraries.
ATLAS is a BLAS implementation that is tuned for each system that it runs on. The people at Mathworks use this as the underlying BLAS system in Matlab. Mathematica Maple, etc. use this as well. There is even a G4/AltiVec optimized version available here. This is the whole point of layered software.
"Bug" implies that the problem is some independent agent, when in fact the problem is the "spoiled" code itself.
The story goes as such. There once was a problem with the ENIAC. The problem caught the attention of a government official. Said official called an individual working on the project, purported to be Grace Hopper, and inquired as to the source of the problem. Said individual said, and I quote to the best of my ability, "Sir, there is a bug in the system." Apparently a moth had died in the internals causing a malfunction. A moth most definitely qualifies as an "independant agent." More interestingly, this moth is supposedly in a museum. Perhaps this is the origin of displacing the responsibility for programs gone awry onto third party agents? I always knew the bugs had it in for us.
The problem with DLP projectors like the one my roomate bought is the "screendoor" effect that makes it look like you are viewing the image through a screendoor: little black boxes around every single pixel. This is an effect that is there from day-one and never goes away!
I think you're just looking at a DLP projector that has a very low resolution, or you're projecting it onto an area larger than it is designed for. We have one of these and it looks beautiful. No "screendoor" effect at all.
I once had a package pass through New Jersey on its way from Sacramento to Seattle. But through the ISS? I'd like a screenshot of that tracking history.
Slashdot Mirror
Bravo for the effort... but, methinks they could do this more cheaply (although, not 64-bit) with stock PC hardware.
Pundits say the machine is actually cheap. For a 64-bit machine with all the I/O and bus trimmings it is priced nicely. The only thing I'm amazed at is that VT didn't wait for headless cluster-only Xserves. Rack mounting the G5 case looks like it would be a hassle and a shame.
I can compress Windows 95 into a 1 bit file, hell a 0 bit file! I just need to decompress it with my special program that has all of Windows 95 as a hard-coded byte array.
Yet another reason to buy an iPod. My iPod never knows where it is.
The first Perl 6 book was out in 2000.
Basic rule of thumb, if you want it to be accurate don't use floating point.
Basic rule of thumb, determine what accuracy you need, then pick your number representation.
Yes, it has a predictive compiler; compiles as you write.
How does it apply optimizations then? A compile-as-you-write compiler would be about as efficient as interpreting code in-place, which sucks. There must be some recompilation done later on or it compiles code in compilation units that aren't currently being modified, possibly the CU's that are the oldest in terms of last modified time.
It could be something as simple as a product naming/trademark issue.
It's not. Connectix paid FWB off to stop making SoftWindows so VirtualPC would be the only game in town. When MS bought VirtualPC from Connectix, this agreement was null and void from FWB's point of view. Apparently MS differs.
More info here.
The best benchmark is to see how well something runs doing exactly what it will be doing when you buy it. When you can't do that just know that the size of your penis increases proportionally with the Ghz rating of your CPU and how many buzzwords are associated with the system you run: HT, DDR, 8x AGP, etc.
Have the first post, I do.
Some of these things are certainly nice (typesafe enums...) - but wouldn't it be nice to try and keep the java language *simple*?
... varargs? Why? It is an object-oriented language - take use of that polymorphism!
... */}
... */}?
Type-safe enums were added to eliminate previously verbose and obfuscated code. It simplifies the code without complicating the language.
There are iterators for doing stuff like foreach-looping
What does polymorphism have to do with an enhanced the for-loop or variable arity functions? The enhanced for-loop ensures that collections are properly iterated across (no out of bounds exceptions). You honestly think that
for (int i = 0; i < C.length; ++i) {/*
is more complex than
for (int i : C) {/*
Also look at what you can do with variable arity functions. Say you have a constructor for a collection class and you want to be able to initialize a variable number of default values. Well, now you can. Apple's Cocoa (Foundation) library uses this to allow easy construction of NSDictionary objects.
id d = [NSDictionary dictionaryWithObjectsAndKeys:@"foo", @"bar", @"biz, @"baz"];
The other way to do it would have been
id d = [[NSMutableDictionary alloc] init];
[d setObject:@"foo" forKey:@"bar"];
[d setObject:@"biz" forKey:@"baz"];
Aside from Cocoa's long parameter naming scheme, the first method is a shorter and a lot easier. It also uses fewer messages.
The only complaint I have is the new format for the for loop... for (int x : b) isnt really easy to read. foreach x in b or something like that, while a little more verbose would be a cleaner
Introducing new keywords may break old programs if they have a variable with a name identical to that of one of the new keywords. Using the colon sidesteps this.
! But, . And finally, .
Just had to get that trolling out of the way. Now let the educated and well-formulated arguments begin.
So maybe when the machines takeover they won't have to use humans for energy.
Zero-time is nicer than constant time any day. Depending on the scope of the loops, your solution is about the equivalent of declaring everything globally.
You're forgetting where the real work is done: in the loop body. The allocation of a single object prior to doing the real work is negligable. Also, as for the comment about global declarations, huh? If your loop body is so large that you cannot see a variable declaration as well as the entire body, your code has issues.
You missed note 2 in the text.
The generics in GJ provide more backwards compatability. Pizza is another story.
Your comments on 4 ignore what Jelovic wrote: "For example, in C++ one can implement schemes that improve the locality of reference. Or allocate and free many objects at once. Or play pointer tricks to make member access faster. Etc. None of these schemes are available in Java. "
I don't understand your comment about allocating and freeing objects in tandem. Also, I'm curious as to how accessing a data member can be made faster via a tool of memory indirection, a pointer.
And finally, about 5, I've seen some neat things done with template meta-programming. You don't like it because it's not elegant. And that's fair. But it still doesn't make Java faster.
Templates are hardly a panacea. You can't treat them the same way everyone has treated XML. "Oh, well let's see if we can use XML to fix this problem with our refridgerator." Their most potent use as a generative programming tool can be duplicated by hand, which honestly is sometimes easier than developing large amounts of groundwork with a template-savvy library. In this respect it doesn't make C++ any faster than Java, only easier in some situations.
1. All Objects are Allocated on the Heap
This issue is debatable. The example the author gives is a bad one.
What small objects? For me these are iterators. I use a lot of them in my designs. Someone else may use complex numbers. A 3D programmer may use a vector or a point class. People dealing with time series data will use a time class. Anybody using these will definitely hate trading a zero-time stack allocation for a constant-time heap allocation. Put that in a loop and that becomes O (n) vs. zero. Add another loop and you get O (n^2) vs. again, zero.
Don't create a new object each time through the loop. Reuse the object to sidestep allocation/deallocation. In a tight-loop where performance matters this will help. In a situation where performance doesn't matter, then this doesn't matter at all.
2. Lots of Casts
Java 1.5 will have generics.
3. Increased Memory Use
Well let's look at the three points the author tries to make.
3.1. Programs that utilize automatic garbage collection typically use about 50% more memory that programs that do manual memory management.
What's a typical program? This one can be ignored.
3.2. Many of the objects that would be allocated on stack in C++ will be allocated on the heap in Java.
See above. This can be minimized.
3.3 Java objects will be larger, due to all objects having a virtual table plus support for synchronization primitives.
I'll admit ignorance on this issue, although my gut reaction is that hard facts need to be presented on the issue. As the original article said, Java has come a long way since 1.0.
4. Lack of Control over Details
This is a mixed bag. You could say that a language without pointers, and consequently direct memory access, will never be as powerful as a language without. But we know this isn't true. Functional languages are as powerful (from a programmatically expressive point of view, not computationally expressive), if not moreso considering the other features they offer: closures, anonymous functions, first-class functions, etc.
5. No High-Level Optimizations
The whole concept of template-metaprogramming is entirely orthogonal to the intended style of C++ programming. Meshing template-metaprogrammed code with regular code is a daunting task (on the large scale). It's a hack to get features that aren't in the language, such as a more computationally inclined macro system, lazy evaluation, etc. With that said, it is useful. However, I would rather see those features actually put into C++ and/or Java rather than having to resort to the abuse of C++'s generic programming facilities. A counter to this could be that templates allow for unbridled extention to C++, but that is most definitely not the case. Until C++ has a macro system that rivals Common Lisp's that assertion cannot be made.
But the reality of regular high-end computing is that people don't have the time to optimize their software for the latest oddball hardware platform. And even something like a hand-coded vectorized BLAS library doesn't help because most scientific software still doesn't use such libraries.
ATLAS is a BLAS implementation that is tuned for each system that it runs on. The people at Mathworks use this as the underlying BLAS system in Matlab. Mathematica Maple, etc. use this as well. There is even a G4/AltiVec optimized version available here. This is the whole point of layered software.
It's nice that this webpage says in caps "IP LOGGED" followed by your IP. I guess this way he can tell who's HTTP GET broke the webserver's back.
This update erased my HD! It messed up everything! Damn you Apple! I'm going to buy a PC tomorrow!
I just thought I'd get that out of the way. Nothing to see here, move along.
"Bug" implies that the problem is some independent agent, when in fact the problem is the "spoiled" code itself.
The story goes as such. There once was a problem with the ENIAC. The problem caught the attention of a government official. Said official called an individual working on the project, purported to be Grace Hopper, and inquired as to the source of the problem. Said individual said, and I quote to the best of my ability, "Sir, there is a bug in the system." Apparently a moth had died in the internals causing a malfunction. A moth most definitely qualifies as an "independant agent." More interestingly, this moth is supposedly in a museum. Perhaps this is the origin of displacing the responsibility for programs gone awry onto third party agents? I always knew the bugs had it in for us.
You've got to be shitting me.
The problem with DLP projectors like the one my roomate bought is the "screendoor" effect that makes it look like you are viewing the image through a screendoor: little black boxes around every single pixel. This is an effect that is there from day-one and never goes away!
I think you're just looking at a DLP projector that has a very low resolution, or you're projecting it onto an area larger than it is designed for. We have one of these and it looks beautiful. No "screendoor" effect at all.
I once had a package pass through New Jersey on its way from Sacramento to Seattle. But through the ISS? I'd like a screenshot of that tracking history.
Someone named Gibbs figured this out years earlier, but he worked at the NSA and couldn't tell anyone for a long time.