You're missing the entire point of what assembly is used for. Generally speaking, there is nothing inherently faster about using assembly over other higher level languages. In fact, C and C++ compilers will usually beat the pants off of any but the most experienced assembly programmers.
What assembly is good for is using machine-specific primitives that aren't accessible via the high level language you are using. For example, currently, if you want to make use of the SIMD extensions of most processors, you'll have to write assembly, because the compilers just aren't smart enough to figure out how to parallelize your code. (This is changing, though. Intel has already released a C++ compiler which seems to be a good start at this).
Programming platform independent assembly is a waste of time. Any competent VM has an interface that lets you call into native code - thus letting you write any platform specific assembly you might desire.
Pfft... Now, why, oh why, would Mr. Joy ever say anything like that?
Here's an excerpt from "The COM and COM+ Programming Primer" about ActiveX that might explain why:
None of the other names has caused even nearly as much confusion as this one....
The reason so many people are confused by the name ActiveX is because
the definition has changed. Originally ActiveX was a brand name for all COM-based Microsoft technologies that had utility on the World Wide Web.
Emphasis mine.
Hope you don't feel silly, because you've been taken in by Microsoft re-writing history.
That's probably because there's really no way to obfuscate Java byte code, since it's all java.lang.reflectable anyway - you can use Java code to dynamically load a class name at run time and then discover methods it contains and public variables it has.
I think you're missing part of the point of an obfuscator. Most obfuscators turn meaningful class and method names like "FourierTransform" and "calculateNow" to "A_" and "b_". So programs end up looking like this:
A_.b_( c_, x1_, y2_ );
Of course, obfuscators can't perform this name mangling on API's which are meant to be exposed publicly.
Sun may want to consider creating a secure JAR file which is loaded by a "secure" class loader...
I once upon a time built a class loader in C++ to protect the "IP investment" for a product. It would verify the product license, and then load the product's encrypted classes from disk, into the virtual machine. Of course, people can't compile against encrypted classes, so I had to write a program which would read the product's class files and generate a library of "stub classes" which our SDK users could compile against.
Bottom line is that every.class file contains a list of all methods and public variables as well as being one instance of an original class definition - not useful for making your program structure hard to dissassemble.
Strangely enough, Microsoft's CLR has the exact same problems, but amazingly, nobody is whining and complaining about it.
Frankly, people don't seem to understand that "native compilation" is no magic bullet. If the processor understands the code, so can a human. And if you've ever spent some serious time designing hardware or programming assembly for a microcontroller or a processor, you know how easy it really is to decipher assembly.
It goes straight from source to native; for one thing, the source format exposes stuff that allows it to be more heavily optimized by GCC's optimizer than the bytecode format does.
That's an interesting statement, because, in a discussion with a Sun engineer (Jeff Kesselman I believe), people were told that, concerning optimization, the point of the compiler was to produce code in a form that was optimal for the VM to optimize.
I can't remember exactly where the discussion was, but I'm sure you can find it if you do a search through www.javagaming.org.
Obviously, having to support the vast amount of devices out there has been one of the most major contributors to the downfalls in operating systems.
There is a project, UDI (Uniform Driver Interface), which is working to rectify the situation, though. It's intent is to even the playing field, by providing source (and in many cases binary) compatibility for device drivers across os and hardware platforms. All the major players are involved - IBM, Sun, Intel, HP,... (Microsoft, most notably missing from the list).
They already have reference drivers working for several platforms... It will be interesting to see how this plays out.
I don't think he was referring to the fact that it's easy to get stuck using Win32 APIs, but rather that VC++ is known to be one of the worst compilers on the market when it comes to standards conformance. Don't believe me? Spend some time on comp.lang.c++.moderated and get the opinions of some of the most respected C++ developers in the world.
I have a friend who works in the recording industry, and his comments indicate the former: albums do not an artist pay.
Re:Comment from a real PERL programmer
on
Perl6 for Mortals
·
· Score: 1
Congratulations, you've used a teaching program in java to compare to your perl program. I spent five minutes making the java program smaller - and I get 10 lines of code. I would say that a ratio of 3:1 isn't bad considering the differences...
Obviously, you've picked the best program that you could to play into perl's strengths, and it shows some here. If you were to play towards java's strengths, you'd write a larger program where encapsulation, maintainability, readability, and robustness are the most important factors.
I'm not bashing perl here. I'm just saying that it's a good language for doing exactly what you are doing here: writing a 3-line program.
I find that when I'm in command line shells, I often repeat the same few tasks over and over. For example, make x, cp y, ls z, tail w. Most of the time, it takes me on the order of 100 milliseconds to execute one of those commands (up-arrow + enter). Moving a mouse, on the other hand, takes me several orders of magnitude longer.
When an operation can be hot-keyed (for example, compilation in most recent IDEs), then the cost in time is proportional... but then you're back to using a keyboard and not a mouse.
amorphis wrote:
kind of ironic, when that's exactly what the original DIVX did
The largest complaint about Divx was that it would become the only option for viewing DVD movies, because all those greedy companies like Disney had plans for unlimited rental-based revenue. Can't you imagine you're five year old kid... "Daddy, Daddy. I want to watch Winnie the Pooh again" - for the hundreth time. Can you say, "Cha-ching"?
Doesn't that immediately strike you as highly analogous to Microsoft's plans for going to the rental software model?
JohnQPublic wrote:
More importantly, Lisp is not "file oriented". In Lisp, a function is a function is a function - you don't have the complex mess of static/public/private/whatever.
I'd like to note a couple of things here.
First, the compilation unit of Java is not a file. It's a class. It can be easily demonstrated that Java classes and files don't have to have any relationship to one another as evidenced by tools like Visual Age for Java.
Second, except for deprecated use, static has nothing to do with files - in C++ or Java.
Third, the lack of access specifiers in Lisp contributes not only to its simplicity, but also its lack of scalability. The ability to define public interfaces and private implementations is key for large projects.
Having said all of that, Lisp is not a bad language. It's just one more tool in my toolbox.
God bless,
-Toby Reyelts
Re:Who's going to pay that??!
on
$1200 Cheap!
·
· Score: 1
Mr. Sketch wrote:
Who would actually pay 1200 bucks for a game console system? I didn't even spend that on my computer which probably has a bit more power and will run a lot more games.
Whoa! Just a bit more power for 1200 bucks? Geez. You can get a computer with gigabytes of RAM, a GeForce 3, a 1GHZ processor, a 40G hard drive, plus everything else an Xbox comes with for about half that. That blows the Xbox right out of the water.
You could be much more conservative and still get a computer with better specs and in the same price range as the $299 Xbox.
That's part of the problem with consoles... They become obsoleted before they even hit the market. For example, the Xbox (which hasn't even been released yet) is supposed to run a 733MHZ P3, but Intel already has a 1.8GHZ P4 out in stores. The Xbox is supposed to contain an 8G hard drive, but 40G hard drives have been available cheaply for quite some time now. The Xbox graphics chipset also falls behind chipsets like the GeForce 3 and the Radeon 8500.
The real question is: Why would anyone want to spend so much for a cheap PC? (When most Americans already own one of those). It seems like most developers will use DirectX, so all of the games will be immediately 'ported' to the PC platform anyway.
I'd guess that the vast bulk of Java development is for relatively small applets and servelets...
I don't believe that is true at all. Why the big hype about J2EE then, which encompasses a whole host of enterprise technology including Servlets/JSP, JMS, JDBC, EJB, JNDI, etc...?
The last two projects that I've worked on have been writing supply chain systems for DaimlerChrysler and Boeing. I'd hardly call that small applets and servlets.
That being said, unlike a lot of posters here, I don't see speed as being a permanent impediment to Java's growth.
HotSpot has definitely improved Java speed greatly. JDK1.4 also includes some tremendous performance changes for Java with additions like file mapping, asynchronous i/o, native byte buffers, and volatile images to the API. You're about to start seeing some kick-butt client-side applications (including games) for Java.
Re:Taking business elsewhere - !@#$%
on
Broadband Crackdown
·
· Score: 2, Insightful
If you don't like their actions or policies, then take your business elsewhere.
This attitude makes me sick. The idea of capitalism seems great, but it just doesn't work. How can I take my dollars elsewhere, when there's nowhere else to go? Every saturated market ends up in the hands of an oligopoly - not much better than a monopoly. In the case of broadband access, it's even worse, because of the government sanctioned monopolies on cable. Go on, ask me what choices I have for broadband access. [sigh]
Slashdot Mirror
You're missing the entire point of what assembly is used for. Generally speaking, there is nothing inherently faster about using assembly over other higher level languages. In fact, C and C++ compilers will usually beat the pants off of any but the most experienced assembly programmers.
What assembly is good for is using machine-specific primitives that aren't accessible via the high level language you are using. For example, currently, if you want to make use of the SIMD extensions of most processors, you'll have to write assembly, because the compilers just aren't smart enough to figure out how to parallelize your code. (This is changing, though. Intel has already released a C++ compiler which seems to be a good start at this).
Programming platform independent assembly is a waste of time. Any competent VM has an interface that lets you call into native code - thus letting you write any platform specific assembly you might desire.
God bless,
-Toby
Emphasis mine.
Hope you don't feel silly, because you've been taken in by Microsoft re-writing history.
God bless,
-Toby
I think you're missing part of the point of an obfuscator. Most obfuscators turn meaningful class and method names like "FourierTransform" and "calculateNow" to "A_" and "b_". So programs end up looking like this:
A_.b_( c_, x1_, y2_ );
Of course, obfuscators can't perform this name mangling on API's which are meant to be exposed publicly.
Sun may want to consider creating a secure JAR file which is loaded by a "secure" class loader...
I once upon a time built a class loader in C++ to protect the "IP investment" for a product. It would verify the product license, and then load the product's encrypted classes from disk, into the virtual machine. Of course, people can't compile against encrypted classes, so I had to write a program which would read the product's class files and generate a library of "stub classes" which our SDK users could compile against.
Bottom line is that every .class file contains a list of all methods and public variables as well as being one instance of an original class definition - not useful for making your program structure hard to dissassemble.
Strangely enough, Microsoft's CLR has the exact same problems, but amazingly, nobody is whining and complaining about it.
Frankly, people don't seem to understand that "native compilation" is no magic bullet. If the processor understands the code, so can a human. And if you've ever spent some serious time designing hardware or programming assembly for a microcontroller or a processor, you know how easy it really is to decipher assembly.
God bless,
-Toby
That's an interesting statement, because, in a discussion with a Sun engineer (Jeff Kesselman I believe), people were told that, concerning optimization, the point of the compiler was to produce code in a form that was optimal for the VM to optimize. I can't remember exactly where the discussion was, but I'm sure you can find it if you do a search through www.javagaming.org.
God bless,
-Toby
Obviously, having to support the vast amount of devices out there has been one of the most major contributors to the downfalls in operating systems.
... (Microsoft, most notably missing from the list).
There is a project, UDI (Uniform Driver Interface), which is working to rectify the situation, though. It's intent is to even the playing field, by providing source (and in many cases binary) compatibility for device drivers across os and hardware platforms. All the major players are involved - IBM, Sun, Intel, HP,
They already have reference drivers working for several platforms... It will be interesting to see how this plays out.
I don't think he was referring to the fact that it's easy to get stuck using Win32 APIs, but rather that VC++ is known to be one of the worst compilers on the market when it comes to standards conformance. Don't believe me? Spend some time on comp.lang.c++.moderated and get the opinions of some of the most respected C++ developers in the world.
I have a friend who works in the recording industry, and his comments indicate the former: albums do not an artist pay.
Congratulations, you've used a teaching program in java to compare to your perl program. I spent five minutes making the java program smaller - and I get 10 lines of code. I would say that a ratio of 3:1 isn't bad considering the differences...
Obviously, you've picked the best program that you could to play into perl's strengths, and it shows some here. If you were to play towards java's strengths, you'd write a larger program where encapsulation, maintainability, readability, and robustness are the most important factors.
I'm not bashing perl here. I'm just saying that it's a good language for doing exactly what you are doing here: writing a 3-line program.
I find that when I'm in command line shells, I often repeat the same few tasks over and over. For example, make x, cp y, ls z, tail w. Most of the time, it takes me on the order of 100 milliseconds to execute one of those commands (up-arrow + enter). Moving a mouse, on the other hand, takes me several orders of magnitude longer.
When an operation can be hot-keyed (for example, compilation in most recent IDEs), then the cost in time is proportional... but then you're back to using a keyboard and not a mouse.
God bless,
-Toby Reyelts
The largest complaint about Divx was that it would become the only option for viewing DVD movies, because all those greedy companies like Disney had plans for unlimited rental-based revenue. Can't you imagine you're five year old kid... "Daddy, Daddy. I want to watch Winnie the Pooh again" - for the hundreth time. Can you say, "Cha-ching"?
Doesn't that immediately strike you as highly analogous to Microsoft's plans for going to the rental software model?
God bless,
-Toby Reyelts
I'd like to note a couple of things here.
- First, the compilation unit of Java is not a file. It's a class. It can be easily demonstrated that Java classes and files don't have to have any relationship to one another as evidenced by tools like Visual Age for Java.
- Second, except for deprecated use, static has nothing to do with files - in C++ or Java.
- Third, the lack of access specifiers in Lisp contributes not only to its simplicity, but also its lack of scalability. The ability to define public interfaces and private implementations is key for large projects.
Having said all of that, Lisp is not a bad language. It's just one more tool in my toolbox.God bless,
-Toby Reyelts
Who would actually pay 1200 bucks for a game console system? I didn't even spend that on my computer which probably has a bit more power and will run a lot more games.
Whoa! Just a bit more power for 1200 bucks? Geez. You can get a computer with gigabytes of RAM, a GeForce 3, a 1GHZ processor, a 40G hard drive, plus everything else an Xbox comes with for about half that. That blows the Xbox right out of the water.
You could be much more conservative and still get a computer with better specs and in the same price range as the $299 Xbox.
That's part of the problem with consoles... They become obsoleted before they even hit the market. For example, the Xbox (which hasn't even been released yet) is supposed to run a 733MHZ P3, but Intel already has a 1.8GHZ P4 out in stores. The Xbox is supposed to contain an 8G hard drive, but 40G hard drives have been available cheaply for quite some time now. The Xbox graphics chipset also falls behind chipsets like the GeForce 3 and the Radeon 8500.
The real question is: Why would anyone want to spend so much for a cheap PC? (When most Americans already own one of those). It seems like most developers will use DirectX, so all of the games will be immediately 'ported' to the PC platform anyway.
God bless,
-Toby Reyelts
I'd guess that the vast bulk of Java development is for relatively small applets and servelets...
I don't believe that is true at all. Why the big hype about J2EE then, which encompasses a whole host of enterprise technology including Servlets/JSP, JMS, JDBC, EJB, JNDI, etc...? The last two projects that I've worked on have been writing supply chain systems for DaimlerChrysler and Boeing. I'd hardly call that small applets and servlets.
That being said, unlike a lot of posters here, I don't see speed as being a permanent impediment to Java's growth.
HotSpot has definitely improved Java speed greatly. JDK1.4 also includes some tremendous performance changes for Java with additions like file mapping, asynchronous i/o, native byte buffers, and volatile images to the API. You're about to start seeing some kick-butt client-side applications (including games) for Java.
For example, check out www.javagaming.org.
God bless,
-Toby Reyelts
This attitude makes me sick. The idea of capitalism seems great, but it just doesn't work. How can I take my dollars elsewhere, when there's nowhere else to go? Every saturated market ends up in the hands of an oligopoly - not much better than a monopoly. In the case of broadband access, it's even worse, because of the government sanctioned monopolies on cable. Go on, ask me what choices I have for broadband access. [sigh]
One frustrated broadband user, -Toby