I was wondering which of the two possibilities is preferred. In my opinion they do more or less the same.
What are the reasons why there are two implementation?
Are there differences in the performance or functionality?
Use scala.Byte in most cases, because it corresponds to both byte and java.lang.Byte in Java terms and you usually want byte. The compiler will use byte for scala.Byte where it's possible/makes sense.
In my opinion they do more or less the same.
It's quite the same. Scala compiler compiles to Java bytecode, just like the Java compiler also compiles to JVM bytecode. A scala.Byte will therefore result in the same bytecode as the usage of java.lang.Byte.
What are the reasons why there are two implementation?
"Scala runs on the JVM, so Java and Scala stacks can be freely mixed for totally seamless integration." This is how Scala is described on https://www.scala-lang.org/. So there are not really two implementations within Scala. You are just provided with the ability to use things from Java if you like / have to.
Are there differences in the performance or functionality
As mentioned above, you can consider them on byte code level as equal. However, they are at least diffrent in usage. If you write your Scala code like you would in Java, you can expect the same performance.
Which one is recomended to use?
If you can, use the Scala implementation. Simply because you'll not leave the "Scala world" and therefore benefit from potential improvements made by the language.
Related
I am working on a small project using SpringBoot to retrieve data from Kafka and pass it to third party supplier. My project is not dependent upon our other micro-services.
I am wondering if there would be any performance improvement if refactored to Kotlin or if it is purely for readability?
Compilation of Kotlin seems slower: https://medium.com/keepsafe-engineering/kotlin-vs-java-compilation-speed-e6c174b39b5d
Other than that it is bytecode in both places. So the only difference is if there are faster implementations of functions in Kotlin. (probably not).
However if you can make more readable code (subjective) in Kotlin, then you have a higher chance of finding places to optimize.
TLDR: do not port language for performance reasons in the language alone.
Java is closer to the way JVM works than Kotlin (methods can't look like field accesses, you can better see where primitives are used compared to classes, etc.). Any performance differences when trying to write equivalent code (i.e. without algorithmic improvements) are likely to be the other way around. But they are also likely to be trivial, especially when considered as a part of the complete application.
I have parser written in Scala due to implementation simplicity.
I need to call it from my java application. I know I need to include scala library in the classpath, etc.
But what about performance? Could it be any strong performance decreases comparing the pure java parser calls?
Calling Scala from Java isn't going to incur any overhead: it's all just bytecode when it executes. It's not as if you were having to travel through some kind of bridge between Java and Scala, as you might if you were calling from Java into, I don't know, Python.
Whether the Scala implementation of this particular algorithm is going to run faster or slower will depend on the nature of the algorithm and the way you'd implement it. Given that you're not going to implement it the same way in the two languages, it's very hard to predict.
In theory there should not be any impact, as Scala uses the same JVM and bytecode as Java and all performance test I've seen give roughly the same speed to both languages.
That is, it should be the same (performance wise) to calling a Java library, or so similar that the difference shouldn't matter.
So, I have a couple of questions about scala.
1) Would writing a new project in scala be speedier (in terms of performance) or should I just stick to regular java? The project that I am going to inherit is already written in java, but it can be massively parallelized. Also, this project is for academic purposes, so I'm a little worried that it's not such a good idea. I know I'd have to run it by my supervisor first, but it's just a thought.
2) Just to be sure, I can compile my scala code on my computer and execute the "binaries" (compiled byte code) on a cluster that has the JVM installed?
3) If I were to compile the inherited java program, should it work? And should it be faster?
(The cluster uses SGE)
This depends entirely on how much work you want to put into parallelizing your code (and how parallelizable the algorithms are). Scala makes it easier, but it does just run on the JVM, and Java can employ every threading trick known to the compiler. So if you want to put the effort into the Java, it will be at least as fast as Scala. (Then again, if you write your Scala like Java, there are very few instances where Java will be faster, so basically it's a tie.)
Yes, as long as you supply the scala-library.jar file (and any others that are needed e.g. if you use Swing, which would be a strange thing to do on a massively parallelized system).
Compiling java bytecode almost never is faster than running the bytecode on the JVM. The JVM is more clever than most static compilers.
You didn't ask, but Scala doesn't have built-in support for the Sun Grid Engine. You could potentially set up something with remote actors, for example, but you'd have significant work to do there.
1) No, you won't get superior performance. Your speed as a programmer will be superior, once you get over the learning curve, but this doesn't seem to be your question.
It might be easier to parallelize by using Scala actors & futures or upcoming 2.9's parallel collections. Also, if the code is heavy on generics but has frequent use of boxed primitives, then Scala's specialization feature is much easier than doing the equivalent by hand in Java.
On the other hand, there's Akka actors and futures that are arguably superior and can be used fine from Java, and Java's own parallel stuff isn't bad.
2) Yes.
3) Err, what?
What the performance of Groovy compared with Java?
It's obviously true that Groovy is compiled to JVM. This however has little to do with the performance.
The most important thing to note here is that Groovy is a dynamic language. This essentially means that most of the time Groovy compiler will have little to no knowledge about the type of an object it is calling a method on / retrieving a property from. This has a huge impact on the performance. There might be thousands of different classes implementing someFancyMethodName() not having a common base class. Yet a call to obj.someFancyMethodName() has to choose the right one. There isn't any better way of doing this than deciding it at runtime based on some kind of reflection. In fact, because of this every single call to a method gets dispatched through a call to invokeMethod() on the object metaclass. This is very much visible in stacktraces if your program ever throws some nasty exceptions. It's even worse. Any class in groovy may choose to provide implementations of methods of the given name dynamically, that is producing them at runtime. There is a fair amount of Grails magic that makes a heavy use of it. Another complication emerges when method overloading comes into play. As the knowledge of types is so limited, it's impossible to choose the right version of the method at compile time. The produced code has to look into the supplied objects and then by making a series of if-elses choose the implementation that best fits the provided call. This most of the time is a really non-trivial process, that was never intended to be performed at runtime. Yet, Groovy has to do it, in order to stay inter-operable with Java.
All that makes Groovy pretty slow. In fact much slower and, what is more painful, more memory consuming than most of the dynamic languages out there (Python for instance).
That said, I agree that the reason for using Groovy is certainly not performance. Most of the time, you will end up optimizing only a small fraction of your code. If performance is such an issue, you can always resort to rewriting those specific pieces in pure Java or give a try to Groovy++. Haven't tried it myself, however the results that I read about online seemed pretty promising.
Groovy 2.0 I have no experience in running the newer version. Quite frankly, I'm not an active Groovy user anymore. I would however expect that most of the issues described above, are fundamentally hard and require a major scientific breakthrough. I have some experience developing HHVM (a PHP virtual machine created by Facebook) and there are much simpler features that performed poorly.
So here we are in 2012 and Groovy 2.0 is ready to rock...
"With the #CompileStatic, the performance of Groovy is about 1-2 times slower than Java, and without Groovy, it's about 3-5 times slower. (...) This means to me that Groovy is ready for applications where performance has to be somewhat comparable to Java."
Performance Test: Groovy 2.0 vs. Java
http://java.dzone.com/articles/groovy-20-performance-compared
And besides the autor, I've used Groovy since 2008 with great success, not only for CV, just to make job done in time business need. Performance is ever relative to what you want to do.
For those who are complaining about numeric use cases, here goes a real use case using web frameworks: http://www.jtict.com/blog/rails-wicket-grails-play-lift-jsp/
"Groovy 1.8.x prototype for fib(42) takes about 3.8s (only 12% slower than Java, over a hundred times faster than Groovy 1.0) So we may no longer encourage people to write such 'hot spots' in Java."
Source: http://www.wiki.jvmlangsummit.com/images/0/04/Theodorou-Faster-Groovy-1.8.pdf
"I'm impressed on how much Groovy's performance has improved for numerical computing. Groovy 1.8 in my project jlab (http://code.google.com/p/jlabgroovy/) sometimes outperforms Scala's performance in my other project ScalaLab (http://code.google.com/p/scalalab) !!"
Source: http://groovy.329449.n5.nabble.com/Great-improvements-in-Groovy-s-performance-for-numerical-computing-td4334768.html
Groovy offers a lot more syntactic sugar over Java, but still runs on the JVM and therefore requires a bit more work by the JVM to provide that sugar. Nevertheless, the difference is extremely minor in the vast majority of normal usages.
In addition, if you do happen to write a function that runs too slowly in Groovy, you can write it in straight Java and call it from your Groovy code. That's the team's recommended solution, and I can vouch for it working well and simply.
It my opinion, for the programming most of us do, it's a non-issue.
A quick Google search yielded some old performance results (http://www.codecommit.com/blog/java/groovys-performance-is-not-subjective, http://www.christianschenk.org/blog/performance-comparison-between-groovy-and-java/).
Groovy++ looks interesting also (http://stronglytypedblog.blogspot.com/2010/02/java-vs-scala-vs-groovy-vs-groovy.html).
However, the reason to use Groovy should be because it improves your performance not the computers...
I think , you have to look at this scientific comparison of Groovy Vs Python Vs PHP vs Ruby.
http://blog.websitesframeworks.com/2013/11/comparison-of-programming-languages-ruby-groovy-python-and-php-353/
They have made one exercise and produce comparison on these programming languages on the below factors:
Comparison of time developing each exercise
Comparison of readability of the languages
Comparison of results in benchmarks and lines of code. From the project Computer Language Benchmarks Game
Conclusions
It is a great quick study to enable you which language is better.
Generally speaking, Groovy will be slower.
You can avoid that by switching to Groovy++ which offers most of the features of Groovy, but can be statically compiled and has performance comparable to Java.
While developing AWS Lambdas Java will be faster than groovy. Apart from that in all other scenarios you might not feel much difference.
Groovy is compiled to bytecode .class files but running Groovy classes requires ~5MB groovy library that make performance overhead.
After reading some OpenJDK mailinglist entries, it seems that the Oracle developers are currently further removing things from the closure proposal, because earlier design mistakes in the Java language complicate the introduction of the Java closures.
Considering that Scala closures are much more powerful than the closures planned for Java 8, I wonder if it will be possible to e. g. call a Java method taking a closure from Scala, defining a closure in Java and giving it to a Scala function etc.?
So will Java closures be represented like their Scala counterparts in bytecode or differently?
Will it be possible to close the gap of functionality between Java/Scala closures?
I think it's more complicated than assuming there's two groups of stakeholders here. The Project Lambda people seem to be working mostly independently of the Oracle people, occasionally throwing something over the wall that the Project Lambda people find out indirectly. (Scala, is of course the third stakeholder.)
Since the latest Project Lambda proposal is to eliminate function types all together, and just create some sort of fancy inference for implementing interfaces that have a single astract method (SAM types), I foresee the following:
Calling Scala code that requires a Scala closure will depend entirely on the implementation of the Function* traits (and the implementation of traits in general) -- whether it appears to the Java compiler as a SAM (which it is in Scala-land) or whether the non-abstract methods also appear abstract to the JVM. (I would think they currently do look like they're abstract since traits are implemented as interfaces, but I'm know almost nothing about Scala's implementation. This could be a big hurdle to interperability.)
Complications with Java generics (in particular how to expressInt/int/Integer, or Unit/Nothing/void in a generic interface) may also complicate things.
Using Scala functions to implement Java SAMs will not be any different than it now -- you need to create an implicit conversion for the specific interface you wish to implement.
If the JVM gets function types (and Oracle seems not to have eliminated that possibility), it may depend how it's implemented. If they're first class objects implementing a particular interface, then all that Scala needs to do to be compatible is make Function* implement the new interface. If a new kind of type is implemented in the JVM entirely, then this could be difficult -- the Scala developers may wrap them using magic like they currently do for Arrays, or they may create create implicit conversions. (A new language concept seems a bit far-fetched.)
I hope that one of the results of all of this discussion is that all of the various JVM languages will agree on some standard way to represent closures -- so that Scala, Groovy, JRuby, etc... can all pass closures back and forth with a minimum of hassle.
What's more interesting to me is the proposals for virtual extension methods that will allow the Java Collections API to use lambdas. Depending on how these are implemented, they may greatly simplify some of the binary compatibility problems that we've had to deal with when changing Scala code, and they may help to more easily and efficiently implement traits.
I hope that some of the Scala developers are getting involved and offering their input, but I haven't actually seen any discussion of Scala on the Project Lambda lists, nor any participants who jump out to me as being Scala developers.
You would likely be able to do this extremely easily using implicit conversions a la collection.JavaConversions whether or not they come out of the box.
Of course, this is not obviously so, because it may be the case that Java closures are turned into types which get generated by the JVM at runtime - I seem to recall a Neal Gafter presentation saying something along these lines
Note: 5 years later, SCALA 2.12.0-M3 (Oct. 2015) did include this enhancement:
Scala 2.12 emits closures in the same style as Java 8.
For each lambda the compiler generates a method containing the lambda body.
At runtime, this method is passed as an argument to the LambdaMetaFactory provided by the JDK, which creates a closure object.
Compared to Scala 2.11, the new scheme has the advantage that the compiler does not generate an anonymous class for each lambda anymore. This leads to significantly smaller JAR files.