I would like to know the best (fastest) scripting language for use in Java. I don't much care if it takes long to load (as long as it is a one time load), as opposed to how fast it runs. I am currently using Jython (python) but I would like something faster.
There's already a lot of benchmarks and discussions on this.
While I don't give a lot of credit (none) to benchmarking. The top 2 contenders are (listed in order of performance speed):
Scala
Groovy++
I've tried both and their not the same in my use cases. Scala came out much faster than groovy++ (again.. this is MY use cases not and may show differently in your use cases). Scala was almost native java speeds.
Groovy (not Groovy++), Closure, JRuby are all really slow.
Groovy and JRuby run approximately 8 times slower on simple algorithms compared to the java versions even after a decent amount of warmup.
I can't guarantee that you would get the same numbers that I did but this would be a decent order to try them in.
Groovy is a very good scripting language that plays very nicely with Java.
That being said, Java can run any scripting language via the command line, or it could run any other program if you wanted it to. So I would focus less on the Java side of it and more on the 'faster' side of it.
There's nothing from stopping you to writing a C++ program to compiled code and calling that.
Further, what profiling tests have you done with Jython/python? How slow is it that it doesn't meet your expectations? Is it causing problems? Is it perhaps in the python script?
Have you tried programming in Java?
You can write some of the performance critical functionality in Java, and leave most of the code in the scripting language of your choice.
Java since version 7 has support for normal compiling at runtime, if SDK is on the path, javax.tools.JavaCompiler
LuaJIT https://github.com/gareins/dynamic_benchmarks
The above benchmarks show LuaJIT to be very fast but it still qualifies as a dynamic language.
Related
Someone told me there was more overhead for Java because you can essentially run it on most operating systems and that C# doesn't have that overhead so then it can execute at near C++ speeds.
So is there more overhead in Java, or does each OS has it's own overhead for it's JVM implementation?
C#, Java (and I'll toss it in there too - JavaScript) are languages. Languages are not fast or slow, they just are specifications for how we humans write things that are to eventually be handled by a computer.
The JVM is the Java Virtual Machine. But there are several different versions of it. There's HotSpot (the original), OpenJDK, And then one can look at JRockit from BEA, Apache Harmony and a bunch more.
For C# there is the CLR, but there's also Mono's runtime. There are also others that have been abandoned over time.
JavaScript (because I'm tossing that in there) has an entire army of runtimes. Some of those runtimes are faster than others.
It is the runtime that is faster or slower than another - even possibly for the same language. But that one is 'cross platform' and another is not is not enough of an indication to say that one is faster than the other. There are a great many other things at work and benchmarks can be constructed that show one combination being faster than another for each one.
Going even further, one can look at languages that span multiple runtimes. You've got Python with CPython as its default implementation - but there's Jython that runs in the JVM and IronPython that runs in the CLR. Similar examples can be found with Ruby, IronRuby, and JRuby or Clojure which can be compiled to JavaScript via ClojureScript and then run on one of the JavaScript runtimes rather than a JVM.
Again, its not the language that is fast or slow - but rather how its implemented in its runtime.
The Java language and the Java Virtual Machine (JVM) are completely separate entities. Oracle has done an excellent job of separating the two, so that other languages (like Scala or even Ruby) can run on the JVM.
The Java language itself is definitely written with the intent of targeting the JVM, but, so far as I know, there is no actual requirement that it must. So far as I know it's completely possible to write a Java compiler that generates native code, rather than Java bytecode. (This is all completely hypothetical. I've never heard of anyone actually doing that - there would be very little point. Current implementations of the JVM tend to be almost as fast as native code, and any benefit gained by this would be greatly outweighed by the loss of portability it would entail.)
The situation is further complicated by the fact that C# doesn't exactly have a VM, as discussed here. So the best comparison you can make is "does this implementation of the JVM run this Java code faster than that implementation of the .NET framework runs that C# code?"
In the end, unless there is a remarkable speed difference for very similar code, the comparison just isn't that compelling because there are too many variables. Use a different JVM, or a different Java compiler, or a different .NET implementation, or a different C# compiler, or run the same code on a different machine, and the numbers change.
I am trying to optimize the performance of some natural language processing in a python project I am currently working on. Basically I would like to outsource the computationally intensive parts to use apache OpenNLP, which is written in Java.
My question is what would be the recommended way to link Java functions/classes back to my python code? The three main ways I have thought about are
using C/C++ bindings in python and then embedding a JVM in my C program. This is what I am leaning towards because I am somewhat familiar writing C extensions to python, but using a triangle of languages where C only functions as an intermediary doesn't seem right somehow.
using Jython. My main concern with this is that CPython is the overwhelmingly popular python implementation as far as I know and I don't want to break compatibility with other collaborators or packages.
streaming input and output to the binaries that come with OpenNLP. Apache provides tokenizers and such as stand-alone binaries that you can pipe data to and from. This would probably be the easiest option to implement, but it also seems like the most crude.
I'm wondering if anyone who has experience interfacing python and java knows how much the performance is likely to differ between these options, and which one is "recommended" or considered best practice in such a situation - or of course if there is an entirely different way to do it that I haven't thought of.
I did search SO for existing answers and found this, but it's an answer from 3.5 years ago and mentions some projects that are either dead, hard to integrate/configure/install or still under development.
Some comments mentioned that the overhead for all three methods is likely to be insignificant compared to the time required to run the actual NLP code. This is probably true, but I'm still interested in what the answer is from a more general perspective.
Thanks!
Consider building a java server with existing language independent RPC mecahnism(thirift, ....). And use python as the RPC client to talk with the server. It has loose coupling。
Just curious about speed of Python and Java..
Intuitively, Python should be much slower than java, but I want to know more...Could anybody give me more? or introduce some nice post to read?
The current standard implementation of Python (CPython) is slower than Java because the standard CPython implementation doesn't have a powerful JIT compiler. Yet.
There have been several projects with the aim of producing a faster implement of Python:
Psyco
Unladen Swallow
PyPy
From what I've tried some of these projects can give very good speed ups for specific algorithms, but you still won't get it to run as fast as Java for typical application code. Most of the current effort seems now to be directed towards PyPy.
The lack of a JIT mentioned is one reason, but another reason is that Python is dynamic. Yes, that does make the language slower. You can see for yourself by using Cython.
A function written in Python can often be compiled to C with Cython. It makes it faster. But it get's really fast when you start adding type information to the variables and parameters, as both Cython and the C-compiler can start applying various simple optimizations that you can't do when the types are dynamic.
So one part of the difference is the inherent dynamicism of Python.
On the future: Python 3 has function annotations: http://www.python.org/dev/peps/pep-3107/ I expect that in a couple of years time, the JIT compilers like PyPy and UnladenSwallow will use this information, and you'll see Python being just as fast as Java, and with some careful applying of Cython, even faster. :)
I do not have data points to give, but one interesting aspect is that there are Python implementations on JVM (ditto for many other dynamic/scripting languages) -- JPython and Jython for example. This could allow some Python applications to run at speeds comparable to native Java applications, assuming implementation of Python runtime itself (on JVM) is efficient.
There are many great answers here as to why Java is faster than Python, 2 of the most common answers are that Python is dynamically typed, and that Java has several extremely powerful Just-in Time Compilers (2 Production quality, several experimental and not for general use) in it's arsenal, with only the C# Common Language Runtime capable of matching it. This is true, but even so, there is one last reason as to why Java is still faster, and oddly enough, it has to do with differences in how Java's Interpreter is designed, vs Python's Interpreter.
Right now, this is the source code of the Interpreter in production for the OpenJDK/HotSpot JVM, Java's reference implementation (There is actually another legacy Interpreter in the JVM source code which was the old one written by James Gosling himself way back when Java was first created, but that one is outdated and not compiled into the actual binary unless you compile it from source with special flags for debugging purposes. Interestingly enough, this is the interpreter responsible for earning Java the reputation of being horrendously slow back in those days):
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/interpreter/templateInterpreter.cpp
This, in contrast, is the code segment of the CPython interpreter that executes Python opcode:
https://github.com/python/cpython/blob/master/Python/ceval.c#L1847
Notice something different between the 2?
While CPython has a massive for loop with a switch case for every single opcode possible (This is true for almost every other interpreter out there actually, other than Java), there is not a single loop, if else, or switch case in Java's Interpreter. Why is this?
The answer is that Java's Interpreter is a special type called a Template Interpreter, which to date is the only one of it's kind. Unlike most designs, instead of a switch case to evaluate Java bytecode, Java's Interpreter has a big arraylist of bytecode, mapped to native machine language when the application is started. This way, the Java Interpreter doesn't need to evaluate bytecode at all, it just inserts the bytecode as an array index, loads native machine language, and directly runs it on the CPU. This means Java's "Interpreter" is actually a discount Compiler, since it runs your code directly on the hardware. CPython on the other hand, like many other interpreters today, is a run of the mill bytecode interpreter, which processes python opcode in software. This obviously makes Python slower to run than Java, even without JIT.
As to why Java has such a unique Interpreter design not used anywhere else, it's because it needs to run interpreted code directly with JIT Compiled code seamlessly, and the ingenious design of having the Interpreter contain a table with bytecode->machine language pairs rather that directly execute it in software was the best way to achieve this goal.
I'm making a falling sand game in Java. I want users to be able to write their own engine for the game and I thought a scripting language might work for that. I've tried out a small script with jython and it's many times slower than that java version.
I need a scripting language that has fast loops and/or fast array access since that's what the game will be doing a lot of. Or if you have any suggestions on another way to let users write their own engine for the game.
I'm also not entirely sure this can work (well). If you don't think it can please let me know why and maybe some possible alternatives.
JavaCC
You could write you're own simple game language with JavaCC. This does give's you all the flexibily you possibly want and native Java speed (well that actualy depends on you're implementation). But you need to keep you're syntax simple or else it will take some efford...
Java
Java? Yes Java! Why not let users extend you're game by Java code? In Java 6 there is a Java compiler API:
javax.tools API.
Beanshell vs Rhino
Some performace comparison between BeanShell and the Rhino (Javascript) interpreters (Rhino is the winner):
thoughtworker.in
Pankaj Kumar's Weblog
You might look at BeanShell for this. In my use it's been pretty much as fast as native Java (as that is what it becomes) and is pretty accessible as it is Java, albeit locked around Java 1.4.
RelProxy is Java compiler on the fly and an automatic hot class reloader, pure Java code can be executed like a scripting language.
Because Java is faaast Java is then maybe the fastest scripting language, optionally you can use .class files like a sort of compiled cache to avoid compiling on load.
I start to write a client - server application using .net (C#) for both client and server side.
Unfortunately, my company refuse to pay for Windows licence on server box meaning that I need to rewrite my code in Java, or go to the Mono way.
Is there any good way to translate C# code in Java ? The server application used no .net specific feature, only cross language tools like Spring.net, Hibernate.net and log4net.
Thanks.
I'd suggest building for Mono. You'll run into some gray area, but overall it's great. However, if you want to build for Java, you might check out Grasshopper. It's a commercial product, but it claims to be able to translate CIL (the output of the C# compiler) to Java bytecodes.
Possible solutions aside, direct translations of programs written in one language to a different language is generally considered a Bad Idea™ -- especially if this translation is done in some automated fashion. Even when done by a "real" programmer, translating an application line by line often results in a less than desirable end result because each language has its own idioms, strengths and weaknesses that require things be done in a slightly different way.
As painful as it may be, it's probably in your best interest and those who have to maintain this application to rewrite it in Java if that's what your employer requires.
I only know the other way. Dbo4 is developed in java and the c# version is generated from the java sources automaticaly.
There is no good way. My recommendation is to start over in Java, or like you said use Mono.
Although I think the first mistake was choosing an implementation language without ensuring a suitable deployment environment, there's nothing that can be done about that now. I would think the Mono way would be better. Having to rewrite code would only increase the cost of the project, especially if you already have a good amount of code written in C#. I, personally, try to avoid rewriting code whenever possible.
Java and C# are pretty close in syntax and semantics. The real problem is the little differences. They will bite you when you dont expect it.
Grasshopper is really the best solution at this time, if the licensing works for you (the free version has some significant limitations). Its completely based on the Mono class libs (which are actually pretty good), but runs on top of standard Java VMs. Thats good as the Java VMs are generally a bit faster and more stable than Mono, in my experience. It does have more weaknesses than Mono when it comes to Forms/Graphics related APIs, as much of this hasn't been ported to Java from the Mono VM, however.
In the cases were it works, it can be wonderful, though. The performance is sometimes even better than when running the same code on MS's VM on Windows. :)
I would say from a maintance stand point rewrite the code. It's going to bring the initial cost of the projet up but would be less labor intensive later for whoever is looking at the code. Like previous posters stated anything automated like this can't do as good as a job as a "real" programmer and doing line by line converting won't help much either. You don't want to produce code later on that works but is hell to maintain.