The absolutely easiest way to write a JIT is to use Javascript and eval() (or "new Function()", which is just eval in a Java-shaped tuxedo). You can quite easily speed up little matching functions, especially arithmetic heavy ones, by just filling in some templates at runtime!
Here's an example used in PuzzleScript: https://github.com/increpare/PuzzleScript/blob/dc1e0fc979365...
HOhodgehog117 小时前
This is true, and is why I think Javascript is underrated for emulation.
For example, this PSX emulator: https://github.com/kootstra-rene/enge-js
It has decent compatibility and good speed. Furthermore, I challenge anyone to find a PSX emulator with fewer lines of code with competitive speed and accuracy. To my knowledge, this is by far the simplest such implementation, and is able to do this by taking advantage of Javascript JIT compilation.
MImikepurvis13 小时前
I've always really enjoyed Andrew Kelley's article about trying to statically recompile NES code from 2013 [1]. Basically he makes a ton of progress but gets hung up not just on the realities of the handwritten assembler of the era just not being all that great at mapping to higher level LLVM IR. In the conclusion he specifically calls out a JIT-type methodology as probably being the way to go, where you live-recompile the hot paths when you have the runtime data required to actually understand them, and don't worry about the parts you can't.
Very cool to see something like that in action.
[1]: https://andrewkelley.me/post/jamulator.html
BAbawolff12 小时前
> Dolphin isn’t on iOS, because you can’t do JIT compilation on iOS....Well, Apple has one exception to its JIT restrictions: web browsers. JavaScriptCore, WebKit’s JS engine, uses JIT compilation for its higher-performance tiers. So, if a JS function is called enough times, eventually it’ll be optimised and compiled into native machine code. The same is true for WebAssembly.
I was wondering about the why of the headline, and this is a really interesting answer. Such a beautiful way to get around restrictions. I wonder how applicable it is to other projects.
PLplaidthunder9 小时前
Restrictions aside, many years ago I landed a self-hosted Array.sort implementation in Firefox's JS Engine that performed better than the native C++ implementation :] -- it's a recurring theme.
https://bugzilla.mozilla.org/show_bug.cgi?id=715181
DAdag10016 小时前
This is an incredible project for an undergraduate. Very impressive.
Interesting to note that Firefox is 25% slower than Chrome/Safari, I wonder why.
TMtmpz2216 小时前
[deleted]
KOkoolala15 小时前
What are you basing this statement on? The code comments read very human to me. Your the one hurting their chances of finding a job by falsely saying this.
SIsimonw15 小时前
I'd hire an undergraduate who can produce this level of work with Claude.
TOtomrod8 小时前
Likewise. When we talk about being able to use AI tooling to do cool things, this is the type of thing that comes to mind.
HUhumpttysidy13 小时前
[deleted]
UYuyyyyyyuyyyy13 小时前
[deleted]
GOgodwinson__4-815 小时前
Every company they apply to will be leveraging LLMs. Time to get over it. No need to be grumpy old man about such things. Every generation has faced such foes. The old always yields to the new.
For the times they are a-changin'
AGagentultra11 小时前
You can’t vibe code a production capable C compiler if you’ve never written one.
Sure, companies are asking for LLM experience. But whether they know it or not they are also hiring someone who knows what they’re doing with the output.
Projects like this are still worth doing by hand. I’d dare say it’s even enjoyable.
GOgodwinson__4-810 小时前
I don't disagree with you. I just don't think it's particularly charitable for a presumably seasoned developer to not only go out of their way to accuse some junior of using LLMs but then declare that this obviously makes them unemployable.
UNunknown14 小时前
[deleted]
GOgodwinsonsucks12 小时前
[deleted]
AHahartmetz15 小时前
Of course it beats a native interpreter. WASM overhead is about 20%, interpreter overhead is about 1000%.
What's cool here is to have a GameBoy JIT runtime at all.
GRgrashalm14 小时前
It's two jits in total.
AHahartmetz11 小时前
True, but the WASM JIT is pretty low overhead because WASM seems to be a good design for what it needs to do. It's what I was referring to with the 20% overhead figure.
RNrnio8 小时前
[deleted]
TAtancop2 小时前
> Apple has one exception to its JIT restrictions: web browsers
i wonder if they ever let native apps compile and run wasm directly instead of opening a browser window.
JCjcmfernandes8 小时前
Very cool! I did something similar using Dolphin and LLVM, 16 years ago during my masters, for a course on virtual machines. I compiled the interpreter to LLVM bitcode and then used it that to build basic blocks. It was super slow, but it worked, and I had lots of fun working on it.
MImilch16 小时前
Very interesting article. Would've been fun to see the comparison between native interpreter & JIT-on-WASM on iOS as well
JHjhatemyjob11 小时前
The author's base assumption, and stated motivation for doing this project, is wrong.
https://github.com/StephenDev0/StikDebug
For an undergrad project, I suppose it's fine to conveniently forget about the existence of this solution for the sake of getting a good grade.
SAsaagarjha10 小时前
I would not expect the average undergraduate to understand the intricacies of how iOS does dynamic codesigning enforcement. There are plenty of people who have graduated with advanced degrees and work at Apple who don't really understand how it works, either.
JHjhatemyjob3 小时前
Ok
JRjrmg11 小时前
It’s wrong ‘for sideloaded apps that have the get-task-allow entitlement.’
It’s right for ‘regular’ apps.
KMkmeisthax5 小时前
In order to use this, you need another device to initiate a debugging session on the given process. This is fine for sideloading Dolphin using your developer credentials but is not an acceptable solution for other kinds of apps. Some people might not want their app to be debuggable by randos, and requiring a tether to kickstart the app - even if it's just another iPhone - is cumbersome and user-hostile.
In contrast, spinning up a WebView works everywhere and App Review probably won't even notice or care what you're doing.
JOjonny_eh14 小时前
So it's a JIT-in-JIT? JiJIT?
LIlightedman13 小时前
Still doesn't beat a natively-coded emulator. I got several that run faster on a 166MHz non-MMX Pentium than this emulator does on my Core Ultra i9.
ANanthk2 小时前
On Mednafen I can speed up the emulator up to 4x while compiling c++ under an n270 netbook. With GCC, not Clang. Without compiling I might yield 16x speeds and more with ease.
BEbebenebenebeb16 小时前
[deleted]
IBiberator16 小时前
yet on real old hardware it would be 20x slower in real life.
same as all native javascript junk - its fast, but non usuable on older hardware
QWqweqwe1414 小时前
Here's a nickel kid. Go buy yourself a real computer.
RIrixed13 小时前
How much RAM would a nickel buy me?
WIwifipunk11 小时前
based on the tracked average of $12.65/gb from rampricesusa you could get about 4mb of ddr5
SWswitchbak15 小时前
Good thing I'm not running games on my 4gb Pentium 4 then.
JOjonhohle12 小时前
Your code running on other people’s hardware is a privilege. Treat it with respect.
评论
13 条顶层评论请先登录 h4cker 账号，然后连接 Hacker News 后发表评论。
The absolutely easiest way to write a JIT is to use Javascript and eval() (or "new Function()", which is just eval in a Java-shaped tuxedo). You can quite easily speed up little matching functions, especially arithmetic heavy ones, by just filling in some templates at runtime! Here's an example used in PuzzleScript: https://github.com/increpare/PuzzleScript/blob/dc1e0fc979365...
This is true, and is why I think Javascript is underrated for emulation. For example, this PSX emulator: https://github.com/kootstra-rene/enge-js It has decent compatibility and good speed. Furthermore, I challenge anyone to find a PSX emulator with fewer lines of code with competitive speed and accuracy. To my knowledge, this is by far the simplest such implementation, and is able to do this by taking advantage of Javascript JIT compilation.
I've always really enjoyed Andrew Kelley's article about trying to statically recompile NES code from 2013 [1]. Basically he makes a ton of progress but gets hung up not just on the realities of the handwritten assembler of the era just not being all that great at mapping to higher level LLVM IR. In the conclusion he specifically calls out a JIT-type methodology as probably being the way to go, where you live-recompile the hot paths when you have the runtime data required to actually understand them, and don't worry about the parts you can't. Very cool to see something like that in action. [1]: https://andrewkelley.me/post/jamulator.html
> Dolphin isn’t on iOS, because you can’t do JIT compilation on iOS....Well, Apple has one exception to its JIT restrictions: web browsers. JavaScriptCore, WebKit’s JS engine, uses JIT compilation for its higher-performance tiers. So, if a JS function is called enough times, eventually it’ll be optimised and compiled into native machine code. The same is true for WebAssembly. I was wondering about the why of the headline, and this is a really interesting answer. Such a beautiful way to get around restrictions. I wonder how applicable it is to other projects.
Restrictions aside, many years ago I landed a self-hosted Array.sort implementation in Firefox's JS Engine that performed better than the native C++ implementation :] -- it's a recurring theme. https://bugzilla.mozilla.org/show_bug.cgi?id=715181
This is an incredible project for an undergraduate. Very impressive. Interesting to note that Firefox is 25% slower than Chrome/Safari, I wonder why.
[deleted]
What are you basing this statement on? The code comments read very human to me. Your the one hurting their chances of finding a job by falsely saying this.
I'd hire an undergraduate who can produce this level of work with Claude.
Likewise. When we talk about being able to use AI tooling to do cool things, this is the type of thing that comes to mind.
[deleted]
[deleted]
Every company they apply to will be leveraging LLMs. Time to get over it. No need to be grumpy old man about such things. Every generation has faced such foes. The old always yields to the new. For the times they are a-changin'
You can’t vibe code a production capable C compiler if you’ve never written one. Sure, companies are asking for LLM experience. But whether they know it or not they are also hiring someone who knows what they’re doing with the output. Projects like this are still worth doing by hand. I’d dare say it’s even enjoyable.
I don't disagree with you. I just don't think it's particularly charitable for a presumably seasoned developer to not only go out of their way to accuse some junior of using LLMs but then declare that this obviously makes them unemployable.
[deleted]
[deleted]
Of course it beats a native interpreter. WASM overhead is about 20%, interpreter overhead is about 1000%. What's cool here is to have a GameBoy JIT runtime at all.
It's two jits in total.
True, but the WASM JIT is pretty low overhead because WASM seems to be a good design for what it needs to do. It's what I was referring to with the 20% overhead figure.
[deleted]
> Apple has one exception to its JIT restrictions: web browsers i wonder if they ever let native apps compile and run wasm directly instead of opening a browser window.
Very cool! I did something similar using Dolphin and LLVM, 16 years ago during my masters, for a course on virtual machines. I compiled the interpreter to LLVM bitcode and then used it that to build basic blocks. It was super slow, but it worked, and I had lots of fun working on it.
Very interesting article. Would've been fun to see the comparison between native interpreter & JIT-on-WASM on iOS as well
The author's base assumption, and stated motivation for doing this project, is wrong. https://github.com/StephenDev0/StikDebug For an undergrad project, I suppose it's fine to conveniently forget about the existence of this solution for the sake of getting a good grade.
I would not expect the average undergraduate to understand the intricacies of how iOS does dynamic codesigning enforcement. There are plenty of people who have graduated with advanced degrees and work at Apple who don't really understand how it works, either.
Ok
It’s wrong ‘for sideloaded apps that have the get-task-allow entitlement.’ It’s right for ‘regular’ apps.
In order to use this, you need another device to initiate a debugging session on the given process. This is fine for sideloading Dolphin using your developer credentials but is not an acceptable solution for other kinds of apps. Some people might not want their app to be debuggable by randos, and requiring a tether to kickstart the app - even if it's just another iPhone - is cumbersome and user-hostile. In contrast, spinning up a WebView works everywhere and App Review probably won't even notice or care what you're doing.
So it's a JIT-in-JIT? JiJIT?
Still doesn't beat a natively-coded emulator. I got several that run faster on a 166MHz non-MMX Pentium than this emulator does on my Core Ultra i9.
On Mednafen I can speed up the emulator up to 4x while compiling c++ under an n270 netbook. With GCC, not Clang. Without compiling I might yield 16x speeds and more with ease.
[deleted]
yet on real old hardware it would be 20x slower in real life. same as all native javascript junk - its fast, but non usuable on older hardware
Here's a nickel kid. Go buy yourself a real computer.
How much RAM would a nickel buy me?
based on the tracked average of $12.65/gb from rampricesusa you could get about 4mb of ddr5
Good thing I'm not running games on my 4gb Pentium 4 then.
Your code running on other people’s hardware is a privilege. Treat it with respect.
You can also like not run the Gameboy emulator