Learning Java

[loftar]

people usually saying something should be coded in C if you want it truly fast.

It should be kept in mind, though, that the main reason people say that is because Java has an unfair reputation of being slow. I think the main source of that reputation is purely historical, since Java was slow in the beginning (before it even had a JIT). I take every chance I get to try and correct that. :)

That's not to say that there isn't any point in saying that C is faster, though. While I'd argue it isn't true per se, it is true that the performance of a C program is easier to analyze than that of a Java program. In C, one can know almost for certain even what exact instructions the compiler is going to emit for every piece of code, while in Java, there's a lot of uncertainty. Will the compiler inline this particular method? How fast are the java.util collections in absolute terms? Can I count on this object being stack-allocated? And, not least, how will this scale on other JVMs than Sun's? Can I even count on them having a generational GC? (Dalvik, for example, apparently hasn't. :O)

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.

That's extremely interesting. I had no idea that Pypy had a Jit.

While interesting, though, looking at those comparison charts does verify my suspicion that no dramatic speed gains are to be had. While a few examples (like Django) are impressively much faster, most of the examples aren't even twice as fast as CPython, and even those that are much faster aren't fast enough to offset Python's slowness to begin with.

To be honest, I'm not placing any bets at all in Python being even possible to compile to fast enough code to ever be a reasonable alternative to C, Java or Lisp -- except, possibly, in some very advanced global optimizer like Stalin. Such global optimizers do have the particular problem of removing the ability to load code dynamically at run-time, however. Without a proper type system, type declarations or static structure information about objects, I don't really see how Python could be reasonably optimizable. If anyone does succeed, I'd be extremely interested in knowing how they did it.

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.

I must admit that I don't really see how you could claim this. In any program that is mainly CPU-bound, Python is always really slow, and while I haven't made any actual quantitative comparison, I would be surprised if the difference wasn't on the order of hundreds of times. The only way I could defend writing a program in Python where performance actually matters, is if I knew that it will be mainly I/O-bound anyway.

[Mqrius]

That's extremely interesting. I had no idea that Pypy had a Jit.

Actually psyco was a sort of JIT for python already, although the JITs are based on different methods. This link seems to have a nice basic rundown of the concepts of pypy.

While interesting, though, looking at those comparison charts does verify my suspicion that no dramatic speed gains are to be had.
...
The only way I could defend writing a program in Python where performance actually matters, is if I knew that it will be mainly I/O-bound anyway.

But I strongly applaud these projects that speed up python, so its use can be justified across a wider range of applications. Coding in python is nice

Without a proper type system, type declarations or static structure information about objects, I don't really see how Python could be reasonably optimizable. If anyone does succeed, I'd be extremely interested in knowing how they did it.

Actually, if I understand the previous link correctly, the code is first interpreted to RPython, which is actually semi-typed, which is then JIT-compiled into native code. (I'm not sure if what I'm saying is fully correct, so check the links for more info)

To be honest I don't quite know what the gap between PyPy and C code speed is at the moment. It's compared to CPython, but I can't find any good comparisons between CPython and C.

[Granger]

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.

So you know that sqlite is bad with concurrency and you use it in an environment containing it.

Bottom line of this: You are using it wrong.

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.

I think that x is y% faster/slower than z claims without the exact circumstances of the situation are a waste of oxygen.
If you want to know why then dig through this: http://shootout.alioth.debian.org/

In case you see that something you do with a computer is to slow - you're simply doing it wrong by
either using a language/tool in an inefficient way (eg. crappy code, using unperformant features for the problem at hand, etc.),
or using the wrong language/tool at all (since it's not fit for the purpose at hand),
or you're doing to much to early (meaning: your hardware isn't big enough).

This is nothing personal, just stating the fact.

Pick the right tool, use it in a smart way.
Don't feel bad when it dosn't turn out perfect, just do it better next time since you have learned.

I am no friend of PC, insult wasn't and isn't intended - but in case feel a need to be personally offended by this: be my guest.

Enough derailing for now. Java has it's merits, but i too think that python is nicer since you can keep it inside your head.

PS: i think this covers Loftars comment 2 posts back too.

[Mqrius]

So you know that sqlite is bad with concurrency and you use it in an environment containing it.

When I started the project, I did not have a frontend like I have now. It was just me, putting maps in a database, and running a tool to generate a picture from the database. Single user, simple proof of concept. Perfect for sqlite. Now the project has grown, and sqlite is not suitable for the job anymore.

Bottom line of this: You are using it wrong.

I am aware of this, and stated this in the first post I mentioned sqlite. I don't need you to repeat my words to me.
Besides that, I have not blamed any performance issue on sqlite whatsoever. The performance of python I was talking about was completely unrelated to sqlite.

I think that x is y% faster/slower than z claims without the exact circumstances of the situation are a waste of oxygen.

Why do you need to put it like that? Saying "are a waste of oxygen" is an implicit insult, whether intended or not. You could have said something akin to "I think speed comparisons are highly dependent on the circumstances, and should not be taken for granted."
I think having a discussion where the other party is constantly insulting me is a waste of my efforts.

In case you see that something you do with a computer is too slow - you're simply doing it wrong by
either using a language/tool in an inefficient way (eg. crappy code, using unperformant features for the problem at hand, etc.),
or using the wrong language/tool at all (since it's not fit for the purpose at hand),
or you're doing too much to early (meaning: your hardware isn't big enough).

Pick the right tool, use it in a smart way.

My first comment was "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."
If I interpret your comments correctly, you would say that if performance was an issue, python should not be used at all, since it's not fit for the purpose at hand. There is some merit in this, and if this is your opinion, then I agree, and my first comment could be more carefully worded as "I love python, because it feels easy and natural. However, I wish it was faster so I could use it in more situations, like (semi)performance-critical applications."
One of your earlier comments, however, stated

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.

This only references to the first way of "doing it wrong ~ by Granger"; "using a language/tool in an inefficient way", which automatically implies "crappy code", according to you.
My point here is: First you implied that the single possible reason my code took long, was because my code was crappy. This is insulting. If you had argued that perhaps I was using the wrong language for the job, then I would not have taken offence at that, in fact, I might agree with you.

insult wasn't and isn't intended - but in case feel a need to be personally offended by this: be my guest.

If no insult is intended, then why do you write it as such? Discussion is perfectly possible from a position of mutual respect. Also, if you want to have a fruitful discussion, perhaps you should not constantly state your opinion as fact, and lecture people about it.

This is nothing personal, just stating the fact.

...

To actually assess one of your points: I agree that the right language for the job is very job-specific, and not only dependent on speed. However, I do think speed comparisons have merit, if only to be able to tell which language could be suitable for a project. The perfect language doesn't exist; it's always balancing pros and cons. Do you want a fast algorithm that takes a lot of effort to get working correctly? Or do you prefer the other way around? Speed comparisons help in this case, as long as they are not taken to be an absolute truth.


As a closing note: I do not think we can have a fruitful discussion. From my side, the high horse comment still seems to accurately describe your tone, even after I commented on this. From your side, perhaps, I am too easily offended by your discussion style, but I'll leave the interpretation up to you.

For these reasons, I shall cease all communication with you from now onward. Thank you, and goodbye.

[Granger]

Maybe it's for one that i'm german, and we folks tend to butcher english from time to time i a way that seems to be unpolite to other people. And when it comes to coding i act more nerd like, so don't try to read something between the lines which isn't there.

Maybe we have a better start in the next incarnation, or you find the following useful and more fruitful:

When I started the project, I did not have a frontend like I have now. It was just me, putting maps in a database, and running a tool to generate a picture from the database. Single user, simple proof of concept. Perfect for sqlite. Now the project has grown, and sqlite is not suitable for the job anymore.

A port to mysql or postgres (which should be straightforward ) should do the trick then.

[...]I have not blamed any performance issue on sqlite whatsoever. The performance of python I was talking about was completely unrelated to sqlite.

Then i must have mixed this up together. To me it read as related (sqlite concurrency lag being example of python being slow). Sorry for that.

My first comment was "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."

My point was to not use it in that circumstances (eg. shell a subcommand, port to C .dll, inline assembler, whatever instead).

If I interpret your comments correctly, you would say that if performance was an issue, python should not be used at all, since it's not fit for the purpose at hand. There is some merit in this, and if this is your opinion, then I agree, and my first comment could be more carefully worded as "I love python, because it feels easy and natural. However, I wish it was faster so I could use it in more situations, like (semi)performance-critical applications."

Given what the guys at CCP (EVE online) pull off using python (on server cluster and in client) i think it is performant enough to do most tricks.
You just have to avoid the pitfalls.

One of your earlier comments, however, stated

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.

This only references to the first way of "doing it wrong ~ by Granger"; "using a language/tool in an inefficient way", which automatically implies "crappy code", according to you.

Can be (as you stated yourself that you rewrote some piece of code and gained an order of magnitude in performance) but this also refers to the second part "using the wrong language/tool at all (since it's not fit for the purpose at hand)".

This does not mean that python is crap, neither that you're an idiot.
Python is just not that good when you do large amounts of low-level manipulations (this is why quite some python packages - eg. PIL - rely on binary extensions to do the heavy lifting) the wrong way (since you then spend most time in the OO abstraction layer instead on the stuff you really want to do).
Typical case is f.ex. using dicts to do lookups into a x/y grid: you get a speed penalty that is really ugly.

Take a look at http://cython.org/, Weave, Pyrex and cyptes which can be useful when having to deal with manipulation of binary data structures.

My point here is: First you implied that the single possible reason my code took long, was because my code was crappy.

My statement was:

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

Should you know about the amount of that kind of my own code i ctrl-A+DEL'ed in my life so far you could laught with me about that statement.

To actually assess one of your points: I agree that the right language for the job is very job-specific, and not only dependent on speed. However, I do think speed comparisons have merit, if only to be able to tell which language could be suitable for a project. The perfect language doesn't exist; it's always balancing pros and cons. Do you want a fast algorithm that takes a lot of effort to get working correctly? Or do you prefer the other way around? Speed comparisons help in this case, as long as they are not taken to be an absolute truth.

I can completely agree with this, as long as i can look into the sources for the test run in the comparisons to see how they did what.

Have a good day.

[notalbanian]

Let's talk about Java's memory efficiency.

[loftar]

In case you see that something you do with a computer is to slow - you're simply doing it wrong by
either using a language/tool in an inefficient way (eg. crappy code, using unperformant features for the problem at hand, etc.),
or using the wrong language/tool at all (since it's not fit for the purpose at hand),
or you're doing to much to early (meaning: your hardware isn't big enough).

I think this does not conflict at all with what I said. Since all (current and, I believe, future) Python implementations are slow, they are the wrong tool to use in such situations where CPU performance is important. I don't think you could argue that it would be reasonable for me to have written, for instance, the Haven server in Python, no matter how lean a Python coder I were -- all Python implementations are too slow for it to be possible.

Let's talk about Java's memory efficiency.
[Image displaying java using 16 exabytes virtual memory]

I'm sorry if I sound rude, but if you have no idea what you're talking about, you should consider abstaining therefrom. That's virtual memory that Java uses, which has no bearing, whatsoever, on its actual memory footprint on the system; it's just a programming technique. The JVM simply allocates a 44-bit block of address space with lazily allocated pages for its heap space. That doesn't mean it's actually using that much in any meaningful way. If you look at the "real memory" column, you see it actually using 308 MB, which reflects the amount of physical pages actually having been allocated to the process.

[Mqrius]

Let's talk about Java's memory efficiency.
[Image displaying java using 16 exabytes virtual memory]

I'm sorry if I sound rude, but if you have no idea what you're talking about, you should consider abstaining therefrom. That's virtual memory that Java uses, which has no bearing, whatsoever, on its actual memory footprint on the system; it's just a programming technique. The JVM simply allocates a 44-bit block of address space with lazily allocated pages for its heap space. That doesn't mean it's actually using that much in any meaningful way. If you look at the "real memory" column, you see it actually using 308 MB, which reflects the amount of physical pages actually having been allocated to the process.

I think that picture was meant as a joke, though. tbh, it does look funny when java is allocating 17 TB of virtual memory (albeit lazily and unused.)

[Granger]

I think this does not conflict at all with what I said. Since all (current and, I believe, future) Python implementations are slow, they are the wrong tool to use in such situations where CPU performance is important.

That's why you should offload CPU intensive low-level data shoveling into compiled <somethings>.

I don't think you could argue that it would be reasonable for me to have written, for instance, the Haven server in Python, no matter how lean a Python coder I were -- all Python implementations are too slow for it to be possible.

Yes, i think python - even being slower compared to other languages - can be an excellent foundation for an MMO server.
The benefits it brings when having to deal with a complex system like such a server can surely tip the scale in pythons favour.

That's why i named CCP, they manage to pull that off (using stackless python, maybe take a peek at it, it's fun), having >40k concurrent users in their shardless world and >2k users on a single node (= one single CPU core).

An MMO server is about managing I/O and object state of the game world in a timely, deterministic and concurrent manner, this imho eats more into RAM and storage/network IOPS than into CPU cycles (given that you don't run a sophisticated neural network for each and every MOB, but even that would be manageable - see below).

Stackless seems to be favourable for this since you can have several hundred thousand microthreads concurrently, and since it is cooperative microthreading (with the ability to kill off a tasklet stuck in an endless loop in a defined manner) you're able to build a deterministic (and lockfree, which in itself saves on CPU cycles big time) system with it.

Using a relatively small glue library you can easily code all your I/O in a blocking manner (since only the one tasklet gets blocked by I/O, not your complete thread) , so you code stays small, clean and straightforward.

And in case one tasklet dies for some reason you can setup an exception handler which dumps you the tasklet including all info needed to debug it (stacktrace including all related objects) while all others keep running.

Also the ability to pickle tasklets enables you to move them to other processes (even on other machines) in a quite straightforward way, so with some planning at the start you're able to break up your world into server nodes on demand, which hand over objects traversing their borders in a transparent way. So you end your limitation on one physical machine having to deal with the complete world and gives you the ability to simply add more hardware in case your world gets crowded.

Other fun stuff is the possibility to eg. just send the current state (incl. a random seed) of a MOB statemachine to a client and run the cosmetic parts of the mob simulation there (like moving around idly), only having to sync it in case the server decides that the MOB will do something special now (like reacting to something the client itself dosn't know) - drastically reduce traffic when eg. being near an animal heard. You could even use this mechanic to split the MOB server part of a node away into another server (or several of them) to get the horsepower needed to run sophisticated simulations of critter behaviour.

Add livecoding to the mix and you can update parts of the code (eg. tweak game rules, fix bugs, or even add completely new behaviours) while server is up and running .

Surely you can archive all these features using other means as long as the language of your choice is turing complete, but why not use the stuff which is already there?