Author Topic: Simutrans in JAVA? (Read 6582 times)

Spike · « **on:** November 30, 2009, 09:00:12 AM »

Off topic: That's also a reason why I like Java - it's much easier to keep applications "going" there than in C++

This topic was split - the new title says "Simutrans in Java" but I originally only wanted to express my like for the Java language, and not an intention to code Simutrans in Java. While we discuss now if this would be possible, I'm more or less still only defending the Java language from some misunderstanding and prejudice, and have no plans or whatsoever to program Simutrans again in Java.

mip · « **Reply #1 on:** November 30, 2009, 11:10:22 AM »

If we do a Java port someday I'm in again. Working on C++ code isn't that easy anymore when you have Java all day

Spike · « **Reply #2 on:** November 30, 2009, 11:16:57 AM »

I've been dabbling in C for a bit recently, and I just don't want that anymore. Java is so much easier ...

prissi · « **Reply #3 on:** November 30, 2009, 01:24:28 PM »

Well but Simutrans code cannot go to JAVA, as it is more OOP than JAVA allows, like multiple inheritances all over the place and such.

Spike · « **Reply #4 on:** November 30, 2009, 01:29:47 PM »

I know ... just dreaming. And also explaining a bit of my problems to get in touch with C/C++ based project again.

mip · « **Reply #5 on:** November 30, 2009, 01:44:54 PM »

Multiple inheritance is bad

.

Spike · « **Reply #6 on:** November 30, 2009, 03:17:10 PM »

C++ doesn't have interfaces, so you need to use normal inheritance to gain the same effect. And seldom things are just bad or just good - multiple inheritance can be useful but bears dangers and good programmers know when not to use it.

prissi · « **Reply #7 on:** November 30, 2009, 03:22:02 PM »

Why? As used in SImutrans it workes quite nicely.

Like any object can be a ding_t and a steppable_t for animation. Why is this bad? It reduces code like

Code: [Select]

if(  dynamic_cast<factory *>(obj)) {
  factory *fab = dynamic_cast<factory *>(obj);
  if(fab->is_steppable()) {
    fab->sync_step();
  }
else if(  dynamic_cast<vehicle *>(obj)) {
  vehicle *veh =  dynamic_cast<vehicle *>(obj);
  if(veh->is_steppable()) {
    veh->sync_step();
  }
} ...

As with any tools it depends on how you are using it. You can also use electricity for electrocution or defibrillator ...

And I fear the JAVA garbage collector would suck on the several millions of objects on larger maps.

jamespetts · « **Reply #8 on:** November 30, 2009, 03:30:45 PM »

I can't imagine how slow that Simutrans would be in Java...

Spike · « **Reply #9 on:** November 30, 2009, 08:28:47 PM »

Java isn't that slow anymore ... but for Simutrans most likely still to slow. I'd assume a Java based Simutrans reaches about 30% of the performance, but would be much easier to multithread, and that could be a win on new systems.

mip · « **Reply #10 on:** December 01, 2009, 09:36:22 AM »

Sorry, it wasn't intended that you take my statement so serious. Fact is that it has advantages as stated and that it is a chance for severe mistakes if not used carefully. Java avoids it and uses interfaces to get it done.

And yes Java is far better than it was with version 1.3 (this was the version I got in contact with it and it was real slow), but a up to date Java version is not comparable to this. Also the garbage collector is better now than it was before (you can also control its behaviour if you want).

I assume UI and other graphic stuff would be easier and cost less performance than now??

Spike · « **Reply #11 on:** December 01, 2009, 09:48:35 AM »

On Unix (X-Windows), graphical operations in Java seem to be pretty slow. At least I got some feedback about my Java based applications that indicates so. On Windows Java uses the DirectX libraries which are fairly fast.

UI in Java should be much simpler than in current Simutrans (but that is not a fault of C++, but a Problem of the UI implementation in Simutrans, which was not designed for such complex UIs as Simutrans has them now - originally it was only for small windows with a few buttons).

prissi · « **Reply #12 on:** December 01, 2009, 09:58:14 AM »

UI costs very little performance in simutrans and is currently quite flexible. In fact it is a little like the UI in BeOS, one of the very few completely object oriented UIs. In that aspect it is very different from most other UI I know.

A garbage collector is slow. Also it adds quite and overhead. Just imagine a 24 byte structure; the GC needs to add a size field and an access timer. It needs for any acces to record that it is still used. Making it in the best case 34 Bytes. And remember, simutrans uses its own memory management, since even standard malloc was more than 30% slower. I doubt any garbage collector comes close to malloc/free, so I doubt JAVA simutrans will run at more than 10% of its speed.

And how does the GC know about stones in the upper left corner not visited for some years and completely deleted objects? And since the number of objects is not known beforehand, one ends up with the same arrays of objects, only slower and bigger. (Not to mention the route search, which even do not use any allocations at all. I could go on about the route search.

In the end it could be done in JAVA, but for many things similar hacks would be needed (like a fixed size array for goods routing with structs equivalents) if it would end playable.

Spike · « **Reply #13 on:** December 01, 2009, 10:22:55 AM »

This topic was split - the new title says "Simutrans in Java" but I originally only wanted to express my like for the Java language, and not an intention to code Simutrans in Java. While we discuss now if this would be possible, I'm more or less still only defending the Java language from some misunderstanding and prejudice, and have no plans or whatsoever to program Simutrans again in Java.

You can use memory/object pools in Java, too. It need some thought and care by the programmer, but it's not rocket science either. This will make gc much more efficient, and is the Java equivalent to Simutrans' selfmade memory management.

But yes, there is an overhead for gc ... I think 8 to 12 bytes overhead are a reasonable assumption for each object. And it has to check the head for garbage now and then, but it does this very efficiently, and usually in less than a microsecond, unless you have created really lots of garbage. Object reuse and pooling can avoid that.

There are several gc implementations available in Java 6, and one can choose which to use. All are fairly complex, and so I cannot tell in a sentence or two how they work. I can only say they are not so dumb and slow as it seems to be assumed here. I'm working with Java since 12 years now, and I see big improvements in the language. I know it can't challenge C or C++ for the most performance needing and realtime systems, but for the average application Java is really good.

I prefer to code Java these day. I like the language much - not for speed, but for the ease of writing and ease of debugging. I choose and tailor my projects so that they work with Java.

I want to conclude that Simutrans is better done in C++ and shall stay C++. I didn't want to put doubt in there, nor did I want to challenge that. I'm sorry if my writing appeared to say so.

I want to quit this discussion here. I made my choice, others made theirs. We are happy with our choices, and so it's good. No need to be missionary, and make other people feel bad about their choices. I'm sorry that I brought this up.

vilvoh · « **Reply #14 on:** December 01, 2009, 10:36:18 AM »

I'm curious.Java and C++ are more or less similar so making a rough estimate, what percentage of Simutrans code could be port to Java as it is, with their equivalents in Java, and what percentage would need to be hacked or rewritten? 60-40? 70-30? 50-50?

Spike · « **Reply #15 on:** December 01, 2009, 10:54:18 AM »

I heard of tools that help with the process, but I have no experience with those.

I have ported C and C++ code to Java in the past. In case of Simutrans I'd assume more than 70% of all code lines must be adapted, if doing it manually.

Each pointer declaration and each pointer dereference operation must be adapted, that uses to be the biggest work (search-and-replace can help to some extend, but the * symbol is also for multiplications. so search-and-replace only helps so much).

Simutrans uses value objects in places, which Java just doesn't have, and replacements must be found.

As Prissi noted above, Simutrans uses multiple inheritance in a style that Java does not support - only one parent class can be a normal class, all other parents must be pure virtual classes (interfaces in Java). That will require a number of architectural changes.

Java templates are different from C++ templates, but I cannot really estimate the impact.

Simutrans also uses "plain" memory areas, allocated by malloc IIRC. In Java such do not exist, the closest are arrays. Each array access is type and bounds checked, so those are slower than memory accesses and a poor way to emulate plain memory areas - in order to get good performance this requires architectural changes again.

My past experiences with porting foreign C and C++ code (= code that I had not seen before) to Java are saying that it takes fairly long (1-2 hours for about 1000 lines of code, if the code is not black magic code), and usually it ends with poorly performing code. To make it work well, a deeper redesign is needed, which needs even more work, but very often just fortifies the opinion that Java is slow, because suchlike ported code really performs poorly. In Java one would use different designs from start, end up with a different application structure and if done right, and code that can get withing the reach of 50% of C++ performance.

I want to repeat that I do not want to port Simutrans to Java, not even suggest to do so. I just like the Java language and was expressing facts that I particularly like among it. For example the fact that Java programs can be written easier in a manner to avoid fatal crashes, also easer debugged than C++. I did not want to challenge C++ overall, it has it's merits. Java has different benefits, which overall matter more to me, and thus I made Java the language of my choice. Speed of execution was not among those.

prissi · « **Reply #16 on:** December 01, 2009, 01:16:45 PM »

The current implementation is very heavy on multiple inheritances and so. It also uses a lot of pointers as hashes and unions of pointers and arrays so there are changes needed too. Lots of abstract classes and templates.

It can be done, but my feeling is that about 30% of the files need more than just slight changes. But better ask a person better knowing in Java than me.

vilvoh · « **Reply #17 on:** December 01, 2009, 02:45:14 PM »

You tempted us too much so now there's not turning back, Hajo. We demand a java port...

Spike · « **Reply #18 on:** December 01, 2009, 03:09:34 PM »

prissi · « **Reply #19 on:** December 01, 2009, 05:05:58 PM »

Do not tease Hajo, please.

No seriously, if started again, Java might be a good choice. Others than that simutrans working fine now, and it is portable enough, so why should work put be in for almost no gain in the moment?

Spike · « **Reply #20 on:** December 02, 2009, 08:52:21 AM »

Thanks, Prissi! Also, I'll try to avoid bringing up the Java topic anymore. I'm sorry for that.