Adding 64-bit support about dna-redux HOT 24 OPEN

@eloraiby On the other hand, if it makes sense to rename the repo, it's probably better to do it early, before it explodes in popularity 😎. What do you think about:

• "dotnet-any", or is that too bland ?
• "dotnet-anywhere", or is it too long?
• "dna-redux", or is that too awesome?

from dna-redux.

@ncave, I ll go with dna-redux, it's perfect 👍

from dna-redux.

working on a bug fix for this.

from dna-redux.

@eloraiby Too bad there is no 64-bit __asm jmp intrinsic so we're stuck with 32-bit on MSVC. Added switching on JIT ops instead.

from dna-redux.

@eloraiby I fixed two memory leaks (#18), but that's probably orthogonal to this issue.

from dna-redux.

@ncave good work!
WIN64: for the __asm jmp on win64, we have to change JIT_Execute.c to use switch cases. wonder if there is really a performance penalty for doing so.

For the x64 bug: it's both a memory alignment issue with the tables and a pointer size problem. now fixing it for gcc, but will take time.

from dna-redux.

@eloraiby I don't see a penalty for switching on op instead of labels (see #19), it's about the same (32-bit). In WebAssembly, switch may even be a bit faster than labels, which is nice.

from dna-redux.

@eloraiby Fixed all the printfn issues, hopefully. Also now using JIT ops switch instead of labels, to squeeze every little bit of performance out of it (but I'm sure there are other low hanging performance fruits).

from dna-redux.

@ncave great work, finally F# is an option with DNA. Are you working on dotnet-js fulltime ?

from dna-redux.

@eloraiby No, I have a day job, but the print issue was bugging me, so I had to dig deep to figure it out. Turned out to be simple once you figure it out, but only in hindsight.

from dna-redux.

@ncave didn't despair yet :), still working on it. I am changing the metadata state machine and change all the table state machine event format in the process.

from dna-redux.

@eloraiby sounds amazing, thanks

from dna-redux.

@eloraiby I checked in some work, hopefully you can rebase. Sorry about the inconvenience.

from dna-redux.

@ncave I have fixed - hopefully - the first part: the state machine for meta data loading.
It crashes in execution trying to access the evaluation stack. We can start pointer chasing now :)

Pull request #26

from dna-redux.

@eloraiby Awesome, thanks! Pointer chasing/fixing will probably take a while, I don't think anybody ever ran this in 64-bit, there are quite a few places that state "32-bits only" or "this should work in 32 bits".

from dna-redux.

@ncave I think a few did then abandoned it when it crashed on them. nonetheless, making it work with 64 bits will give it a large audience and will draw more ppl attention.

from dna-redux.

@ncave after the mono announcement wasm support, do you plan to continue working on DNA ?

from dna-redux.

@eloraiby I think so, at least for a while, at least until we see what the performance characteristics of mono-wasm are. I'm still interested to explore any potential low-hanging performance improvements for DNA, so let me know if you have any pent-up ideas or thoughts.

About the 64-bit support, it's (obviously) up to you if you want to proceed, it's not an immediate goal, although I agree it would be nice.

Anyway, it's a fun toy project, it's nice to have full control over the entire code base and be able to iterate quickly as needed, so I'll probably keep tinkering with it now and then, as it may be useful for other platforms too.

Let me know what you think, I appreciate your help.

from dna-redux.

@ncave good to hear. For me, DNA is also a pet project, and honestly, I would like to have an open source cross platform framework for minigames using it, in the spirit of Lua's LOVE. That's why I ported it to armv32 and still working on the 64bit version. There are around 1000 issues to fix thanks to the static analyser. If only 5% are real issues, we have about 50 bugs to fix as it stands. As such, my priority now is fixing these issues, and hopefully, the 64 bits issues will be fixed as well.

That being said, my experience with mono on devices wasn't great: memory consumption is high, load time is high as well. AOT code is not that great at the expense of more memory and huge binaries.

Performance wise, it really depends on the application side. There is plenty of optimisations that can be done in the garbage collector itself, other areas would require JITing on load instead of on execute. Detecting patterns while jiting and transforming those to native calls is also something we can do. The current implementation is a stack machine, so it's a bit slower than register based VM on register machines - again, something to consider eventually.

Having said that, and since they stopped support of DNA in blazor, I will suggest to make it a standalone project, independent of blazor. (DNA-Reloaded ?) ;)

from dna-redux.

@eloraiby It's already independent of Blazor (not a fork) and stand-alone, do you want to rename it or just change the readme a bit? I can make it into an org if you prefer, or just add you as a contributor, anything works, just let me know.

from dna-redux.

@ncave the choice is really yours, the JS at the end sounds it is about dotnet for JS but we already have it working for 32 bits platforms (arm, ia32 and wasm on windows and linux). With x64 it will be on all platforms. That's why I suggest the name DNA-Re or DNA-Reloaded. It could be a parallel repo though for people referencing dotnet-js.

Also you have made a lot of modifications, and honestly debugging takes the majority of time (80% on average), so updating the list of credit (put your name there) is fair to say the least :)

from dna-redux.

@eloraiby Thanks, makes sense, I'll think about it, perhaps we can rename it after the mono-wasm is officially out and the novelty of running on webassembly subsides a bit 👍

from dna-redux.

@ncave can you provide a private channel for communication ?

from dna-redux.

@eloraiby emailed.

from dna-redux.