maxime_cb

Thanks for clarifying. Tone is sometimes ambiguous via text.

At the moment I'm in no rush to actually write the JIT compiler because I think it's faster to iterate with an interpreter. I want to flesh out the VM and its APIs, test the hell out of everything and develop the system a bit more first.

The interpreter runs at something ~400 million instructions per second on my laptop, which is probably close to the performance of an old school Pentium 2 chip, so it's actually fast enough to run a lot of non-trivial software. With even a really basic JIT I should be able to hit 10x that throughput. I've benchmarked code out of GCC and it runs about 27 times faster (on a microbenchmark).

At the moment I have an event-driven system where you can set up callbacks and timers. It's not green threads but it makes it easy to have multiple different update events running at different rates, for example: https://github.com/maximecb/uvm/blob/main/ncc/examples/attac...

The level of cynicism on HN is sometimes really depressing.

> the jvm already exists and you can run [some] ancient compiled class files with it [but many won't work correctly].

FTFY.

> With all due respect, you ain’t going to beat the JVM with your UVM’s JIT compiler, not even close.

I think I may be able to get very close to native performance. I don't want to sound like an asshole by appealing to authority, but you aren't talking to a teenager writing an interpreter from their parent's basement. I have 21 years of programming experience, a PhD in compiler design and multiple published papers. I have some idea what I'm talking about.

> Why do you think creating a similarly good JIT compiler to a very similar design would be any easier in case of UVM?

The design is superficially similar to the JVM but it's also quite different. UVM's bytecode is untyped. It maps fairly directly to the x86-64 and ARMv8 instruction sets. If you want an idea of how a simple JIT compiler for a bytecode like that can perform, you should look at the performance of Apple's Rosetta. But, I actually think I can build something that yields better performance than that :)

I could actually use some feedback when it comes to the design of the parallelism model for UVM. I have a few ideas but it's not my area of expertise, so I would welcome feedback and suggestions.

Except that's just not true. It's already broken/incompatible in many places across browsers. You may not notice if you're just doing basic HTML/CSS, but if you do anything slightly more dynamic, you're going to notice. An ever-expanding set of complex APIs also makes it more and more likely that bugs will go unseen and unfixed. See two examples I detailed in the blog post.

Yes, but POSIX doesn't provide APIs for graphics or audio, for example, even though these things are necessary to build a lot of end-user software.

You seem to be doing just fine without me :)

Blink is a very impressive project. Mad props.

Implementing a good GC is incredibly hard. The JVM may have just "100+ basic instructions", but it also has classes, objects, arrays, and a whole set of APIs it provides. Your JVM is kind of useless if it doesn't ship with all of the user interface primitives (and other APIs/classes) people expect, for instance. Otherwise what you have is not what people expect to find in a JVM.

I'm also under the impression that building a good JIT for a JVM would be a massive undertaking. It literally took over a decade for the Sun/Oracle JVM's JIT to become mature enough.

I've designed UVM in a way that I believe it will be possible to design a good JIT with relatively little effort

If I had to guess, I would say it probably comes down to wanting to go with static, ahead of time compilation rather than JIT. There are real and valid advantages to AOT compilation. There's downsides with the LLVM approach too. For example, LLVM makes it explicit that they provide zero guarantees when it comes to the stability of their bitcode format. That somewhat limits what you can do with it.

> Does the discussion happen in a public place? If yes I'd be extremely happy to join in since I also got started with making my own system around a month ago, and it feels a bit lonely going on such an endeavor at times.

I'm happy to discuss anything in the GitHub discussions for UVM: https://github.com/maximecb/uvm/discussions

> Very interesting choice, I did away with such assumptions and ran the other way, my system might feel quite alien/esoteric since I went for something that draws a lot of inspiration from Chuck Moore's work with ColorForth as well as his F18 chip.

If you're building a system for fun, or to explore new ideas, then it seems fine to make it as esoteric as you want. However, in my experience, making esoteric choices when designing programming languages for instance, can really alienate potential users. Especially if you could have obviously gone with some more traditional and familiar choices but you went with something more esoteric that doesn't have any clear value added.

IMO it's a bit like when it comes to terminology. If there's a commonly accepted way to refer to something, use it. Don't make up your own nomenclature, you'll just create extra confusion for no reason.

I go into some of the design decisions I made to make JIT optimizations easier here: https://github.com/maximecb/uvm/blob/main/doc/design.md

Besides the issue of whether you pin or don't pin your dependencies, the problem is that node packages can depend on external native code. You can have several more layers of dependencies in there. If, for any reason, those native packages won't install/run on your machine, your dependencies can still break under you, even if you pin them. Python and Ruby have the same vulnerability when it comes to dependencies breaking.

For one the JVM is a huge piece of software. Large enough that only a large corporation could realistically reimplemented or maintain it. It also exposes many APIs with a large surface area. Then there's the issue of Oracle and how you feel about them as a company.

UVM has obviously nowhere near the ecosystem, but you can draw pixels to a frame buffer with two function calls, and your UI will be guaranteed to look the same everywhere.

LLVM is more heavyweight. Has a lot of analysis and optimization passes for static compilation. UVM is currently very lightweight, will be JIT compiled. Crucially UVM will provide graphics, audio and networking primitives.

Author here. The creator of UXN is a friend of mine and we chat semi-regularly about our VMs.

I have a lot of respect for uxn and credit it as an inspiration, but the goals of each project are different. UXN is a 16-bit system with 64KB of RAM accessible. It will also probably always remain interpreted. These design restrictions are seen as tools to foster creativity.

UVM is a 32/64-bit VM. It's currently interpreted, but I've designed the instruction set with JIT compilation in mind. I have a PhD in compiler design and I'm fairly confident that I can make a fast JIT for UVM in a relatively short amount of time, when I feel the design is mature/stable enough.

At the moment, UVM is relatively immature, but I want it to be a small/minimalistic VM that you can still build "real" or modern software in that takes good advantage of the capabilities and performance of your machine.

Another difference is that IMO, UVM is more approachable. UXN's assembly language is fairly esoteric IMO. It doesn't look like any other assembly language I've ever seen. That doesn't make it bad, but it does potentially make it harder to learn and harder to leverage an existing base of programming skills. UVM's assembly is designed to not be surprising if you've ever programmed in assembly and know the basic ideas about how a stack machine works. I also have a WIP C compiler that's already usable to write simple programs. See my little snake game for a fun toy example: https://github.com/maximecb/uvm/blob/main/ncc/examples/snake...

Assembly syntax example: https://github.com/maximecb/uvm/blob/main/vm/examples/factor...

I'll point to the fact that there is almost no boilerplate necessary to start drawing some pixels on a 2D canvas, which IMO makes it a fun platform to develop for. Like I said, it's immature, but I'll iron out all the bugs I can find and keep making it better.

Yes. Not only is YJIT directly integrated into CRuby, it's also 100% compatible with your existing Ruby code, which is why we chose to go that route.

We didn't want to independently reimplement Ruby because we knew that this would lead to a situation where we wouldn't be 100% compatible, which would stop people from using YJIT. If you think about PyPy for example, they have great performance numbers, but relatively few people are using it.

If you believe the language benchmark game, Ruby is faster than Python on many of the microbenchmarks: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

And the benchmark game is using Ruby 3.1, whereas 3.2 is significantly faster. YMMV though, it is going to depend on your use case, but we are always working on making Ruby faster, and if you run into a use case where Python is a lot faster, you can ping me on twitter @Love2Code and tell me about it. We'll take a look.

Look at it a different way: maybe BASIC is good at exactly what it was intended to do, which is to provide a good intro to programming to kids and beginners. It was never intended to write enterprise-scale software, and that's ok. That's not the intended use case for BASIC, and it's fine that BASIC can't please everyone with every possible use case.

That's pretty weird. If you or anyone has time to help me debug this, I would much appreciate your help. Might be something with the CSS.

You can save it locally to a file that's in a JSON format and easy to parse. That can allow you to run it locally, or you could build some kind of exporter. Right now to export audio you'd have to record the audio output.

Please share your project with acid tones! :)

Since 2019 on and off in my spare time. I've found motivation comes and goes and I actually spent one year not working on it at all, but resumed work in 2021.

There is a help page to get you started: https://noisecraft.app/help

It's pretty basic but I invite people to open pull requests to improve it.

This video shows how (an older version) of the app is used: https://www.youtube.com/watch?v=609k3_Z-16o

Thanks Paul. Web development definitely has its downsides. It's been challenging to get everything to work well across Chrome/Firefox and Safari because there's annoying little differences in the way they handle mouse events for example (I might blog about this at some point).

The upside though is that with an app like this, anyone can start experimenting with music and sound design from their computer, without installing anything, and you can easily show your friends the things you created (or share ideas with internet strangers).

Thank you. The UI is pretty basic but I tried to design it in such a way that the functionality would feel intuitive to newcomers, with as few hidden features as possible. I picked this project to share because I figured that it was very easy for people to play with by editing the pattern, without needing to understand how the sound synthesis works.

Nice. What kind of device are you using?

No problem :)

I should mention that this is open source too: https://github.com/maximecb/noisecraft

OP here. I've been working on an app/platform for people to explore musical ideas. This is a drum machine that a European friend of mine created using the app. You can press the Play button in the top-right corner to start audio playback and customize the pattern being played by clicking the red squares on the step sequencer.

If this example is too big and scary, I've made a simpler drum machine here: https://noisecraft.app/529

And many more examples can be found on the browse page: https://noisecraft.app/browse

One of my all-time favorites is this one: https://noisecraft.app/101

Disclaimer that this is made with laptop/desktop computers in mind and may not work well on mobile. The app supports binding MIDI controls by double clicking on knobs :)

Also going to plug in NoiseCraft since we're talking about music live coding: https://noisecraft.app/101