It'd probably make more sense to write a new compiler, the bytecode the current one outputs is extremely bad
Edit: Well, this OP sounds lame because the thread got split
ID:1254783
 May 3 2013, 3:14 am (Edited on May 3 2013, 4:10 am)
|
|
Other than lack of any optimization system causing hilarity (e.g setting a varaible, then instantly getting it and never using that variable register again), setting a variable then immeditely setting it to something else
Lists are also generally horrible in every way with how they work right now (static lists are created dynamicaly for some reason) | |
These are fairly minor things, as it goes, and would be my second or third thing to go to after "does the DM code it's compiling do anything dumb". To which the answer is almost exclusively "yes".
| |
These are fairly minor things, as it goes, and would be my second or third thing to go to after "does the DM code it's compiling do anything dumb". To which the answer is almost exclusively "yes".
| |
The static list thing is actually a big cause of slowdown since huge lists are sometimes remade for each call, even though they're never changed
I just pulled those things from picking a few random procs on this disassembly and finding bad parts, theres some other seriously bad crap I cant remember right now | |
Probably would do better to raise feature requests for it, if it's trashing performance on your game.
The obvious workaround for your static list case is simply to pull it out of the procedure local scope, and make it object/global scoped instead. Having a huuuuge static list inside of the procedure in the first place does smack of design iffyness, mind, that's more game data than game logic. | |
Which just makes your code ugly as hell
I'm not even gonna get started on the ways the bytecode is encoded, I still havent managed to properly handle all edge cases and weird modifiers on get/set instructions in my disassembler E: Plus, the lists dont have to be that big for the slowdown to be rediclous since each entry is a separate opcode (or two opcodes if you're attaching data) | |
I'd actually probably argue having game data directly embedded in the procedure like that via static list is uglier, assuming it's big.
You know, one great whacking list of 500+ elements sprawling off screen, then underneath it, the actual logic of the procedure, which you're interested in. No bueno. | |
As a thought, actually, there's nothing particularly stopping you making a post-processor for DMBs to do this kind of optimisation, if you liked.
| |
I was actually going to do this, though right now I'm writing an (actually reasonably simple) DM VM that pre-compiles the bytecode to x86 bytecode for fast execution (predicting an optimistic speedup of about 700%)
| |
Using what, for your graphical, sound and networking layers?
| |
I have the networking (somewhat) reverse engineered, I could possibly write a custom server that DS is able to connect to, right now its just the VM though
| |
The VM kind of ... is the server, and has to (among other things) send appearances to the client, stream out the RSC etc. What I'm more interested in, is the libraries you're using to do this.
| |
Not really, while the VM is a part of it, the VM on its own isnt quite a server as all it does is execute the code
The main analyzer is written in Lua though, using LuaJIT's FFI to interface with a library that deals with the trampoline and stack handler code | |
And to complete many of those opcodes, you need to do things like send out updates to the clients.
Edit: Sorry, to complete many of those opcodes usefully ... | |
Not really, the VM would just call the provided stub thats meant to implement those opcodes (such as icon_mapcolors), they'd just do basicaly nothing until you hook something up to it
Edit: goddamn edits everywhere, but yes, those wont be terribly usefull until you tell the VM what to do when running those | |
Alright, now I get it. I was a bit alarmed you see, when you said "actually reasonably simple", because I thought you'd encompassed the entire set of functionality in there. When obviously yeah, that's a lot more time and work than simply having the infrastructure to read in DMBs and 'execute' bytecode, handle stack frames blah blah. Makes more sense now.
| |
You're making two different points in this thread. You said the compiler is stupid, and I agree to an extent: the compiler does its job, but it doesn't particularly optimize the bytecode it produces.
Every point you made after that actually encompasses the VM or the DMB format itself, which the compiler isn't to be faulted for. The optimizations the compiler could be making aren't a big deal---more or less, you can do those yourself by smartly writing your code, with a few exceptions. Drastically changing the .dmb format isn't likely on the foreseeable future's to-do list. As for the VM? Sure, I'll be happy to have dynamic x86 binary translation when BYOND takes off and Tom strikes it big (or Google buys BYOND, and Tom strikes it big). Right now I don't imagine they're investing their limited resources in this, however. | |
I addressed the compiler at the top of the thread, then it sidetracked, and its not like the reason for BYONDs demise is how hilariously laggy anything made in it is (half the fault of the crappy networking though)
| |
The main problem with writing a new compiler is DM isn't a language you can particularly express well in a context-free grammar, so it's a real pain in the butt to parse all the cases dm.exe also supports.