From my experiences indirect-threading and direct-threading are only ~10-15% of performance apart.
However, the switch-loop dispatch that is used on platforms that do not support tail-calls can be a lot slower. However, the slowdown highly depends on the underlying hardware. For example, on Apple Silicon the slow-down is huge, whereas on Intel the slowdown isn't that drastic.
Unfortunately, I haven't tested any of the Wasm runtimes on low-powered hardware so far but that would be a great addition and I'd be extremely interested in how the fast interpreters such as Wasmi, Wasm3 and Stitch perform there. From what I know Wasm3 was optimized for those targets, so it might fare well and if Wasmi does not yet perform well there it should be fairly easy to catch up since the architectural foundation is similar.
Also, Wasmi's auto-dispatch feature that automatically detects if tail-calls can be used is very conservative. We might be able to cover more targets in the future with it, thus avoiding the slower switch-loop for more platforms eventually.
From the people that use Wasmi on lower-powered hardware (e.g. the Firefly-zero people) they seem to be very happy with Wasmi's performance so far.
Thank you! :)
In the `wasmi-benchmarks` suite we support ~20 different Wasm runtimes and compare their performance with each other, including optimizing JITs such as Wasmtime/Wasmer Cranelift and baseline JITs such as Wasmtime Winch and Wasmer Singlepass.
The geomean of performance of Wasmi compared to baseline JITs across all benchmarks in the repository ranges from 2.5-5.2x slower depending on hardware.
And compared to opimizing JITs geomean ranges from 5.3-10.7x slower.
Wasmtime's Pulley is a very interesting interpreter. It isn't the fastest but it is the only Wasm interpreter that sits behind an elaborate optimization pipeline. Thus if you feed unoptimized Wasm, it would likely outperform the other interpreters. However, unoptimized Wasm is extremely uncommon.
I've been poking at a C version of this (https://github.com/dan-eicher/javelina) which would be interesting to benchmark against as it does a similar tail-calling dispatch mechanism. Plus copy-and-patch JIT but that probably only works on x86-64 as that's the only place I've ever tested it. The main differences from a brief skim of TFA is mine doesn't have any fallback (so non-tail calls will blow up the C stack) and the function calls always go through the trampoline so the VM doesn't have to care if it's calling JIT or interpreted code which, I'm assuming, your function pointer embedding thing is designed to optimize away.
And the JavaCard firewall algorithm would be an interesting non-spec addition to a wasm VM which is running code you really, really don't want to escape the sandbox. Something to look into for inspiration on the subject, perhaps? Not sure if there's any sort of proposal for sandboxing these things as I just took the spec file and implemented it using the dodgy weasels where it was mainly to see how far they've come with no real plan to use it for anything so kept it strictly to what the spec said a wasm interpreter needs to do.
Anyhoo, didn't really realize there were so many different projects doing the same thing, kind of interesting, actually...
If you think that your Wasm interpreter is stable and kinda production ready enough, you might want to file a PR to the wasmi-benchmarks repo to add support for your Wasm runtime.
Would certainly be another great addition to have it.
This would allow comparing your engine to all the others.
hey, I'm not super familliar with webassembly interpreters in general so id ask here:
What's the usecase? like I guess edge, chrome etc already have their own interpreters for webassembly built in. do you aim to replace those and be bundled with them?
Or is this for other browsers? or even just other apps (whats the usecase there as opposed to just native execution)
Wasmi does not directly compete with the large JIT engines such as Wasmtime and V8. Instead, Wasmi tries to fit perfectly into its niche. Its main purpose is that it is very easy to embed and provides great performance for those use-cases.
As detailed in the article, Wasmi is already used a lot for plugin systems, as game engine, as engine for executing smart contracts, and even as engine to run apps in experimental operating systems that have native Wasm support. It is also useful for cloud hosts that do not trust their inputs but need fast startup times and deterministic execution.
Furthermore, there are platforms such as iOS that outright forbid using JITs, so interpreters are the only option.
Fun fact: Wasm interpreter usually can even be embedded into Wasm environments themselves by compiling them to Wasm. Wasmi ran inside Wasmtime when it was used at Parity Technologies. This allowed them to hot-patch the Wasm runtime (Wasmi) without downtime.
> Wasmi is an efficient and feature-rich WebAssembly (Wasm) interpreter. It is an excellent choice for IoT devices, plugin systems (Typst, Zellij, Josh), cloud hosts, smart contracts (Soroban, Ripple) and even for your lightweight game consoles (Firefly Zero).
Hi there! It's really great seeing someone putting in the work to make a WASM interpreter fast :) I'm very much interested in this because I want my game's scripting system to simply run WASM so I need a fast WASM interpreter because iOS forbids JIT and most gaming consoles allegedly do so as well. I know it's NDA gated so one has to be light on details, but have you heard about people using wasmi interpreter on one of the major gaming consoles? I could imagine how that also makes awesome modding possible, especially when being able to limit how many resources those mods are allowed to consume.
I am not aware of any of the major gaming consoles uses Wasm or Wasmi in particular for their engine but I am sure they'd let us know if they ever used Wasm as execution model for all their games.
What's more likely is that Wasm is used in some indie games for those major game consoles.
I know of one game engine (Firefly-zero) and one game where Wasmi is used as game engine and plugin engine respectively. There likely are more, but that's what I know for a certain.
I experimented with running Doom using Wasmi and it even works in the browser, thus in a double sandbox where Wasmi itself is compiled to Wasm: (references in the article)
https://wasmi-labs.github.io/wasmi-doom/
If Wasmi supports all the Wasm proposals that you need for PGlite and if Wasmi supports all the WASI features you need (Wasmi only supported the standard WASI features without extensions), then Wasmi should work for your use-case. :)
> There is a lot of desire for advancement, but standardization means decisions are hard to reverse. For many, things are moving too quickly and in the wrong direction.
Most Wasm proposals are very elegantly designed and effective - meaning they provide lots of value for relatively minor specification bloat. Examples are tail-calls, multi-value, custom-page-sizes, memory64 and even gc.
However, the simd and flexible-simd increased spec bloat by a lot, are not future-proof and caused more fragmentation due to non-determinism. In my opinion work should have focused on flexible-vector (SVE-like) which was more aligned to Wasm's original goals of near-native performance. The reason for this development was that simd was simpler to implement and thus users could reap benefits earlier. Unfortunately, it seems the existence of simd completely stalled development of the superior flexible-vectors proposal.
If flexible-vectors (or similar) will ever be stabilized eventually, we will end up in one of two (bad) scenarios:
1) People will have to decide between simd and flexible-vectors for their compilation, depending on their target hardware which is totally against Wasm's original goals.
2) The simd proposal will be mostly unused and deprecated. Dead weight.
simd128 fills a common need(most games using vector operations) and was a viable option with _broad hardware support_, yes, it adds a ton of instructions and impacts a ton of places with regards to memory ops but vec4 operations commonly use much of those instructions. Better useful than something that will never have a chance of standardization.
On the other spectrum, things like custom-page-sizes seems like a simple flexible solution but smells like an implementation nightmare if you already have a runtime since that really impacts things on a far deeper level (64k pages was probably a mistake, but reading up on the issues of emulating x86 with 4k vs 16k pages on Mac's kinda hints at how devious "small" things like that is), i'm not surprised if it never comes about as an offical part (only 3 runtimes supporting it so far).
I can understand the need for tail-calls but at the same time it's also an annoying can of worms to implement into compilers that wasn't prepared (could have been a large part of why it took so long for Safari to support).
wasm-gc really hit a real-world need (bindings did really suck.. they're better but not perfect now) but also comes in a bit half-assed in some respects (languages like C# needing workarounds to use it), same with memory64 being a real-world need.
I can see different camps (popular/functional languages for gc,m-val and tail-calls), games (simd128, multithreading, memory64), embedded(flexible pages),etc all competing and having focus on what they want but all camps also need to understand that pushing _everything_ will be pushing the risks of the web (security) and in the end that's what wasm was for, providing a runtime to run non-JS code on the web.
My view on specifications is that their long-term success depends on the value they provide relative to their complexity. Complexity inevitably grows over time, so spending that complexity budget carefully is crucial, especially since a specification is only useful if it remains implementable by a broad set of engines.
WebAssembly MVP is a good example: it offered limited initial value but was exceptionally simple. Overall, I am happy with how the spec evolved with the exceptions of 128-bit simd and relaxed-simd.
The main issue I see with 128-bit simd is that it was always clear it would not be the final vector extension. Modern hardware already widely supports 256-bit vector widths, with 512-bit becoming more common. Thus, 128-bit simd increasingly delivers only a fraction of native performance rather than the often-cited "near-native" performance. A flexible-vectors design (similar to ARM SVE or the RISC-V vector extension) could have provided a single, future-proof SIMD model and preserved "near-native" performance for much longer.
From a long-term perspective, this feels like a trade-off of short-term value for a large portion of the spec's complexity budget. Though, I may be underestimating the real challenges for JIT implementers, and I am likely biased being the author of a Wasm interpreter where flexible-vectors would be far more beneficial than 128-bit simd.
Why you think flexible-vectors might never have a realistic path to standardization?
I view it a bit more from the lens of it's initial evolution (Asm.JS) being a wall-breaker to force Safari,etc to keep up. It was done by adding a MVP that was easy to add for all parties (Asm.JS already ran on top of WebGL buffers and JS.. it was mostly a matter of standardizing a way to optimize this in a less hacky way).
In the same way, simd128 was a low hanging fruit with more or less _universal_ hardware support (being a good MVP to bring benefits, more or less fulfilling 99% of what games and other 2d/3d applications need.. important point).
Now as for being future-proof, even today only simd256 would be usable on desktop (so we're only losing half the _potential_ performance) due to how spotty Intel's AVX512 support has been (crashy, P/E core differences, etc), the full potential bought by flexibility in SVE or RV's VE being a thing to look for in the future.
Now, if webassembly had an neural-net or other AI/large-vector heavy focus I'd agree that the omission of a future-proof option is bad, but they've decided to focus on what can be used today and standardize on that since we will actually benefit from that for the forseeable future.
Vector lengths really has been stagnant compared to core counts for hardware makers since it's been more "bang for the buck", the AI focus might still shift that back (even if NPU's has taken the front-seat) but I wouldn't hold my breath for flexible vectors until Intel or AMD jumps on the bandwagon (or ARM and RV chips with really wide vectors takes enough marketshare that it becomes untenable to not support it).
It's kinda frustrating that Mozilla's CEO thinks that axing ad-blockers would be financially beneficial for them. Quite the opposite is true (I believe) since a ton of users would leave Firefox for alternatives.
The whole web ecosystem was first run by VC money and everything was great until every corner was taken, the land grab was complete and the time to recoup the investment has come.
Once the users were trapped for exploitation, it doesn’t make sense to have a browser that blocks ads. How are they supposed to pay software salaries and keep the lights on? People don’t like paying for software, demand constant updates and hate subscriptions. They all end up doing one of those since the incentives are perverse, that’s why Google didn’t just ride the Firefox till the end and instead created the Chrome.
It doesn’t make sense to have trillion dollars companies and everything to be free. The free part is until monopolies are created and walled gardens are full with people. Then comes the monetization and those companies don’t have some moral compass etc, they have KPI stock values and analytics and it’s very obvious that blocking ads isn’t good financially.
I agree with the untrue and revisionism bit, but I disagree with it being the opposite of what happened.
People were trying to figure out how to make money off of the Internet from the early days of the Internet being publicly accessible (rather than a tool used by academic and military institutions). It can be attributed to the downfall of Gopher. It can be attributed to the rise of Netscape and Internet Explorer. While the early web was nowhere near as commercial as it is today, we quickly saw the development of search engines and (ad supported) hosting services that were. By the time 2000's hit, VC money was very much starting to drive the game. In the minds of most people, the Internet was only 5 to 10 years old at that point. (The actual Internet may be much older, but few people took notice of it until the mid-1990's.)
> People don’t like paying for software, demand constant updates and hate subscriptions.
Yes, No, Yes?
I don't demand constant updates. I don't want constant updates. Usually when a company updates software it becomes worse. I am happy with the initial version of 90% of the software I use, and all I want is bug fixes and security updates.
GP wasn't differentiating between different types of updates in their argument, because it doesn't make sense - they're discussing the economics of it, which doesn't care if you're fixing bugs or not.
>> How are they supposed to pay software salaries and keep the lights on? People don’t like paying for software, demand constant updates and hate subscriptions.
I suspect then it doesn't matter whether Mozilla kills itself or not. You should be fine with the current release of Firefox. Maybe you'd lose the installer, so all you have to do is put it somewhere safe and you're good.
while i may agree with the first line, rest are little skewed perspective.
> People don’t like paying for software, demand constant updates and hate subscriptions.
hate subscription?? may be. if it's anything like Adobe then yes, people will hate.
that constant update, is something planted by these corporates, and their behavior manipulation tactics.
People were happily paying for perpetual software, which they can "own" in a cd//dvd.
People weren't happily paying, there was huge pirate business that was run on porn, gambling ads and spyware revenue. Then there were organizations with lots of lawyers paid by the "pay once use forever" companies to enforce the pay part because people didn't want to pay.
One time fee software ment that once your growth slows down you no longer make money and have plenty of customers to support for free. That's why this model was destroyed by the subscription and ad based "free" software.
The last example is Affinity which was the champion of pay once use forever model, very recently they end up getting acquired and their software turned into "free" + subscription.
It wasn’t one time fee though.
The one time fee bought a copy of the software and its patches.
A couple of years later a new version would come out and people had the choice between keeping using the old version or buying the new one.
To convince people to buy they had to add genuinely useful features. I would have bought a new version with new features and better performance. I wouldn’t have bought a new version same as the previous one with AI crammmed in it
The long tail of the web, likely consisting of mostly small or noncommercial sites, are currently numerically huge but individually low traffic. Meanwhile, user attention is dominated by a relatively small set of commercial and platform sites.
That was ine inception age when very few people were online, its not the stage of mass adoption. The mass adoption starts with the dot.com era with mass infrastructure build up.
But sure, if you think that we should start counting from these years you can do that and add a "public funded" era at the beginning.
I came to the web after dotcom and most of the content (accessibke trough search) was blogs and forums. It wasn’t until SEO that fake content started to grow like weeds.
There were companies that were making some money but those were killed or acquired by companies that give their services for free. Google killed the blogs by killing their RSS reader since they were long into making money stage and their analytics probably demonstrated that it is better people search stuff than directly going to the latest blog posts.
It's the same thing everywhere, the whole industry is like that. Uber loses money until there's no longer viable competition then lose less money by jacking up the prices. The tech is very monopolistic, Peter Thiel is right about the tech business.
The existing online mass is what attracted the VC in the first place, same as it ever was. It was mostly privately funded and very much a confederacy (AOL vs Prodigy vs BBS) at the time, much like now.
If a time comes when there are zero free browser with effective ad-blocking, it will create space for a non-free browser that does it. It would create a whole ecosystem.
I currently pay zero for ad-blocking (FF + uBlock Origin) and it works perfectly; but I would pay if I had to.
I think they are trying to balance it between making as much as money possible, risking being sued for monopolistic practices and risking exodus. Microsoft once overplayed their hand and the anger and consumer dissatisfaction was so strong that people left Internet Explorer en masse.
So the best situation for google would be to have borderline monopoly where they pay for the existence of their competition and the competition(Firefox) blocks adblockers too by default but leaving Chrome and Firefox is harder than forcing installin adblockers through the unofficial way.
So basically, all the people who swear they never clicked ads manage to block ads, Firefox and Chrome print money by making sure that ads are shown and clocked by the masses.
The only reason Mozilla matters in the eyes of Google is because it gives the impression there's competition in the browser market.
But Firefox's users are the kind who choose the browser, not use whatever is there. And that choice is driven in part by having solid ad-blockers. People stick with Firefox despite the issues for the ad-blocker. Take that away and Firefox's userbase dwindles to even lower numbers to the point where nobody can pretend they are "competition". That's when they lose any value for Google.
Without the best-of-the-best ad-blocking I will drop Firefox like a rock and move to the next best thing, which will have to be a Chromium based browser. I'll even have a better overall experience on the web when it comes to the engine itself, to give me consolation for not having the best ad-blocker.
It might be financial beneficial once as an up-front payment,
but long term, as others have mentioned, really not good for the project to remove the only feature that gives firefox a defensible way to fill it's niche in the market.
> Quite the opposite is true (I believe) since a ton of users would leave Firefox for alternatives.
Yes but keep in mind that’s not an individual problem that is solved by switching browsers. If a browser engine dies, the walls get closer and the room smaller. With only Chromium and WebKit left, we may soon have a corporate owned browsers pulling in whatever direction Google and Apple wants. I can think of many things that are good for them but bad for us. For instance, ”Web Integrity” and other DRM.
I think people like to imagine it's not viable because the most commonly known adblocker refuses to release the version for it. Negative news somehow stick better.
Fortunately it's not the only one and for example Adguard works perfectly fine.
Maybe, maybe not. It's getting dangerously close to the modern day IE, where some websites just don't work right and everyone has to do arcane shit to make their websites cross platform.
It's also a closed source browser developed by Apple. It's not competing with Firefox. Everyone contemplating switching to safari over Firefox are not being honest - they're not even on the same playing field.
> It's getting dangerously close to the modern day I.E.
This line gets thrown around a lot, but if you look at the supported features, Safari is honestly pretty up-to-date on the actual ratified web standards.
What it doesn't tend to do is implement a bunch of the (often ad-tech focused) drafts Google keeps trying to push through the standards committee
The only way you can possibly view Safari as "the modern day IE" is if you consider the authoritative source for What Features Should Be Supported to be Chrome.
You should probably think about that for a bit, in light of why IE was IE back in the day.
> The only way you can possibly view Safari as "the modern day IE" is if you consider the authoritative source for What Features Should Be Supported to be Chrome.
No. Safari is the modern IE in the sense that it's the default browser on a widely used OS, and it's update cycle is tied to the update of the OS itself by the user, and it drags the web behind by many years because you cannot not support its captive user-base.
It's even worse than IE in a sense, because Apple prevents the existence of an alternative browser on that particular OS (every non-safari OSes on iOS are just a UI on top of Safari).
But this can only be by comparison to something. And Apple is very good at keeping Safari up to date on the actual standards. You know—the thing that IE was absolutely not doing, that made it a scourge of the web.
So if it's not Chrome, what is your basis for comparison??
> But this can only be by comparison to something.
The something being the other browsers. Chrome and Firefox. Safari was even behind the latest IE before the switch to Chromium by the way.
> the thing that IE was absolutely not doing, that made it a scourge of the web.
You're misremembering, IE also kept improving its support for modern standards. The two main problems were that it was always behind (like Safari) and that it people were still using old versions because it was tied to Windows, like Safari with iOS. When people don't update their iPhone because they know it will become slow as hell as soon as you use the new iOS version on an old iPhone or just because they don't want their UI to change AGAIN, they're stuck on an old version of Safari.
I'm sorry, but you're wrong. I am not remotely misremembering, and I'll thank you not to tell me what's happening in my own head.
IE 6 stood stagnant for years, while the W3C moved on without them, and there was no new version.
> The something being the other browsers. Chrome and Firefox.
And can you name a single thing Firefox does right, that Chrome didn't do first, or that came from an actual accepted web standard (not a proposal, not a de-facto standard because Chrome does it), that Safari doesn't do?
The reason why IE 6 kept haunting us all was because later versions were never available on Windows XP.
> actual accepted web standard
The only thing for which there is an actual standard that matters is JavaScript itself (or rather ECMAScript) and on that front Apple has pretty much always been a laggard.
Saying “Apple is compliant with all of W3C standards” is a bit ridiculous when this organization was obsolete long before Microsoft ditched IE. And Apple itself acknowledge that, themselves being one of the founding parties of the organization that effectively superseded W3C (WHATWG).
> The reason why IE 6 kept haunting us all was because later versions were never available on Windows XP.
First of all, according to the IE Wikipedia page, that's not true—7 & 8 were available for XP.
Second of all, this ignores the fact that for five years, there was only IE6. And IE6 was pretty awful.
> Saying “Apple is compliant with all of W3C standards” is a bit ridiculous when this organization was obsolete long before Microsoft ditched IE. And Apple itself acknowledge that, themselves being one of the founding parties of the organization that effectively superseded W3C (WHATWG).
And now you have identified a major component of the problem: in the 2000s, the W3C was the source of web standards. Safari, once it existed, was pretty good at following them; IE (especially IE6) was not.
Now, there effectively are no new standards except for what the big 3 (Safari, Chrome, and Firefox) all implement. And Firefox effectively never adds new web features themselves; they follow what the other two do.
So when you say "Safari is holding the web back," what you are saying is "Safari is not implementing all the things that Google puts into Chrome." Which is true! And there is some reason to be concerned about it! But it is also vital to acknowledge that Google is a competitor of Apple's, and many of the features they implement in Chrome, whether or not Google has published proposed standards for them, are being implemented unilaterally by Google, not based on any larger agreement with a standards body.
So painting it as if Apple is deliberately refusing to implement features that otherwise have the support of an impartial standards body, in order to cripple the web and push people to build native iOS apps, is, at the very best, poorly supported by evidence.
I prefer Firefox over Chromium. But I much more prefer having a working ad blocker. Therefore I support that statement and when Firefox starts removing support for that, I'm out and there's enough alternatives I can go to, even tho they're Chromium based.
I use the Duck Duck Go browser for almost everything. I is open source for iOS/Android/macOS platforms, but I think there are parts of their platform that are not. The DDG browser hits all my privacy requirements.
Apple doesn't collect your browsing data, they build in privacy controls that are pretty much as strong as they can manage given the state of the world, and while it doesn't support uBO, it supports a variety of pretty solid adblockers (I use AdGuard, which, AFAICT, Just Works™ and even blocks YouTube ads most of the time, despite their arms race).
That's what their marketing want you to believe, at least.
Their privacy policy is very clear it's not the case though:
> we may collect a variety of information, including:
> […]
> Usage Data. Data about your activity on and use of our offerings, such as app launches within our services, including browsing history; search history;
And users would flee not just because they're seeing the ads but because Firefox is obviously the slowest browser again. Stripping the ads is a big performance boost, so right now Firefox feels snappier than Chrome on ad-laden pages.
You can't even imagine how little the rest of the world cares about this.
Do people in California care that slightly under 50% of my state's population are at or below poverty level? Do they care that most of the rest spend 55-60% of our income on food? Do they care that our life expectancy is 15 years lower than that in California, mostly because of terrible pollution caused by extraction and processing of minerals which our beloved government then sells to the US and several European countries, and pockets the money?
Do they care about conflict minerals in general, used to build electronics for their enjoyment? Have they done anything about this?
This American political bickering does not even register on our radars when choosing a web browser.
"Europe's problems are the world's problems but the world's problems are not Europe's problems.", as India's Mr. Jaishankar is fond of saying.
Wasmtime, being an optimizing JIT, usually is ~10 times faster than Wasmi during execution.
However, execution is just one metric that might be of importance.
For example, Wasmi's lazy startup time is much better (~100-1000x) since it does not have to produce machine code. This can result in cases where Wasmi is done executing while Wasmtime is still generating machine code.
> Every iteration of the loop polls the network and input drivers, draws the desktop interface, runs one step of each active WASM application, and flushes the GPU framebuffer.
This is really interesting and I was wondering how you implemented that using Wasmi. Seems like the code for that is here:
> It might interest you that newer versions of Wasmi (v0.45+) extended the resumable function call feature to make it possible to yield upon running out of fuel:
That is really interesting! I remember looking for something like that in the Wasmi docs at some point but it must have been before that feature was implemented. I would probably have chosen a different design for the WASM apps if I had it.
I am really sorry I have waited so long to extend Wasmi's resumable calls with this very useful feature. :S
Feel free to message me if you ever plan to adjust your design to make use of it.
Not OP, but I'm confused how this would be helpful. You're saying for example, he can use this function to create a coroutine out of a function, begin it, and if the function fails by e.g. running out of memory, you can give the module more memory and then resume the coroutine? If so, how is that different than what naturally happens? Does wasm not have try/catch? Also, wouldn't the module then need to back up manually and retry the malloc after it failed? I'm so lost.
Wasmi's fuel metering can be thought of as is there was an adjustable counter and for each instruction that Wasmi executes this counter is decreased by some amount. If it reached 0 the resumable call will yield back to the host (in this case the OS) where it can be decided how to, or if, the call shall be resumed.
For efficiency reasons fuel metering in Wasmi is not implemented as described above but I wanted to provide a simple description.
With this, one is no longer reliant on clocks or on other measures to provide each call its own time frame by providing an amount of fuel for each Wasm app that can be renewed (or not) when it runs out of fuel. So this is useful for building a Wasm scheduler.
Wasmtime's epoch system was designed specifically to have a much, much lower performance impact than fuel metering, at the cost of being nondeterministic. Since different embeddings have different needs there, wasmtime provides both mechanisms. Turning epochs on should be trivial if your system provides any sort of concurrency: https://github.com/bytecodealliance/wasmtime/blob/main/examp...
I don't know how fuel metering in Wasmtime works and what its overhead is but keep in mind that Wasmi is an interpreter based Wasm runtime whereas Wasmtime generates machine code (JIT).
In past experiments I remember that fuel metering adds roughly 5-10% overhead to Wasmi executions. The trick is to not bump or decrease a counter for every single executed instruction but instead to group instructions together in so-called basic blocks and bump a counter for the whole group of instructions.
This is also the approach that is implemented by certain Wasm tools to add fuel metering to an existing Wasm binary.
This is really cool stuff. I've always wanted fuel-based work with a high level programming languages. Having a language compile to wasm with wasmi now seems like a nice way to achieve that.
I first encountered this with gas in the Ethereum VM. For Ethereum, they price different operations to reflect their real world cost: storing something forever on the blockchain is expensive whereas multiplying numbers is cheap
I’m not sure what it’s used for in this context or how instructions are weighted
Let's consider that you create a serverless platform which runs wasm/wasi code. The code can do an infinite loop and suck resources while blocking the thread that runs the code in the host. Now, with a fuel mechanism the code yields after a certain amount of instructions, giving the control back to the host. The host can then do things such as stop the guest from running, or store the amount of fuel to some database, bill the user and continue execution.
Thanks! I have lots more too. Are there directions in space? What kind of matter is fire made of? If you shine a laser into a box with one-way mirrors on the inside, will it reflect forever? Do ants feel like they're going in regular motion and we're just going in slow motion? Why do people mainly marry and make friends with people who look extraordinarily similar to themselves? How do futures work in Rust? Why is the C standard still behind a paywall? Let me know if you need any more great questions.
Flame is what you see when gases burn in the air. As the material burns, it breaks down and releases flammable gases, which burn too, giving the effect of flame. If you have ever tried burning fine-grade steel wool, you will have seen that it burns without any flame because the iron burns directly without making gases first.
"If you shine a laser into a box with one-way mirrors on the inside, will it reflect forever?"
No, because each reflection comes at a cost (some light transformed to heat)
"Why do people mainly marry and make friends with people who look extraordinarily similar to themselves?"
To not get so much surprises and have a more stable life. (I didn't choose that path.)
(But I feel it would be too much OT answering the other questions and don't want to distract from this great submission or the interesting Wasmi concept)
No, I do not accept this. There must be a way. What if the mirror box has a high enough heat? Would it work then? The box could be made of a heat resistant material, like fiberglass.
It's not that the mirror or box is damaged by heat, it's that each bit of heat energy comes from a bit of light energy. Eventually the light bounces enough times that there's no energy left in it.
I understand, but what I mean is, what if there is no more opportunity for the light to emit heat, because the surrounding environment is already saturated with so much heat that it can't accept more? Is this a possible way to prevent the light from emitting heat and therefore prevent the light from decreasing its luminousness? There must be a way!
A few notes:
* There's no such thing as "absolute hot" state that meansno more heat can be added
* Blackbody radiation means that above a certain temperature, regardless of what you make your mirror out of, it will be spontaneously emitting visible light at all times.
Indeed. There is only an absolute zero, that cannot get colder, but more heat is always possible as more heat means more rapid movement of elements. While absolute zero at 0 K means no movement.
Basically, what you propose negates the nature of reality. There is always friction/energy loss into heat (increased chaotic movement). Only way to deal with it, if you want permanent cycles, is constantly add energy in the same amount that is lost.
It's awesome that Wasmi is fast enough to run GUI apps. I'm working on an app runtime for making highly portable GUI apps. I'm targeting wasm because it seems to strike a good balance between performance and implementation simplicity. Ideally it would be possible to run apps on a runtime hacked together by a small team or even a single person. The fact that an interpreted (if highly optimized) wasm runtime like Wasmi is clearly capable of running GUI apps is exciting.
Thank you! And thanks for making Wasmi, it's a really impressive project and it's the reason why I decided to go this whole WASM sandbox route (because I could embed it easily) :)
Yeah it's one of those projects were I'm so impressed that I'm saying nothing because there's nothing to say, it's just really impressive. I'm not sure what will come of this project, but it has a lot of potential to at least inspire other projects or spark important discussions around its innovations.
reply