I haven't see this shootout article (and apparently won't be able to at that link...look for yourself), but based on personal experience, trivial programs tend to benchmark similarly (count to a billion, stop.).
Yeah...forgot that the dude redirects you if you're coming from Slashdot. Copy and paste the link manually and it should work.
First you said "small programs" and now you're talking about "trivial programs". When you're comparing languages, you'd probably want to compare how they perform the things you need them to perform. You originally said something about text-parsing and are now down to a useless loop.
By the way, Perl's regex libraries are written in C. Not that there's anything wrong with that, but it's clear that Perl is probably not the language you'd choose when implementing something that's computationally intensive.
Java is cheap (free), multipurpose, and difficult to learn to use well, but suitable for large applications.
Perl is cheap (free), multipurpose, and easy to learn to use, but difficult to create large, maintainable apps with (subject to change with Perl 6?)
First of all, your "easy to learn" comparison is asymmetric: you didn't include the term "well" in the Perl version. Secondly, I, personally, think that Java is easier to learn than Perl. I also don't think I'm the only one who thinks so.
As far as how a program performs, unless you're doing a lot of FP math, most small programs of similar function written by programmers of similar skill in a given language will be fairly even, performance-wise.
Though I'm not sure what you mean by "small programs", but the "Great Computer Language Shootout" suggests a high amount of variation between languages (language implementations, actually) for very small programs.
However I would not go as far as to say that a bad test means that java dose not have good performance for "long-running" computationally intensive applications.
I've written web crawlers in Perl and Java that run for weeks at a time. Comparing their performance to existing crawlers written in C/C++, the performances are equivalent (though the Java and Perl bots suck up more memory).
This is because a web crawler isn't very computationally intensive. You're probably be waiting for I/O most of the time. It's because of this, and not because it's "long-running", that the performances are comparable.
If there isn't much duplicated code, it's probably slower than templates. The wxWindows solution seems like it is more like Java's Generics than C++'s templates.
Does generics on VB.Net even make sense? If you don't want to bother with casts, can't you just declare a generic variable that can hold anything? And if you want speed, don't use VB.Net as it is clearly not designed for that.
Um...do you know how templates work? I'm not talking about typecasts when I say "lot of code". I'm talking about the almost identical copies each template function (usually, the only difference is a tiny comparison operation).
Now...I wouldn't consider the extra code to be a fault of template programming, since I can't think of a better solution that would be as fast (time-space, my friend). Templates don't even force you to have the extra code either, but libraries like the STL make use of the feature to speed things up.
Yes there is, and it's called void*. It's not exactly polymorphism but C programmers do just fine with it.
C++ templates, howerver, speed things up and let you have collections that actually store the data instead of point to dynamically allocated memory. Templates also get rid of unnecessary type casts (which, in Java, are almost always the same as the slow dynamic_cast from C++).
Well, my statement was based on the first paragraph of the article (do people even get that far before posting?). But it's third-hand knowledge at best. Also, by defensive, I didn't mean that it only defended products that were related to the patent. I thought it was more like IBM's where if you sued them for patent infringement, they'd probably have many patents covering the everyday use of computers, allowing them to counter-sue.
Since my original post, I read that Microsoft did, in fact, use software patents to force a free ASF video implementation to shut down.
Not necessarily. The patents could be, as MS claims, defensive patents. It gives them some clout when dealing with unnecessarily stupid situations involving little craphole companies.
Even the article says that Microsoft doesn't have a history of enforcing patents (who reads the article anyway?). What they do instead is keep adding to the API forcing compatible projects to constantly play catch-up (seeWine).
Hopefully the script timeout. The interpreter/compiler had better recognize a tail call in its simplest form. Then again, it probably wasn't written with functional programming in mind.
Numbers that aren't uniformly distributed will exist in a smaller range than those that are uniformly distributed. A brute force attack would be easier against an RNG that produced numbers that aren't uniformly distributed.
One problem with "javac" doing range checking may be that the JRE doesn't trust.class files. Everything is verified first. Unless it's easy to verify a correct bounds-check removal, the runtime compiler will have to duplicate the original analysis anyway. Maybe the bytecode could be extended to allow for compilation hints.
Instead, "javac" could structure the output in such a way that it is trivial for the HotSpot compiler to figure out that the check can be eliminated. I believe HDL compilers do something similar.
To begin with, recursion isn't a very efficient process in Java. Each time the method calls itself, all of the current local variables are stored, a new copy of the method is made (with new locals), and execution continues in the new copy.
A recursive call is just as fast as any other procedure call. You make it seem like a whole bunch of extra work is being done. "Storing" current local variables and making "a new copy of the method" often involves merely incrementing a register (the stack pointer). Function calls are usually slowed down because of parameters and storing things onto the stack.
Try doing that with an NFA, dumbass. An NFA cannot detect matching parentheses. A pushdown automaton can. This should be pretty obvious since your example is a grammar production of the context-free grammar style. PDAs are related to CFGs like NFAs/DFAs are related to regexes (though the relationship isn't as clean in the former case).
Regexes aren't NFAs but regexes can be used to describe any regular language (and only regular languages) and NFAs can recognize any regular language (and only regular languages). They are "equivalent" in terms of theoretical computational power (the traditional definitions state that regexes generate languages and NFAs recognize them). Also, DFAs can recognize all and only the regular languages.
However, I still don't understand why the grandparent poster said:
I'm an avid fan of regular expressions simply because a nondeterministic finite automata is far more flexible than linear code.
If "linear code" means non-branching code, then I guess that that's true. What I don't get is how he/she is restricted to linear code. Regular code is turing-complete and therefore much more powerful than regular expressions. Regular expressions are more compact and map better to certain problems, but they are provably less "flexible".
As a side note, I think that Larry Wall suggested calling them "patterns" instead of "regexes" because they are more powerful than regular expressions (though I'm sure the old terminology will still be used). This is fully described here.
Re:Still building 1.4.1 native on FreeBSD!
on
Java 1.4.2 Released
·
· Score: 2, Insightful
If your machine is swapping non-stop, it could be thrashing. If it's thrashing, then you should probably give up and buy more memory since you're basically using your hard drive as RAM at this point.
You might want to try generating the Java API docs with 'javadoc' for more VM fun.
Re:startup time improvements
on
Java 1.4.2 Released
·
· Score: 3, Interesting
That's because a large part of some scripting language libraries is native code and is kept as a shared library (to be faulted in as necessary).
Java's libraries are mostly written in Java and they are loaded, verified and usually partly compiled each time. Since is not part of the "text" segment (it's probably in the heap), sharing requires using some shared memory facilities.
I think it would be nice if there was a "javalib" utility that would load up the Java classes, compile them, and produce a DLL. Then at least the JVM wouldn't have to load (and/or recompile) the core library every time.
To take it even further, if the JVM was suid root, the DLL could be updated every time anybody runs a Java program (like suid "man").
Slashdot Mirror
autopr0n wrote:
And later wrote:
If you had used "if" originally, it would have been pretty clear that it was hypothetical. But you didn't. You used "for".
Yeah...forgot that the dude redirects you if you're coming from Slashdot. Copy and paste the link manually and it should work.
First you said "small programs" and now you're talking about "trivial programs". When you're comparing languages, you'd probably want to compare how they perform the things you need them to perform. You originally said something about text-parsing and are now down to a useless loop.
By the way, Perl's regex libraries are written in C. Not that there's anything wrong with that, but it's clear that Perl is probably not the language you'd choose when implementing something that's computationally intensive.
First of all, your "easy to learn" comparison is asymmetric: you didn't include the term "well" in the Perl version. Secondly, I, personally, think that Java is easier to learn than Perl. I also don't think I'm the only one who thinks so.
Though I'm not sure what you mean by "small programs", but the "Great Computer Language Shootout" suggests a high amount of variation between languages (language implementations, actually) for very small programs.
I didn't.
This is because a web crawler isn't very computationally intensive. You're probably be waiting for I/O most of the time. It's because of this, and not because it's "long-running", that the performances are comparable.
Ok...but can containers hold anything besides pointers (or other values that are less than or equal to pointers in size)?
If there isn't much duplicated code, it's probably slower than templates. The wxWindows solution seems like it is more like Java's Generics than C++'s templates.
Does generics on VB.Net even make sense? If you don't want to bother with casts, can't you just declare a generic variable that can hold anything? And if you want speed, don't use VB.Net as it is clearly not designed for that.
Um...do you know how templates work? I'm not talking about typecasts when I say "lot of code". I'm talking about the almost identical copies each template function (usually, the only difference is a tiny comparison operation).
Now...I wouldn't consider the extra code to be a fault of template programming, since I can't think of a better solution that would be as fast (time-space, my friend). Templates don't even force you to have the extra code either, but libraries like the STL make use of the feature to speed things up.
Wow...a new low. Forget not reading the article. Thus dawns the age of not reading the summary or the comment you are replying to.
Yes there is, and it's called void*. It's not exactly polymorphism but C programmers do just fine with it.
C++ templates, howerver, speed things up and let you have collections that actually store the data instead of point to dynamically allocated memory. Templates also get rid of unnecessary type casts (which, in Java, are almost always the same as the slow dynamic_cast from C++).
Many functional programming languages have template-like features that are absolutely essential.
Generics will take care of the syntatic part but templates are much faster (though they produce a lot of code).
Well, my statement was based on the first paragraph of the article (do people even get that far before posting?). But it's third-hand knowledge at best. Also, by defensive, I didn't mean that it only defended products that were related to the patent. I thought it was more like IBM's where if you sued them for patent infringement, they'd probably have many patents covering the everyday use of computers, allowing them to counter-sue.
Since my original post, I read that Microsoft did, in fact, use software patents to force a free ASF video implementation to shut down.
Not necessarily. The patents could be, as MS claims, defensive patents. It gives them some clout when dealing with unnecessarily stupid situations involving little craphole companies.
Even the article says that Microsoft doesn't have a history of enforcing patents (who reads the article anyway?). What they do instead is keep adding to the API forcing compatible projects to constantly play catch-up (see Wine).
Hopefully the script timeout. The interpreter/compiler had better recognize a tail call in its simplest form. Then again, it probably wasn't written with functional programming in mind.
Yes it is. Even Google says so.
Umm...how?
Numbers that aren't uniformly distributed will exist in a smaller range than those that are uniformly distributed. A brute force attack would be easier against an RNG that produced numbers that aren't uniformly distributed.
This can also be done for regular tail calls (not just for recursive calls) though it may be more work (depending on the underlying architecture).
One problem with "javac" doing range checking may be that the JRE doesn't trust .class files. Everything is verified first. Unless it's easy to verify a correct bounds-check removal, the runtime compiler will have to duplicate the original analysis anyway. Maybe the bytecode could be extended to allow for compilation hints.
Instead, "javac" could structure the output in such a way that it is trivial for the HotSpot compiler to figure out that the check can be eliminated. I believe HDL compilers do something similar.
A recursive call is just as fast as any other procedure call. You make it seem like a whole bunch of extra work is being done. "Storing" current local variables and making "a new copy of the method" often involves merely incrementing a register (the stack pointer). Function calls are usually slowed down because of parameters and storing things onto the stack.
So few words, so much ignorance...
Try doing that with an NFA, dumbass. An NFA cannot detect matching parentheses. A pushdown automaton can. This should be pretty obvious since your example is a grammar production of the context-free grammar style. PDAs are related to CFGs like NFAs/DFAs are related to regexes (though the relationship isn't as clean in the former case).
Regexes aren't NFAs but regexes can be used to describe any regular language (and only regular languages) and NFAs can recognize any regular language (and only regular languages). They are "equivalent" in terms of theoretical computational power (the traditional definitions state that regexes generate languages and NFAs recognize them). Also, DFAs can recognize all and only the regular languages.
However, I still don't understand why the grandparent poster said:
If "linear code" means non-branching code, then I guess that that's true. What I don't get is how he/she is restricted to linear code. Regular code is turing-complete and therefore much more powerful than regular expressions. Regular expressions are more compact and map better to certain problems, but they are provably less "flexible".
As a side note, I think that Larry Wall suggested calling them "patterns" instead of "regexes" because they are more powerful than regular expressions (though I'm sure the old terminology will still be used). This is fully described here.
If your machine is swapping non-stop, it could be thrashing. If it's thrashing, then you should probably give up and buy more memory since you're basically using your hard drive as RAM at this point.
You might want to try generating the Java API docs with 'javadoc' for more VM fun.
That's because a large part of some scripting language libraries is native code and is kept as a shared library (to be faulted in as necessary).
Java's libraries are mostly written in Java and they are loaded, verified and usually partly compiled each time. Since is not part of the "text" segment (it's probably in the heap), sharing requires using some shared memory facilities.
I think it would be nice if there was a "javalib" utility that would load up the Java classes, compile them, and produce a DLL. Then at least the JVM wouldn't have to load (and/or recompile) the core library every time.
To take it even further, if the JVM was suid root, the DLL could be updated every time anybody runs a Java program (like suid "man").
I think it's the same lawyer too!