From digging, it looks like the issue here (or one of the issues) is that the Web Assembly encoding for some Lisp uses cases (multiple value return) is not very compact. Making the proposed change would presumably reduce the size of Lisp code once compiled to Web Assembly, it would not really affect the behavior of the program once compiled to native code.
I can relate to the Web Assembly team's reluctance to add features which are only really wanted by a small subset of users, especially when they only affect the binary size. These features, if implemented, may suffer from poor test coverage. My own preference is that compact binaries are nice but if you're going to use a high-level language, an increase in binary size is just expected (say, an order of magnitude) unless the encoding/VM and language were designed in concert (Java + JVM, or C# + CIL are two examples). Heck, C++ binaries can be enormous.
Then again, I didn't dig deep enough to really understand the nuances of the argument. Perhaps someone could elaborate.
The target prevails over the language. The implicit intent is to convert LLVM bitcode.
"Please keep in mind that Wasm is not a user-facing language, it is a compilation target. To justify the extra complexity of this feature for its own sake, you would need to come up with convincing evidence that compilers would significantly benefit from it. I doubt that."
Why are you talking about SBCL here? This is not for the benefit of SBCL, which does not target Web-Assembly, but about implementing multiple return values easily. Yes not many languages have multiple return values today, but Web Assembly should not only focus on implement only the languages that are popular today but the languages of the future.
From what I understand, it really is just Lisp, not any language with multiple return values. The issue here is Lisp semantics for multiple return values being slightly cumbersome (but by no means difficult).
This is not only about code size, but about efficiency and, more fundamentally, about what multiple values are. Are MRV just syntactic sugar around lists, a second-class mechanism ("tuples don't nest") for when you have zero-or-one return value, or a first-class feature which can benefit from the support of the runtime compiler?
The last time you discussed about this[0], you attributed to Common Lisp some problems that were present with Scheme's multiple values.
And here, as explained in this thread, Wasm is not a user-facing language but the target of compiler, which means that the usual complaints about the somewhat verbose binding constructs of CL's values (which I find acceptable as a user) are not a problem either, since the code ought to be generated from other languages (which might even not define multiple values themselves, but for which a compiler could generate code that use MVR).
It seems that the only acceptable way to produce multiple values for you is to return a composite value. I think that having a dedicated type to represent multiple values is a useful tool to give to the programmer.
You can think that. I disagree. That's fine. Good on you.
And yes, I did mis-attribute some problems with Scheme's implementation of MVR to common lisp. However, I admitted to the mistake in that thread, and eventually got the idea.
So please, don't confuse the issue. Here, I'm not talking just about lisp. I just don't like MVR in general. And yes, I think that a composite value is the only good way to produce multiple values. But I don't have an objection to WASM adding MVR, because it's compiler facing, as you pointed out. I object to higher lever languages adding it.
Not really, aside from smaller binary size parsing a binary bytecode vs parsinga a JS pseudo bytecode is a huge difference in load time + they get to optimize it for efficient translation vs trying to hack JS constructs to get desired semantics and then trying to recognize those in the JIT
Asm.js is a hack made with ducktape and chewing gum, wasm is a solution designed/engineered to solve the general problem - not just smaller asm.js
ASM.js builds can be quite large, even 10s of MB is not uncommon. Reducing the binary size isn't just "nice to have", it changes the viability of the platform.
I don't think anyone is arguing that binary size isn't relevant. It just has to be weighed against the other parameters we want to optimize, like implementation complexity.
Any way to reconcile power-of-two memory structure and boundary checks? I can't imagine all code should be constrained to power-of-two memory, but if you throw in multi-threading somehow, I think it would start making more sense to have the best of both worlds.
My knowledge of LLVM an SBCL is limited but I know a bit emscripten and how it works. I will look around "multivalues" and "power of two memory access" in LLVM.
Actually getting the support of other language communities would be even more useful. If you can find use-cases of the feature for other languages then it's going to be much more compelling.
The memory allocation feature feels more like it would be part of whatever memory allocation library is used than something that should be baked into the language. For example, jemalloc allows for the kind of alignment that is discussed here and is done at runtime, and doesn't require specific behavior from the lower levels. Any language is going to need a runtime because you can't put in every feature that every user will need, and a malloc doesn't seem like a huge issue, especially with one already written that an implementation can crib from.
Memory allocation feature asked is not a language feature. It has to be baked into web assembly if you want to use portable byte masking with pointers.
It's very low level implementation level detail that enables fast execution of dynamically typed languages. Boxing has high cost and it consumes memory. Type tags embedded in pointers can be very fast. For that to work, you need objects that are aligned with power-of-two byte boundaries.
Adding this feature enables efficient execution strategy for scripting and dynamic languages.
The primary target of WebAssembly is strongly-typed pre-compiled languages, where the kinds of features you want would just lead to slowdowns and excessive memory consumption. There is no hardware currently out there that is a tagged architecture, so expecting them to bend backwards is not a realistic option.
> The mission of this group is to promote early-stage cross-browser collaboration
on a new, portable, size- and load-time-efficient format suitable
for compilation to the web.
This is a collaborative work where people can make suggestions (I cannot judge if the proposal was fairly evaluated or not).
> WebAssembly team doesn't want to listen my ideas on how WebAssembly should work.
Your title implies that the WebAssembly team has the best knowledge and/or expertise to develop WebAssembly. They are probably expert in their own domain but are willing to take advice from other contributors.
"This masking strategy would in turn require a power-of-two related memory size, and there has been a lot of resistance to this too."
And try to think about the implications it has on the memory model of the VM that is going to execute/JIT Webassemly.
A power of two memory model, isn't really viable at this level I think. And you don't need to think a lot about it, to figure out that jumping to 256MB memory, just because your app/page needs 130MB is a bit of counter-optimization :)
The resistance is the sensible thing to do in this case :)
BTW, language implementations which rely on LLVM for code generation would get it for free. Well, for much less pain.
BTW2, time to appreciate how LLVM's approach is superior to JVM madness/religion (and how Golang's is even more clever - do less by doing it right - essentiaistic/minimalistic ascetism)
Modern CPU+OS is a good-enough hardware VM and a target platform. Process isolation under an OS is a right level of abstraction.
A VM as user-level OS process which tries to do an OS job and reimplement everything inside a VM is simply ridiculous. Javascript follows the same madeness.
Multi-threading for imperative code is a big mistake, which breaks isolation and results in lock-hell, context-switching nightmare and layers of unnecessary complexity which is impossible to reason about.
At cost of wasting of almost as much resources that it serves.
Top is about popularity, not quality. Junk-food is also popular.
My analysis was about the first principles, not abstract ones, but grounded in reality. Those who got the principles right wins in the long run.
Erlang (where VM is not a byte-code interpreter), Golang, Haskell (except when monads are abused by idiots), etc are designs based on the right principles. Java was a primitive religion based on superstitions (the fear of pointers) from the start.
Performance on a simplified task is the least important metric.
BTW, it will be wonderful to see next to these charts "memory used" and "lines of code used, including all dependencies" columns. And "length of stack trace in kilobytes" of course.
Sorry, I didn't read this particular link. I have seen too many of them before. Principles are above particularities.)
Edit: an illustration - closer to real world example chart from the same site:
Let me illustrate the thesis about necessity of proper abstractions and principles grounded in reality in another way.
There are way too many cases of a meaningless bloatware in human history, including writings produced by Hegel, Marx and Engels. There are millions of people suffered because these graphomans have produced 4000+ pages of so-called [political] philosophy, full of pure abstractions, abstract concepts and meta-phisical design patterns. The shit doesn't fly, except for confusing minds of bunch of lesser idiots, which ruined whole nations afterwards.
On the other hands, there are writings after "down to earth" guys, such as Buddha or Christ, or to lesser extent, the guys who wrote Upanishads (which uses rather poetical language) which literally saved, or at least improved, billions of lives. In the realm of philosophy, guys like Tomas Hobbes and Adam Smith wrote much less pages and described some aspects of reality way better.
Piling up layers upon layers of disconnected from reality crap of wrong abstractions and dubious abstract principles, praised by brainwashed followers, especially because they are too bogus and too abstract, is a way to ruin.
I think it is not too hard to notice rather striking similarities.)
No. Not acceptable. You seem to have forgotten what a VM IS. It stands for VIRTUAL MACHINE. The idea is that you can run the VIRTUAL MACHINE on top of ANY PHYSICAL ARCHITECTURE, and have the applications work, so long as the machine's basic assumptions are followed (i.e. there's some kind of I/O, and a screen capable of displaying graphics, for most of them). A well designed VM can be re-implemented anywhere, and have the software run on it just work. Just look at the Z-machine, or the squeak VM.
The problem with a modern CPU+OS as a VM is that it cannot be re-implemented on other hardware effectively. you can't pull a piece of software designed to run on the x86+unix "VM" and write a VM to make it run on ARM+Windows. Not fast, not in a way that you'd want to use. Try writing native code translation fast enough that you can run Quake3 without even noticing the difference. That's why VMs exist.
The original rationale for the JVM -- "write once, run anywhere" -- no longer exists since nobody downloads applets anymore.
The more sensible technology for making code run on multiple platforms still works quite well. It's called a compiler.
Not if you make OS specific syscalls. Your system has to account for the fact that not everybody runs on the same system. VMs do that, and do it far better than most compilers, when it comes to reliable cross-platform without doing a ton of re-writing.
> Multi-threading for imperative code is a big mistake, which breaks isolation and results in lock-hell, context-switching nightmare and layers of unnecessary complexity which is impossible to reason about.
Go is multithreaded and imperative. Sure, it has some nice concurrency features to help you untangle it, but all of the dangers of shared memory multithreading is right there.
…as is Swift with NSOperation/GCD. Apple's process isolation tech (XPC) is built upon their multithreading tech (GCD). The two are complementary, not antagonistic.
Doing multithreading on a runtime with automatic reference counting gc and expecting performance is nuts. Every reference assignment is a potential write contention.
It is possible to do it, even sensible when you need it for GUIs for example. Just don't expect it to use the hardware in a sensible manner.
I can relate to the Web Assembly team's reluctance to add features which are only really wanted by a small subset of users, especially when they only affect the binary size. These features, if implemented, may suffer from poor test coverage. My own preference is that compact binaries are nice but if you're going to use a high-level language, an increase in binary size is just expected (say, an order of magnitude) unless the encoding/VM and language were designed in concert (Java + JVM, or C# + CIL are two examples). Heck, C++ binaries can be enormous.
Then again, I didn't dig deep enough to really understand the nuances of the argument. Perhaps someone could elaborate.