Learning Java

[GreenScape]

in some cases it's hundreds of times slower than even java.

"Even" Java? I thought we were past that.

Java is always slower than c++/c/delphi... because of virtual machine. this is the price for multiplatformness.

[loftar]

Java is always slower than c++/c/delphi... because of virtual machine. this is the price for multiplatformness.

No, that is simply not true. It seems that you do not know it, but the JVM contains a native code compiler, so there isn't anything it cannot do that a C compiler can do. In fact, the opposite is true. The JVM can do really insane optimizations precisely because of its VM nature. Let me throw some facts at you.

Some of the optimizations that it can do, that a C compiler cannot do, stem from the fact that it has complete knowledge of the code it is running; for example, it can know for sure that a certain method is not overridden by any subclass at the moment, and therefore inline it in places where it is called, while a C++ compiler must always assume that a virtual method might be overridden somewhere else (especially in cases where the system is capable of loading code at runtime, such as via a dynamic linker) and therefore cannot inline it (this is the reason why getters and setters in Java often are truly as fast as accessing their corresponding variable directly). There are a whole range of other optimizations that are made possible from this fact, including, but not limited to, always being able to use as many registers as theoretically possible for argument passing at function calls, optimizing away mutex operations that can be guaranteed to be limited to one thread, or stack-allocating objects that never escape the scope of the stack frame in which they are allocated.

Other optimizations that become possible stem from the fact that the compiler really knows what system it runs on. The JVM compiler can, for example, use the full range of SSE4 instructions available on a processor that it happens to run on, or schedule instructions much more precisely, since it can have intimate knowledge of e.g. the superscalar structure, the branch prediction unit or the cache line size of the CPU it's running on, while an ahead-of-time compiler cannot assume intimate knowledge of the CPU, and therefore must use generic instruction scheduling and avoid specialized instructions. Even though GCC and other ahead-of-time compilers are capable of generating code for a specific CPU, that capability can almost never be used outside from-source Linux distributions like Gentoo or Sourcemage.

[GreenScape]

okay, let suppose it is in some cases faster than C(then C++ either), but tell me why do game clients using all 100% of the CPU core time? while modern 3D games, run in window mode using only 60-80? i know many examples java apps is 10x slower than C++ but i don't want to trolling.

[loftar]

but tell me why do game clients using all 100% of the CPU core time? while modern 3D games, run in window mode using only 60-80?

I've stated it elsewhere on the forum a couple of times, but that's mainly because my usage of OpenGL is very suboptimal. The game client doesn't actually use a lot of real CPU time; it spends a lot of time on the graphics card. That's my fault rather than the JVM's, however.

To be honest, though, I'm not really sure why that counts as CPU time; I would think that waiting on the graphics card's command buffer would put the process to sleep. Though I guess it might be that the latency is so short that the driver spinwaits for the buffer to drain.

i know many examples java apps is 10x slower than C++ but i don't want to trolling.

Well, as I wrote in my previous post, Java does make it extremely easy to write slow programs. Common problems include exaggerated usage of java.util collections rather than plain variable or array storage, lacking knowledge of how various library functions scale given certain inputs or usage patterns, or using unnecessary layers of indirection because of the language's lack of metaprogramming features. That's just a few of the many errors people commit, though. The problem is further compounded by the fact that Java is often taught as the first or even only language at many universities these days, so there's an vast host of bad programmers out there writing really awful Java programs. It is yet further compounded by the fact that Java actually does make it easier for those bad programmers to write software that seems to work at all -- while a bad C++ programmer would churn out programs that crash all the time and therefore cannot even be shipped, a bad Java program doesn't crash half as easily, and might thus be shipped despite it sucking beyond everything that is reasonable.

None of those performance problems are inherent to Java, however, and can be avoided by people who know what they're doing; though it is true that Java (the language, not the JVM) makes it far easier to fall prey to them unwittingly than do many other languages.

[GreenScape]

but tell me why do game clients using all 100% of the CPU core time? while modern 3D games, run in window mode using only 60-80?

I've stated it elsewhere on the forum a couple of times, but that's mainly because my usage of OpenGL is very suboptimal. The game client doesn't actually use a lot of real CPU time; it spends a lot of time on the graphics card. That's my fault rather than the JVM's, however.

To be honest, though, I'm not really sure why that counts as CPU time; I would think that waiting on the graphics card's command buffer would put the process to sleep. Though I guess it might be that the latency is so short that the driver spinwaits for the buffer to drain.

i think the problem is in drawing. looks like u render each object separately, and then draw it on the screen using java methods. i think so because if there are a lot of objects around the FPS goes down to 20. i think the correct way is to render whole screen in GL and draw bitmap into the window.

p.s. GL is too fast to slow main loop, especially for 2D graphics!

[Granger]

I love python, because it feels easy and natural. I hate it, because in some cases it's hundreds of times slower than even java.

Then you're using it wrong.

The backend of the world map is written in python, with an sqlite database.

Q.E.D.

It works pretty well, but if the project would be any bigger, it just wouldn't be sufficient. sqlite is very bad with concurrency. Right now, when I'm inserting a new batch into the database, you probably can't view the map for a few seconds.

Now you know why.
You blame python but you get your penalties from a 3rd party library.

And before I recoded the entire matching algorithm, matching large batches could take over half an hour.

See above.

Fucked up code is to blame, not the language you use.

[Mqrius]

I love python, because it feels easy and natural. I hate it, because in some cases it's hundreds of times slower than even java.

Then you're using it wrong.

The backend of the world map is written in python, with an sqlite database.

Q.E.D.

It works pretty well, but if the project would be any bigger, it just wouldn't be sufficient. sqlite is very bad with concurrency. Right now, when I'm inserting a new batch into the database, you probably can't view the map for a few seconds.

Now you know why.
You blame python but you get your penalties from a 3rd party library.

And before I recoded the entire matching algorithm, matching large batches could take over half an hour.

See above.

Fucked up code is to blame, not the language you use.

Now that's a bit shortsighted, as well as a little rude. I am very well aware of what parts of my program have what speed, and I do realise that sqlite is not the proper solution here.
But the database is only accessed at the start and the end of the matching algorithm and in between, the actual python code is what took half an hour, and was still very slow, even when using 'fast' extensions as numpy (which I do).
Of course you could argue that my program could be faster if I use a less simplistic matching algorithm, but the fact remains that the python code would be tens to hundreds of times faster if the same thing was coded in C or java. Please get off your high horse.

in some cases it's hundreds of times slower than even java.

"Even" Java? I thought we were past that.

I haven't actually done any speed tests between C and java myself, and the 'even' stemmed from people usually saying something should be coded in C if you want it truly fast.

I love python, because it feels easy and natural. I hate it, because in some cases it's hundreds of times slower than even java.

I had placed my hope in the Unladen Swallow project, run by Google, that was supposed to up the speed by 5 times.
They never got very far, though, and the results where disappointing.

I'm placing bets on the Pypy project, from the developers of psyco (no longer maintained, sadly), which aims to be faster than C through a JIT compiler of course, as well as some other features I haven't quite taken the time to look into yet. They're doing pretty well, according to their own stats, but not all modules can be used with pypy out of the box yet. Their project is pretty massive though, but I hope they whip it up into a usable shape sometime soon.

[mvgulik]

[peek]

The backend of the world map is written in python, with an sqlite database.

Q.E.D.

To me this looks like your just calling him a liar. Or do you doubt he knows with what code/tools he created the world map.
[/peek]

[Granger]

To me this looks like your just calling him a liar. Or do you doubt he knows with what code/tools he created the world map.

Nope.
His claim is python is slow.
He also stated he uses sqlite which stalls for measureable time when he's doing certain operations.
And using sqlite (which is nice when using it locally to store some data in a single-user environment, or to quickly test some stuff) isn't the product of choice when you want server the data to multiple clients (since you run into the same clusterfuck as with MS Access .MDB).

My point is: in case you manage to use python in a way to have it behave hundreds of times slower than java you simply do something terribly wrong.

Which he stated himself:

And before I recoded the entire matching algorithm, matching large batches could take over half an hour.

That's why i said:

Fucked up code is to blame, not the language you use.

This has nothing to do at all with horses.

[Mqrius]

My point is: in case you manage to use python in a way to have it behave hundreds of times slower than java you simply do something terribly wrong.

The hundreds of times actually came from a different thing I did recently. I was trying to get proper gif palette creation in python (Python Imaging Library sucks), and as such, I ported the java implementation of NeuQuant to python. I did this nearly verbatim, only using numpy arrays instead of python arrays, which should give a decent speed improvement since the arrays can be width*height of image long. However, it was hundreds of times slower than java (java was nearly instant, while in python it took minutes). I then did some work to convert all low level array element messing arounds to list operations from numpy, and this improved it significantly. It's now only tens of times slower than java.

The high horse comment was aimed at your short comments, which looked almost patronizing to me (and still look that way). You comment on my coding thinking you don't need any further info on what I base my claims on, and/or what I tested, or what my algorithm actually does/is.

One example of patronizing:

It works pretty well, but if the project would be any bigger, it just wouldn't be sufficient. sqlite is very bad with concurrency. Right now, when I'm inserting a new batch into the database, you probably can't view the map for a few seconds.

Now you know why.

You say "now you know why" as if you just taught me that sqlite is bad. For one, sqlite is actually very fast. Secondly, I just stated myself that sqlite is bad with concurrency, I'm not unaware of that.


Do you believe that 'the average algorithm' when coded in java or python, will give the same performance?