4 ms·

Nice! This is what I keep telling everyone: LLMs let you build stuff you may not have the time/energy to before. You still need to do the last 10% yourself thou

by sieve 2mo ago

Nice! This is what I keep telling everyone: LLMs let you build stuff you may not have the time/energy to before. You still need to do the last 10% yourself though. Tying up all the loose ends. Syntax is a personal choice. Can always be changed. Architectural choices are difficult to manage later on. The VM seems to be a stack VM. I have my own python replacement project (https://news.ycombinator.com/item?id=48090665 https://news.ycombinator.com/item?id=48090665) that I am developing privately for now. LLM-assisted ofc. Started with a bytecode VM and then switched over to a register one. The biggest break from regular language systems was the decision to move to an Erlang-style preemptive scheduler.

AbhiramaVS 2mo ago
I completely agree! I started Jaithon before mainstream LLMs existed and for a while Jaithon was free of AI generated code and my personal stance on AI generated code was rather negative. Recently though, my stance has grown far more positive towards AI. While LLMs are undeniably the future it remains crucial that you completely understand the code being generated, and are also in control of the architecture in place. I have tried to adhere to both of these principals while coding :) and it is an unequivocal fact that AI made me atleast 10x more productive. Granted this is a bad measure but still a measure of such: in the last 2 days I have made the same number of commits as I have to Jaithon in the last 3 years. Also, I was curious why you swapped over to a register based VM, could you give more clarity on that and the benifits/negatives? currently im using some sort of bytecode vm, though its not like im married to the idea of a bytecode vm. Also (dont mean this as any sort of advertisement or anything like that) would you mind starring the repo? trying to hit 15 stars :D dont feel forced or anything like that.
- sieve 2mo ago
  There are pros and cons to both approaches. I moved from stack to register because I was writing the code gen backend from scratch in any case and preferred to have a register representation instead of converting from stack to register (which has to happen one way or another). Also mildly helpful with control flow analysis during bytecode generation and verification phases.
  - AbhiramaVS 2mo ago
    ah gotu, yeah that makes sense. I will def further investigate this ltr :)
- UncleEntity 2mo ago
  >> I was curious why you swapped over to a register based VM Not the OP but there are real performance benefits, I've been poking at a wasm VM and it has two jit backends where one is pure copy-and-patch while the other caches the locals in registers using the function args + copy-and-patch and there is a significant performance gain just from that alone. A push/pop from a stack is fairly expensive while the register caching keeps things in the CPU's happy place. The smallest gain was ~2x over the interpreter on memory bound tasks while the largest was ~20x on math heave kernels. Admittedly, the interpreter isn't the fastest thing ever as its one and only goal is conformance with the spec to use for differential testing but the difference between the the two jit levels are somewhere in the neighborhood of 1.5-5x depending what the code is up to. The three biggest performance gains, from the random benchmarks, are quality of the bytecode out of the compiler, the jit itself and register caching from what I can tell from the fancy chart I had Claude make and a good squint. Tail-calling would be somewhere on that list too but I can't measure that as all the opcode do the tail-calls between each other as that's just how it was all put together, the code the interpreter runs is the same code the copy-and-patch jit stitches together as they are both generated from the same DSL. Which is also the biggest cost with the register caching as the code template file grew from tens of kilobytes for the 407(?) wasm opcodes to ~3MB for all the specialized ones to pass the locals in eight args but that's really just a binary size thing, the stitched together functions just pick and chose the ones they need. Long winded way to say CPUs like when you keep things in registers, I suppose...

by sieve 2mo ago

AbhiramaVS 2mo ago

I completely agree! I started Jaithon before mainstream LLMs existed and for a while Jaithon was free of AI generated code and my personal stance on AI generated code was rather negative. Recently though, my stance has grown far more positive towards AI. While LLMs are undeniably the future it remains crucial that you completely understand the code being generated, and are also in control of the architecture in place. I have tried to adhere to both of these principals while coding :) and it is an unequivocal fact that AI made me atleast 10x more productive. Granted this is a bad measure but still a measure of such: in the last 2 days I have made the same number of commits as I have to Jaithon in the last 3 years. Also, I was curious why you swapped over to a register based VM, could you give more clarity on that and the benifits/negatives? currently im using some sort of bytecode vm, though its not like im married to the idea of a bytecode vm. Also (dont mean this as any sort of advertisement or anything like that) would you mind starring the repo? trying to hit 15 stars :D dont feel forced or anything like that.

sieve 2mo ago
There are pros and cons to both approaches. I moved from stack to register because I was writing the code gen backend from scratch in any case and preferred to have a register representation instead of converting from stack to register (which has to happen one way or another). Also mildly helpful with control flow analysis during bytecode generation and verification phases.
- AbhiramaVS 2mo ago
  ah gotu, yeah that makes sense. I will def further investigate this ltr :)
UncleEntity 2mo ago
>> I was curious why you swapped over to a register based VM Not the OP but there are real performance benefits, I've been poking at a wasm VM and it has two jit backends where one is pure copy-and-patch while the other caches the locals in registers using the function args + copy-and-patch and there is a significant performance gain just from that alone. A push/pop from a stack is fairly expensive while the register caching keeps things in the CPU's happy place. The smallest gain was ~2x over the interpreter on memory bound tasks while the largest was ~20x on math heave kernels. Admittedly, the interpreter isn't the fastest thing ever as its one and only goal is conformance with the spec to use for differential testing but the difference between the the two jit levels are somewhere in the neighborhood of 1.5-5x depending what the code is up to. The three biggest performance gains, from the random benchmarks, are quality of the bytecode out of the compiler, the jit itself and register caching from what I can tell from the fancy chart I had Claude make and a good squint. Tail-calling would be somewhere on that list too but I can't measure that as all the opcode do the tail-calls between each other as that's just how it was all put together, the code the interpreter runs is the same code the copy-and-patch jit stitches together as they are both generated from the same DSL. Which is also the biggest cost with the register caching as the code template file grew from tens of kilobytes for the 407(?) wasm opcodes to ~3MB for all the specialized ones to pass the locals in eight args but that's really just a binary size thing, the stitched together functions just pick and chose the ones they need. Long winded way to say CPUs like when you keep things in registers, I suppose...