Slashdot Mirror

1. The language. Ruby tends to be slower. Something like this programming language shootout will give you details. But this isn't the whole story.

2. Enough rope to hang you. Rails gives you a lot of ways to easily define dynamic classes, where the class is being generated dynamically on the fly. It can make the code lovely and small to use, but can make it slower than hammering it out in a lower level language. This and other techniques can lead to higher memory consumption, too. But I don't fault the language here. I see it as a powerful tool that must be wielded carefully sometimes.

3. Active record. A lot of the slowness that people see can come from automagic that's happening in the background. If you're not careful with active record, for example, it pulls in every last field from table you're looking for, along with the relatives. I just needed the customer's name, and ended up with 8 kilobytes of data because I wasn't careful with what I was doing.

They each have their advantages and disadvantages. According to the great computer language shootout, Java is faster by an order of magnitude, but is more verbose and usually consumes about twice as much memory. The ultimate decision depends (at least) on your application's needs and the capabilities of the environments you're targeting.

Okay, please show me these instances of where the Java version of an app is faster than the C version. That's not a troll: I'd really like to see it. Because I'm now just as tired of the "Java is as Fast or Faster than C Now" myth as I am the "Java is Slow" myth. Time for a reality check: task-for-task, Java is slower than C, period.

Just take a look at some benchmarks. There is only 1 test out of 26 where Java beats C (compiled with either gcc or vc). One!!!

The original Quake2 had a software rendering mode as well as OpenGL. If Jake2 attempted software rendering (does it? I played a Jake2 build from several months ago and I didn't check) I seriously doubt it would come near the performance of the C version.

Does this mean that C is "better" than Java? Certainly not. I am currently writing a JSP/Servlets for a financial web app, and I'd sooner chop off my arms than try to do the same thing in C. However, I am sick of language zealots who try to argue that the [fill in the blank] language is The One True Programming Language. Java is pretty cool but when you try to sell "your" language as all things to all people you're just asking for a backlash.

Ruby is the worst offender -- I'm sure it's great but in 5 years the proponents of [some cleverly named gem or mineral] will try to link Ruby with global warming... you just wait.

That's what happens when you consolidate your energies rather than using a random collection. I'd be interested to know what these other languages were.

"It's much faster to write the application in php, then identify performance issues and code those functions as c++ extentions than it is to write the whole thing in java. This is Radwin's point, and I've seen it proven repeatedly in practice."

There's a problem with that. You now have to have developers know php and c++ which negates one of the benefits of PHP being easier to program. Whereas with Java you're starting off with better speed and if you need to go to native api's you can still do that through JNI and going from java to cpp is a lot easier than going from php to cpp from a coding perspective. (The languages are more alike).

"'Java's as fast as C++'. OMFG. LOL."

Ok, now I know you haven't used java or haven't touched it in years. On the server side JIT compilation really shows it's strengths. And things are going to only get better as cpu's continue to have greater threading capabilities which PHP can't usually take advantage of until more modules are made thread safe. JIT compilers can inline a method increasing performance and use other static calls. Intel worked on features of the P4 and Xeon processors to perform better with code with a lot of branching and inderection. They did this with JVM's in mind. The JIT compiler can reduce the number of branches and it's branch prediction is right most of the time. More than static compilers anyway. Delays on these processors for a correctly predicted branch are down to almost zero clock cycles.

Here are some links in case you don't believe me.

Java Pulling Ahead, Java faster than c++, Computer Language Shootout, http://www.tommti-systems.de/main-Dateien/reviews/ languages/benchmarks.html">This shows them mostly similar, this is an interesting read too

From my limited experience, Fortan is about the best choice you can do for anything between "lightweight" tasks and more advanced tasks, as long as you skip a GUI requirement (even if you could, consider a Python GUI and remain calm).

For more complex matters, Ocaml might be a better choice, as compared to C/C++. Check out a Linux Ocaml shootout here and a Windows Ocaml shootout here. Neither of them were meant to be Ocaml benefactori per se, but it is hard to avoid being impressed (so, I'm a sucker for fast speed, low memory imprint, and few lines of code; but, what do I know...).

Still, none of these sites address Fortran, so the jury still is out there...

In many situations, Java absolutely thrashes VBS/JS/Python/Perl. In other situations, it doesn't. The numbers certainly shouldn't lead you to conclude that Java is the slowest of them all.

sorry sir, I dont buy it, Java is the slowest of them all.

Here is a simple 'hello world' benchmark. Which language can
generate 'hello world' to stdout the fastest way. Java ends up
being second last and with highest memory usage

http://dada.perl.it/shootout/hello.html

How is the test done?
a batch file / shell script is created that calls your program
an x amount of times. The total time taken is then devided by X
to get the average time needed to display 'Hello World'.

Java apologists will say that the problem is with the JVM because
everytime you want to run a program you get the JVM baggage, but
will ignore the fact that other interpreted / emulated / VM like
languages are atleast THREE times as fast (ie: vbscript / jscript
/ python / perl).

--
/apz, if java can not even simply start fast, how can it be speedy?

While Delphi applications may not be quite as fast as C++ apps the performance is certainly better than VB.

According to the Win32 port of the Great Computer Language Shootout, Delphi is faster than C++ for most purposes.

I believe that it has been demonstrated that not all functional languages are slow.

I believe that it has been demonstrated that not all functional languages are slow.

it could be faster and i've read a few articles that show how. Others have done similar testing too I'll be pleased to see java implemented but I still love perl and a bit of gawk. see lots of here language benchmarks - I really like this site.

"Premature optimisation is the root of all evil"
C.A.R. Hoare.

"Programming in C++ is premature optimization."
From comp.lang.python

Things have changed quite a bit, still a bit behind java though (see this more recent shoot out); OTOH I hear a *lot* has happened between 7.4 and 7.6.

The biggest nicety with pike is not the speed though .. it's the way of writing code. It's just lovely.

Thanks for the link. I always like to look at what other people have tried. However, I highly doubt those results. Besides, C++ still came out on top.. eh?

For one thing they don't really test anything useful as the tests are just tight loops of very basic math stuff. His C code doesn't even compile with the VC++ compiler because he's using C99 syntax (Microsoft's compiler is not C99 compliant). And even when I fixed those problems there where a lot of warnings due to questionable variable usage. The C++ version isn't even written in C++, I wonder why there are even two separate files. Not a good start and makes me seriously question this programmers abilities.

Just a quick glance at the code suggests at least the trig benchmarks are more a test of the standard math library rather than the language. C# is going to use the same version as C/C++.

His timing methods are also questionable. Using CPU time can be highly inaccurate. It's much better to use the high precision timing functions.

I will need to take a more detailed look and do some testing of my own to see if these results are valid. Off the top of my head I will say there seems to be something screwy going on because I've never seen properly written code run faster in C#. It's just not possible. C and C++ are so close to the hardware that when written properly it is near impossible to make it faster without going to assembly. The best C# can hope for is something close to C/C++, but never better.

I'll make another post if I get time to take a more detailed look but I'm not optimistic about these tests being worth anything. Try the Language Shootout (or the win32 version) benchmarks for broader benchmarks where a lot of them have actually been looked at by programmers that know what they are doing. If you know what you are doing then you might want to really try them, don't just go by the results on the pages because some of them are skewed because the run times are way too short to be meaningful.

Again, I ask you to design a vector class in C# that uses the same or less memory than C++ and performs the same or better. It's not even close to possible.

I was going by the benchmarks here that someone else linked to. These show Java at around three to ten times slower than C++, using JRE 1.4.1.

Modern JVMs optimise for SSE/MMX. Your point again?

And it probably does about as much as GCC's use of MMX/SSE - not much. You generally have to write the inner loop with the opcodes available in mind to get the most performance.

I have yet to see any of the people here bitching about how he should be optimising for all different operating systems and processors in C

What a pointless comment. The guy wants community participation to run his program. There's little point in him saying "Look at all the processor power this required" if the only reason it took that much is because he wrote the thing in a slow language.

I was going by the benchmarks here that someone else linked to. These show Java at around three to ten times slower than C++, using JRE 1.4.1.

Modern JVMs optimise for SSE/MMX. Your point again?

And it probably does about as much as GCC's use of MMX/SSE - not much. You generally have to write the inner loop with the opcodes available in mind to get the most performance.

I have yet to see any of the people here bitching about how he should be optimising for all different operating systems and processors in C

What a pointless comment. The guy wants community participation to run his program. There's little point in him saying "Look at all the processor power this required" if the only reason it took that much is because he wrote the thing in a slow language.

I was going by the benchmarks here that someone else linked to. These show Java at around three to ten times slower than C++, using JRE 1.4.1.

Modern JVMs optimise for SSE/MMX. Your point again?

And it probably does about as much as GCC's use of MMX/SSE - not much. You generally have to write the inner loop with the opcodes available in mind to get the most performance.

I have yet to see any of the people here bitching about how he should be optimising for all different operating systems and processors in C

What a pointless comment. The guy wants community participation to run his program. There's little point in him saying "Look at all the processor power this required" if the only reason it took that much is because he wrote the thing in a slow language.

The Great Win32 Computer Language Shootout

While Java is not "unacceptably slow" or "1000 times slower" as some claims, it is generally slower than C and much more resource intensive nevertheless.

Actually if one wants to write this kind of math intensive apps, pure Java is really not the best choice. Even pure C isn't. He should think about implementing some of the highly used routines in assembly (no joke). And since photon tracing can be done parallelly, one would find the SSE and 3DNow! families of instructions useful.

And finally, besides the CPU, you can also try to do the calculations in your GPU. You'll need a new-fangled PCI-X card in the future to do the calculations efficiently tho.

Take a look at this site BrookGPU

Actually, there are some very efficient OCaml implementations out there, on par with C. But don't take my word for it...

I had made many TK-perl appz (on win XP) compiled with Visual Studio 7, and everything is running fine on *unix and mac.
(I had less pain in tk-perl then using html+dhtml to be compatible with the above 3 OS.)

Hey and most of it is FREE. - (So stop it blaming on module incompatiblitys)

• www.indigostar.com (perl 2 exe)
• dada.perl.it
• (Each Win32 APIs or third-party or even homegrown DLLs are usable with perl.)
• Oreilly Perl bookshelf
• containing six books.

Komodo activestate.com is in my opinion one of the best editors and debuggers in this world. (Beside the new web package manager is a little bit buggy, but everything else works fine... And be sure to take a look at the great regex evaluator.)

And of course dont miss Larry Wall "O'Reilly Perl Programming" or Programming Ansi C by Brian W.Kernighan and Dennis M.Ritchie

Eighter i think you couldn't be a good unix admin without the knowledge and the module section of pe(A)rl.

This benchmark strongly favours languages compiled to native code. A much better place to seek language comparisions is The Great Language Shootout, even if it hasn't been updated for 2 years or so. (There's a more up-to-date version, albeit Windows-oriented, at The Great Win32 Language Shootout.)

Don't forget about the Win32 Compiler Shootout

on some theoretical JIT, might actually run faster than a snail.

You do know that java is faster than C# for non-GUI apps, right? source. I suspect that if you dump swing and go with the eclipse SWT, you probably equalize the GUI speed issue too, which would mean that on windows platforms Java is faster than C#.

The "java is slow" reputation was earned with java 1.1 and was fixed long ago when the JIT VM's came out (they are part of all modern JVM's). Memory use issues might give you a real issue to knock java on, but you really shouldn't repeat untrue lore.

2. JSRs are talk. C# is a reality.

C# 1.0 is a reality. The posting is about the "design specifications document for C# 2.0". How would you classify that -- "talk or reality". (The correct answer is talk).

On the other hand Java 1.5 is talk that is on the verge of release (weeks or months away), while C# 2.0 is just getting started.

And while, .net is a reality, it isn't a very pretty one. It's about where JDK 1.2 was. Most people don't realize that C# is SLOWER than java on MS platforms, which is fscking SAD, given that java has to be cross platform which costs speed. (source: results from Aldo Calpini's windows port of Doug Bagley's Language shootout).

First of all -- what's the deal with this whole "WARMUPS" thing? This is just the most explicit way possible of training the JIT mechanisms without measuring its overhead. That might be fine if you believe that the overhead asymptotically costs nothing, however, I don't know what evidence there is of this. The test should use other mechanisms other than this explicit mechanism to allow the language itself to demonstrate that the overhead is of low cost.

The way this test is set up, the JIT people could spend hours or days optimizing the code without it showing up in the tests. This is the wrong approach and will do nothing other than to encourage the JIT developers to cheat in a way such as this just to try to win these benchmarks.

Ok as to the specific tests:

1. FloatInteger conversion on x86 are notoriously slow and CPU micro-architecturally dependent. It also depends on your rounding standard -- the C standard dictates a rounding mode that forces the x86s into their slowest mode. However using the new "Prescott New Instructions", Intel has found a way around this issue that should eventually show up in the Intel C/C++ compiler.

This does not demonstrate anything about a language other than to ask the question of whether or not the overhead outside of the fi rises to the level of not overshadowing the slowness of the conversion itself.

(That said, obviously Intel's compiler knows something here that the other guys don't -- notice how it *RAPES* the competition.)

2. Integer to string conversion is just a question of the quality of the library implementation. A naive implement will just use divides in the inner loop, instead of one of the numerous "constant divide" tricks. Also, string to integer will use multiplies and still just be a limited to the quality of implementation as its most major factor determining performance.

3. The Pi calculation via iteration has two integer->floating point conversions and a divide in the inner loop. Again, this will make it limited to CPU speed, not language speed.

4. The Calculation of Pi via recursion is still dominated by the integer divide calculation. It will be CPU limited not language limited.

5. The Sieve of Erastothenes (sp?) is a fair test. However, if SLOTS is initialized to millions, and the comparable C implementation uses true bits, instead of integers, then I think the C implementation should beat the pants off of C#, Java, or anything else.

6. The string concatenation test, of course, is going to severely ding C for its pathetic string library implemenation (strcat, has an implicit strlen calculation in it, thus making it dramatically slower than it needs to be.) Using something like bstrlib would negate the advantage of C#, Java, or any other language.

7. The string comparison with switch is a fair test, and gives each language the opportunity to use whatever high level "insight" that the compiler is capable of delivering on. It should be noted that a sufficiently powerful C compiler should be capable of killing its competition on this test, however, I don't believe any C compiler currently in existence is capable of demonstrating this for this case. I.e., this *could* be a legitimate case to demonstrate that C# or Java's high level abstractions give it an advantage over where the state of the art is in C compilers today.

8. Of course the tokenization is another serious ding on the rather pathetic implementation of the C library. None of strtok, strspn, etc are up to the task of doing serious high performance string tokenization. If you use an alternative library (such as bstrlib or even just PCRE) you would find that C would be impossible to beat.

-----

Ok, while the results here are interesting, I don't think there were enough tests here to truly test the language, especially in more real world (and less laboratory-like) conditions. Please refer to The Great Win32 Computer Language Shootout for a more serious set of tests.

http://www.sound-hack.org

http://stub.org

http://slub.org

http://kanak.perl.it/music/

http://fals.ch