JIT compiler/VM discussion [split]

[argv]

A JIT compiler for ZScript?? Jeez. If you're going to go to that much trouble, wouldn't it be easier to just embed an already-made JIT-compiled scripting VM (HotSpot Java, V8 JavaScript/WebAssembly, or the like), and write up code to translate ZScript/ACS/Decorate to run on that VM instead? Graf and Rachael hated the idea, though.

[Rachael]

Graf and Rachael hated the idea, though.

Did you even give the SLIGHTEST consideration as to why?

If you're going to spout off nonsense like this, at least try to ground yourself in the facts before making such statements.

And I doubt it'd be easier even if we wanted it anyway - once it's on the master branch someone has to maintain it...

[Graf Zahl]

Yeah why exactly? Maybe because this just does not work? The only JITable languages I found that were even remotely adequate for embedding and overall structural compatibility were Lua and AngelScript. But Lua is a nightmare in itself and not really compatible with everything and as much as I like AngelScript, it lacked one crucial capability: It was not capable of having script objects inherit from native objects seamlessly, and neither was it capable of having native objects inherit from the base object for scripting and expose the result to the scripting side. This would have necessitated a lot of glue code to make it work and/or a complete transition of most of the game logic to the scripting side, which was out of the question.

Oh, and behold the evil J-word again...

[argv]

Told ya they hated it.

Did you even give the SLIGHTEST consideration as to why?

Of course I did. We had a whole thread about it, where the reasoning against using an existing VM was spelled out quite explicitly. But the reasoning never made sense to me. I decided to leave well enough alone, but now you two have kicked down the door and opened fire just because I posted a minor grumble, so I guess here we go again…

Look, I realize I'm not nearly as good a programmer as you two are—I don't even know how to draw a single triangle in OpenGL, much less write a complete game engine—but I have embedded a JVM for scripting before, it wasn't that bad, and that was without fancy glue-generating tools like SWIG and JNAerator.

And I doubt it'd be easier even if we wanted it anyway - once it's on the master branch someone has to maintain it...

That's bogus. The whole point of using an existing VM and language is that you don't have to write and maintain the damn thing, because someone else (Google, Oracle, whoever) is already doing so.

The only JITable languages I found that were even remotely adequate for embedding

What??? JavaScript and Java were both specifically designed for embedding, in web browsers! Java isn't used that way any more, but the infrastructure for it (JNI) hasn't gone away. JavaScript still is embedded in web browsers, and that remains its main purpose. How on Earth are they not “even remotely adequate for embedding”??

and overall structural compatibility

That's…vague. I remember you saying that you'd have to map a bunch of C++ classes to VM types, but you had to do that anyway. gzdoom.pk3/zscript contains a full declaration of every single type, method, and field that the engine exposes.

as much as I like AngelScript, it lacked one crucial capability: It was not capable of having script objects inherit from native objects seamlessly, and neither was it capable of having native objects inherit from the base object for scripting and expose the result to the scripting side. This would have necessitated a lot of glue code to make it work

So does ZScript! Every single native function in ZScript is exported explicitly with DEFINE_ACTION_FUNCTION, which generates a bunch of VM glue code for it. Every single native field gets a similar treatment from the DEFINE_FIELD family. Every single native method that can be overridden by ZScript code contains an explicit IFVIRTUALPTR check and VMCall. That is not seamless.

Besides, I already told you that tools exist for generating said glue code. Binding native code to VM code—even object-oriented native code—is not some horrible unsolved problem that no one has ever dealt with in a reasonable way before.

And since when was writing glue code (or, if necessary, a generator thereof) anywhere near as hard as writing your own freaking programming language compiler and VM? Maybe I'm missing something, but to me, that's like walking up to a 5° slope, refusing to walk up it because it's just too hard, and taking an alternative route to your destination that involves scaling a mountain!

Oh, and behold the evil J-word again...

Yeah, because HotSpot and V8 are fast, widely used, lots of languages can run on them, lots of development tools exist for them, and they aren't going to have noticeable frame rate drops from a few hundred function calls per frame to draw a tree of GUI widgets.

And no, I didn't recompute their layout for every single frame. It would've been even slower if I did. I've since thought of some optimizations I could've done (limiting the scope of layout invalidations to just a subtree, collecting all widgets in each tree into a single array to avoid recursive calls, and not having a Draw method on layout containers that don't draw anything themselves), but I don't know if that'd be enough.

I want to script an awesome game in an awesome language, and make awesome mods that don't wreck performance. I don't want to write hundreds of lines of code just to read a configuration file. F*** me, right?

[_mental_]

[dpJudas]

Yeah, because HotSpot and V8 are fast, widely used, lots of languages can run on them, lots of development tools exist for them, and they aren't going to have noticeable frame rate drops from a few hundred function calls per frame to draw a tree of GUI widgets.

My government (Denmark) decided back in the day to use Java applets and as a result got the Ask toolbar installed on everyone's computer in the entire country. I will actively use every influence I have on anything to never ever let anything Java close to any product I use. It could be the fastest thing on the entire planet (it is not, not even close) and I STILL would not use it. Seriously, fuck Java. Now owned by ORACLE! Yeah let's use that!!

Now, with Javascript you do have a point. We could probably make bindings that would make such a thing work, but there's one thing you're completely ignoring here: motivation. The asmjit stuff we're playing around with is fun and solving the call overhead isn't as hard a thing as it is made out to be. The true reason why it hasn't been solved already is because nobody is motivated enough to spend the time fixing it.

You also forget that even if we did include v8 for scripting, we would STILL need to keep ZScript around as there's many mods now using it and we actually care enough about the users to not just royally fuck them over by abandoning it.

[Graf Zahl]

Told ya they hated it.

Surely we do not appreciate if some smartass comes along while showing a blatant disregard for why things are the way they are.

Look, I realize I'm not nearly as good a programmer as you two are—I don't even know how to draw a single triangle in OpenGL, much less write a complete game engine—but I have embedded a JVM for scripting before, it wasn't that bad, and that was without fancy glue-generating tools like SWIG and JNAerator.

I concur with dpJudas here. The mere fact that the language is copyrighted by some corporate bully is enough not to use it.

And I doubt it'd be easier even if we wanted it anyway - once it's on the master branch someone has to maintain it...

That's bogus. The whole point of using an existing VM and language is that you don't have to write and maintain the damn thing, because someone else (Google, Oracle, whoever) is already doing so.

You are correct - but what does have to be maintained is all the code that manages the interaction between the external VM and the actual game - and all of those external tools lacked one crucial property: It was simply impossible to maintain a mixed native/scripted class hierarchy.

The only JITable languages I found that were even remotely adequate for embedding

What??? JavaScript and Java were both specifically designed for embedding, in web browsers! Java isn't used that way any more, but the infrastructure for it (JNI) hasn't gone away. JavaScript still is embedded in web browsers, and that remains its main purpose. How on Earth are they not “even remotely adequate for embedding”??

You didn't read the entire thing. "suitable for embedding" also means "plays nicely with how the game engine works", and that's where everything failed. Javascript also failed on language syntax. I have seen professional code that managed to abuse JS's looseness to hell and back, what would you expect would Doom modders do with it? Of all the languages I ever developed with, the only thing coming in behind JS is Lua, but that's more owed to its syntax than its features. In terms of features and how the language deals with them JS is a nightmare come true.

and overall structural compatibility

That's…vague. I remember you saying that you'd have to map a bunch of C++ classes to VM types, but you had to do that anyway. gzdoom.pk3/zscript contains a full declaration of every single type, method, and field that the engine exposes.

No, that's not vague. You cannot shoehorn some VM into a project that cannot deal naturally with the needs of the underlying project. The result will inevitably be a compromise. More importantly here, DECORATE was already using the VM for its parameterized functions. How would you have handled that? That part had to stick around.

as much as I like AngelScript, it lacked one crucial capability: It was not capable of having script objects inherit from native objects seamlessly, and neither was it capable of having native objects inherit from the base object for scripting and expose the result to the scripting side. This would have necessitated a lot of glue code to make it work

So does ZScript! Every single native function in ZScript is exported explicitly with DEFINE_ACTION_FUNCTION, which generates a bunch of VM glue code for it. Every single native field gets a similar treatment from the DEFINE_FIELD family. Every single native method that can be overridden by ZScript code contains an explicit IFVIRTUALPTR check and VMCall. That is not seamless.

What you are talking about are VM internals. This was also mostly code that already existed when ZScript development started. As for the function thunks, of course you need them. The main question is, how hard they are to code.

And since when was writing glue code (or, if necessary, a generator thereof) anywhere near as hard as writing your own freaking programming language compiler and VM? Maybe I'm missing something, but to me, that's like walking up to a 5° slope, refusing to walk up it because it's just too hard, and taking an alternative route to your destination that involves scaling a mountain!

If those externally developed languages cannot properly interface with your code you cannot use them. Simple as that! If the scripting language cannot naturally extend the internal class hierarchy which is the very cornerstone of the engine, you cannot come up with any satisfying results. And please don't point to Eternity. They are dealing with a far simpler base and have no existing mods to care about so they are in a far better position to go with AngelScript and do it right. Of course it remains to be seen if they do it right, it's far too early to tell.

Oh, and behold the evil J-word again...

Yeah, because HotSpot and V8 are fast, widely used, lots of languages can run on them, lots of development tools exist for them, and they aren't going to have noticeable frame rate drops from a few hundred function calls per frame to draw a tree of GUI widgets.

It's very clear that you have no grasp at the real issues at play here.

I want to script an awesome game in an awesome language, and make awesome mods that don't wreck performance. I don't want to write hundreds of lines of code just to read a configuration file. F*** me, right?

Yes, that's what happens if you think you have to code your own parser. It would have been a lot simpler to write a parser class based on sc_man and make a pull request for that. Ironically, nobody who wrote a scripted parser thought of that...

[Rachael]

Graf and dpJudas beat me to the punch on responding, so I am just going to respond to the things they haven't said yet.

Did you even give the SLIGHTEST consideration as to why?

Of course I did. We had a whole thread about it, where the reasoning against using an existing VM was spelled out quite explicitly. But the reasoning never made sense to me. I decided to leave well enough alone, but now you two have kicked down the door and opened fire just because I posted a minor grumble, so I guess here we go again…

The reason doesn't have to make sense for it to be a good reason. And this is where perspective bias kicks in: What makes sense to you might not make sense to someone else - someone who's either in the weeds or looking at the bigger picture. In both perspectives, it's a drastically different view than someone who's just looking at the field from afar.

And I doubt it'd be easier even if we wanted it anyway - once it's on the master branch someone has to maintain it...

That's bogus. The whole point of using an existing VM and language is that you don't have to write and maintain the damn thing, because someone else (Google, Oracle, whoever) is already doing so.

Oh... the ignorance on show here. Yes - you quite do have to maintain it. You have to update it (and lord knows Java has about 50 of those a day, THAT's going to be a nightmare in of itself!) and you have to continually test it and maintain the connections it has in your code. That's not a huge deal if you're Mozilla or Google and have a whole corporation of programmers backing your efforts, but we're just a Robin Hood company of merry men/women here. It doesn't quite work the same.

It gets even more complicated when you have unfinished feature branches which touch the code (and I am sure the 'clientserver' branch could easily have issues with something like this, depending on what code has to be touched by both).

And since when was writing glue code (or, if necessary, a generator thereof) anywhere near as hard as writing your own freaking programming language compiler and VM? Maybe I'm missing something, but to me, that's like walking up to a 5° slope, refusing to walk up it because it's just too hard, and taking an alternative route to your destination that involves scaling a mountain!

Writing JIT isn't that hard. You know how the OS's of old, like CP/M and DOS 1.0 were written primarily in Assembly? It's the same thing here. Ultimately CPU code is just bytes - you string them together and put a function pointer on the string - and bam, you can execute that. No one would be willing to write CPU code by hand or assembly if it were so hard.

Similar to 3D modeling, it's also possible to use "prefabrications" of code, i.e. preconstructed strings, that have already been researched and do a specific thing, in order to make future stringing together and expansion even easier.

Actual compilers, like GCC and Clang, do the exact same thing, anyhow! And SOMEONE had to write them! The biggest difference is, they also have the benefit of having optimiser passes run over the code and remove redundancy so that it executes faster.

That's actually a whole lot easier than sticking someone else's monolith VM inside your code - because you have a higher degree of control, you actually know what it does (no "black box" mystery like a lot of programs with large libraries suffer from), and it's possible to fine tune it and tailor it to your needs without bloating it.

[argv]

Surely we do not appreciate if some smartass comes along while showing a blatant disregard for why things are the way they are.

Whoa, calm down. I briefly grumbled because I disagree with a design decision you made, and I think you have some misconceptions about the VMs I mentioned. I did not make a demand, belittle your work, try to force a discussion, or question the lineage of your firstborn. If you want, I'm willing to have a polite conversation (preferably in a different thread) and tell you what I know, but let's not make a big deal out of this, all right?

[Blue Shadow]

I decided to split this from the original thread as it was off-topic. It's up to my fellow moderators as to whether the topic should stay open or not.

[Rachael]

Whoa, calm down. I briefly grumbled because I disagree with a design decision you made, and I think you have some misconceptions about the VMs I mentioned. I did not make a demand, belittle your work, try to force a discussion, or question the lineage of your firstborn. If you want, I'm willing to have a polite conversation (preferably in a different thread) and tell you what I know, but let's not make a big deal out of this, all right?

If the end result is still having JIT regardless, what's the big deal? Just because we don't like Java and have had terrible experiences with it and same with other major programming languages and VM's does not mean we shun JITs altogether. We just want a light-weight one that we do our own way. The end result is still increased performance regardless - except the download archive is still 8 megs instead of 80 megs. (No I am not exaggerating, I wish I was with that...)

[argv]

If the end result is still having JIT regardless, what's the big deal? Just because we don't like Java and have had terrible experiences with it and same with other major programming languages and VM's does not mean we shun JITs altogether. We just want a light-weight one that we do our own way. The end result is still increased performance regardless

Performance is the biggest deal, so yes, JIT would be quite helpful.

Still, I can think of a bunch of other advantages to using an established language/VM:

• It already exists and works. (That's not to say that integrating it is trivial, mind you, just that the VM itself probably doesn't need debugging. Probably. In theory. )
• Lots of existing libraries: parsers, algorithms…
• Lots of existing tools: build automation, code generators, compilers for other languages, documentation generators…
• Cool language features: generic typing, maps/hash tables, functional programming, namespaces, exceptions…

As for the terrible experiences you've had, at least some of them have been fixed/improved already (Java being huge, JavaScript being loose), some aren't true (Oracle isn't suing anyone for using OpenJDK), and some have never been an issue for bundling the VM with an app (the Ask toolbar and Java update notifier only exist in the commercial consumer JRE, not the commercial JDK, application-bundled JREs, or OpenJDK). It's not fair to shun them for problems they don't actually have.

By the way, you mentioned the need for fine-tuning the VM and tailoring it to GZDoom's needs. Could you expand on that? What sort of tailoring/fine-tuning did you have in mind?

except the download archive is still 8 megs instead of 80 megs. (No I am not exaggerating, I wish I was with that...)

Java 9 added a way to build a stripped-down JRE with only the modules you need (which, in our case, would probably be just java.base). On Linux x86-64 with OpenJDK 10.0.1, that resulted in a zip file size of 15 megs.

Not sure how big V8 is. It's usually statically linked to the application, so I don't have a dll/so to look at. I have a Node.js binary (containing V8 + all the other stuff Node does), which is 6 MB gzipped.

[Rachael]

I think you aren't getting the overall sentiment here: NONE of the developers like Java whatsoever - period!

I don't think I can understand it quite as well as if I had worked with it, myself, commercially - and I am pretty sure both Graf and dpJudas have. I know what little experiences I have with it - I avoid it like the plague, myself. It is a scourge on IT and web development, and it is one that self-perpetuates.

The benefits do not outweigh the downsides of it - and emotion may play a big role in that, but it's an important role none the less.

You can disagree with us all day long about it if you want - but the end result is still a very clear "no". I promise you, we're not going to change our stance on that, no matter how many advantages of it you tell us there are, no matter how good you tell us it is.

And besides - ZScript is already an established language. Even if it's less than 2 years old (not counting the time it existed as a feature branch) - we honest to god don't need JavaGZDoomScript - which seems to be what you're trying to go for, here.

At any rate, even if we did use it, we'd have to research Java opcodes in order to write a ZScript to JRE compiler, and that's no different than researching CPU opcodes anyway, and if you're trying to make it so that closed-source Java is available to modders... oh, that's not something I want at all... we might as well strip the middleman and go for CPU code directly because JRE is going to do that ultimately, anyway.

[dpJudas]

(Oracle isn't suing anyone for using OpenJDK), and some have never been an issue for bundling the VM with an app (the Ask toolbar and Java update notifier only exist in the commercial consumer JRE, not the commercial JDK, application-bundled JREs, or OpenJDK). It's not fair to shun them for problems they don't actually have.

Yes, it is fair. The stewards of Java fucked me over in the past in such a huge way that I will never ever use anything related to them again. It doesn't matter that Oracle has only sued Google, or that they only fuck people unfortunate enough to have to download the JRE. The fact of the matter is that when I download an executable from someone, in this case the SDK for my personal computer, I have to trust people that already fucked me and my family over with the Ask toolbar. So no, no technicalities about them not screwing me over directly in this case is going to convince me to help their market position.

Each time I had to uninstall the Ask toolbar from a relative when fixing their computer it cost them a 1 year penalty. By now they are banned for 20 years+.. There is a reason why the browser vendors effectively removed Java applets from their products.

Not sure how big V8 is. It's usually statically linked to the application, so I don't have a dll/so to look at. I have a Node.js binary (containing V8 + all the other stuff Node does), which is 6 MB gzipped.

Yes, V8 isn't very big. But Graf already reasoned he didn't pick that one due to not wanting the language itself. If you don't want the language in question, it doesn't matter what size the v8 library is.

[Graf Zahl]

Hearing someone who has to work with a server based Java solution on a daily basis constantly curse about the language's deficiencies certainly does not help.
I also blame Java for Android still not being able to displace iOS as the #1 mobile gaming platform (mainly because Google seems to have no interest in a working NDK.)
Last but not least, many years ago I worked on Java Mobile development. Write once, run anywhere? Yeah, good joke. The entire platform was designed by imbeciles which totally forgot to add any hardware query functions to it. And now I should trust the same imbeciles who cooked that up to provide a working solution for embedded scripting? Excuse ma, may I laugh?