I wonder what will give me the best performance
-
There's always assembler if you're really bored. :)
As the aircraft designer said, "Simplicate and add lightness". PartsBin an Electronics Part Organizer - Release Version 1.3.0 JaxCoder.com Latest Article: SimpleWizardUpdate
-
I want to write a medium sized project for Windows and I am considering the following options: A: Write it in JavaFX, which means I will end up with a standard Windows MSI installer that will install a native Windows exe. B: Write it in Kotlin which means I will end up with a Java Jar file that will run under Java on my Windows rig. I am not really interested in C# as I got bored with it. The question is: Which option will perform best speed wise? Any ideas out there?
Ok, I have had my coffee, so you can all come out now!
Others have already done the funny and relevant answers. On the boring side, then: - what makes your app need (more) performance? CPU, GPU, disk IO which of the/any lot? - if you anticipate need for tuning, use a language which has (decent interaction with) a profiler. After all, optimizing software (in any language) usually gives better performance upgrades then the choice of language, extremes excluded.
-
Others have already done the funny and relevant answers. On the boring side, then: - what makes your app need (more) performance? CPU, GPU, disk IO which of the/any lot? - if you anticipate need for tuning, use a language which has (decent interaction with) a profiler. After all, optimizing software (in any language) usually gives better performance upgrades then the choice of language, extremes excluded.
I suppose one of the things I wonder about: I understand that a jar file runs under Java as an interpreted item, not as a native exe. That makes me wonder if the jar file is not going to be significantly slower?
Ok, I have had my coffee, so you can all come out now!
-
I suppose one of the things I wonder about: I understand that a jar file runs under Java as an interpreted item, not as a native exe. That makes me wonder if the jar file is not going to be significantly slower?
Ok, I have had my coffee, so you can all come out now!
-
I suppose one of the things I wonder about: I understand that a jar file runs under Java as an interpreted item, not as a native exe. That makes me wonder if the jar file is not going to be significantly slower?
Ok, I have had my coffee, so you can all come out now!
The last time I checked jar files are compiled into machine executables on the first run, so only the initial run will require the interpreter/compiler and the rest will run at full speed. The biggest question for performance is do your algorithm choices perform well on the hardware, both from a theoretical sense (bubble vs. quicksort) and from a hardware resource sense (huge arrays vs. small data structures).
-
I want to write a medium sized project for Windows and I am considering the following options: A: Write it in JavaFX, which means I will end up with a standard Windows MSI installer that will install a native Windows exe. B: Write it in Kotlin which means I will end up with a Java Jar file that will run under Java on my Windows rig. I am not really interested in C# as I got bored with it. The question is: Which option will perform best speed wise? Any ideas out there?
Ok, I have had my coffee, so you can all come out now!
How do you get bored with a language? I don't care what language I have to use, it's all about solving the users' problems. That said, it sounds like you have the luxury of choice and want to learn new skills? No I guess I'm just jealous. Who's going to have to support this after you? Would JavaFX or Kotlin or other make this better or worse for them?
-
The last time I checked jar files are compiled into machine executables on the first run, so only the initial run will require the interpreter/compiler and the rest will run at full speed. The biggest question for performance is do your algorithm choices perform well on the hardware, both from a theoretical sense (bubble vs. quicksort) and from a hardware resource sense (huge arrays vs. small data structures).
obermd wrote:
I checked jar files are compiled into machine executables on the first run
I don't believe so. First of course it would not do that to a jar file. Classes are loaded from a jar file and then methods are run for that class. Methods might be compiled if the VM deems it is worthwhile. I suspect however that the 'compiled' version might have a different form than if one did the same method in C/C++ and created a binary image from it. For starters I would expect complications for accessing method variables, instance and class variables and method parameters. As an example of that in C/C++ if one attempts to dereference a method variable that is null then the system will throw the exception. However in Java it is going to need to check that so it can throw the appropriate Java exception instead. So it cannot do it as directly as C/C++ code would.
-
I want to write a medium sized project for Windows and I am considering the following options: A: Write it in JavaFX, which means I will end up with a standard Windows MSI installer that will install a native Windows exe. B: Write it in Kotlin which means I will end up with a Java Jar file that will run under Java on my Windows rig. I am not really interested in C# as I got bored with it. The question is: Which option will perform best speed wise? Any ideas out there?
Ok, I have had my coffee, so you can all come out now!
Cp-Coder wrote:
Which option will perform best speed wise? Any ideas out there?
As suggested elsewhere that question is typically meaningless when one looks only at individual technologies. One needs to look at what the application will do and then decide on appropriate technologies (plural) to optimize for the point of the application. Quite possible that speed is not even a consideration depending on what it is doing (not in the context of how fast either might perform based on the application needs.)
-
I suppose one of the things I wonder about: I understand that a jar file runs under Java as an interpreted item, not as a native exe. That makes me wonder if the jar file is not going to be significantly slower?
Ok, I have had my coffee, so you can all come out now!
-
obermd wrote:
I checked jar files are compiled into machine executables on the first run
I don't believe so. First of course it would not do that to a jar file. Classes are loaded from a jar file and then methods are run for that class. Methods might be compiled if the VM deems it is worthwhile. I suspect however that the 'compiled' version might have a different form than if one did the same method in C/C++ and created a binary image from it. For starters I would expect complications for accessing method variables, instance and class variables and method parameters. As an example of that in C/C++ if one attempts to dereference a method variable that is null then the system will throw the exception. However in Java it is going to need to check that so it can throw the appropriate Java exception instead. So it cannot do it as directly as C/C++ code would.
jschell wrote:
obermd wrote:I checked jar files are compiled into machine executables on the first run I don't believe so.
Unless Java has changed a lot the last few years, and I am quite sure it hasn't, you are right. But in the beginning, there was Java bytecode, and bytecode was interpreted directly. Just like the Pascal "P4" bytecode, which is said to be an essential inspiration for Java bytecode. I never heard of any compiler for Pascal P-code; it was always interpreted (as far as I know - correct me if I am wrong). Bytecode is just like any other binary instruction set. 'Compiling' Java bytecode for, say, Aarch64 is functionally identical to compiling x86 binary code into Aarch64 binaries, except that x86 is so messy that it is no simple task :-). When Apple Mac switched from PPC to x64, lots of code was compiled from binary PPC to x64. PPC is far tidier than x86, so I guess that job was simpler. A binary instruction set, whether a 'real' one or bytecode for a virtual machine, usually carry a minimum of 'why-information', limited to 'what-information'. If the compiler could know why so-and-so binary code was generated, it would have greater opportunities to generate more optimal code for the target machine. Or rather: It would be a lot easier. If you compare Java binary bytecode with .net IL (Intermediate Language), IL is not suitable for (or intended for) direct interpretation, but it contains a lot more of 'why-information', making it easier to generate optimal target code. .net IL has always been compiled to native code before execution. When compilation of Java bytecode was introduced, the essential reason was to keep up to speed with .net, which claimed the same 'compile once, execute everywhere'. (For all directly compilation from source code to native code, noone expected interpretation of bytecode to be able to complete.) At about the same time, we also got Java compilers generating native code executables, rather than bytecode, to obtain maximum execution speed, but sacrifying the 'compile once, execute everywhere.
First of course it would not do that to a jar file.
If you refer to the compilation to add to the jar file, you are most certainly correct. The compiler could do like the .net IL compiler: It maintains a persistent cache (in the file system) of compiled assemblies. Before starting compilation of an assembly, the jitter ('Just-In-Time compiler') checks the cache
