Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hoot: Scheme on WebAssembly

spritely.institute

Post reply on HN
Print view View original

31–40 of 49 posts

Re: Hoot: Scheme on WebAssembly

#31

Post by shakna »

veqq wrote: post #24

It's fascinating how much development's occurring in Guile recently. Unfortunately, a lot seems to be ex-Racketers moving over. The splitting of community effort's sad (particularly as Guile e.g. greatly lags Racket performance or lacks nice libraries like Gauche).

> particularly as Guile e.g. greatly lags Racket performance

Huh. This has not been my experience, rather the other way around.

I do see a whole heap of benchmarks that contradict it, so I probably should put in some effort to find out why, or if I'm just plain wrong... But at a guess? Guile doesn't have Racket's startup time penalty, and most of what I do is IO bound - and Guile's IO story is better than Racket's.

Re: Hoot: Scheme on WebAssembly

#32

Post by HexDecOctBin »

veqq wrote: post #24

It's fascinating how much development's occurring in Guile recently. Unfortunately, a lot seems to be ex-Racketers moving over. The splitting of community effort's sad (particularly as Guile e.g. greatly lags Racket performance or lacks nice libraries like Gauche).

I didn't know there was a schism in Racket. Is this about the CS vs BC backend? I thought that was water under the bridge.

Re: Hoot: Scheme on WebAssembly

#35

Post by vanderZwan »

veqq wrote: post #24

It's fascinating how much development's occurring in Guile recently. Unfortunately, a lot seems to be ex-Racketers moving over. The splitting of community effort's sad (particularly as Guile e.g. greatly lags Racket performance or lacks nice libraries like Gauche).

I don't really follow Racket, but I recall that few years ago one apparently fairly significant contributor within their community wrote a blog post about Racket having a Missing Stair problem involving another even more significant (possibly foundational) contributor.

I'm a complete outsider, cannot find that blog post any more, and also just not invested in the language at all, so I'm hesitant draw conclusions about the validity of any of the accusations that were thrown back and forth at the time, but it seems pretty obvious to me that it's inevitable that the community will end up being split after an event like that.

https://en.wikipedia.org/wiki/Missing_stair

Re: Hoot: Scheme on WebAssembly

#36

Post by veqq »

vanderZwan wrote: post #35
veqq wrote: post #24

It's fascinating how much development's occurring in Guile recently. Unfortunately, a lot seems to be ex-Racketers moving over. The splitting of community effort's sad (particularly as Guile e.g. greatly lags Racket performance or lacks nice libraries like Gauche).

I don't really follow Racket, but I recall that few years ago one apparently fairly significant contributor within their community wrote a blog post about Racket having a Missing Stair problem involving another even more significant (possibly foundational) contributor. I'm a complete outsider, cannot find that blog post any more, and also just not invested in the language at all, so I'm hesitant draw conclusions abou…

https://alexalejandre.com/notes/criticisms-of-racket/ summarizes some such stories

Re: Hoot: Scheme on WebAssembly

#37

Post by amanwithnoplan »

shakna wrote: post #31
veqq wrote: post #24

It's fascinating how much development's occurring in Guile recently. Unfortunately, a lot seems to be ex-Racketers moving over. The splitting of community effort's sad (particularly as Guile e.g. greatly lags Racket performance or lacks nice libraries like Gauche).

> particularly as Guile e.g. greatly lags Racket performance Huh. This has not been my experience, rather the other way around. I do see a whole heap of benchmarks that contradict it, so I probably should put in some effort to find out why, or if I'm just plain wrong... But at a guess? Guile doesn't have Racket's startup time penalty, and most of what I do is IO bound - and Guile's IO story is better than Racket's.

https://ecraven.github.io/r7rs-benchmarks/

For the onlookers, this bunch of microbenchmarks suggests Racket is faster than Guile, but the fastest is Chez (which Racket uses as a substrate).

Re: Hoot: Scheme on WebAssembly

#38

Post by shakna »

amanwithnoplan wrote: post #37
shakna wrote: post #31

Earlier quoted context omitted.

> particularly as Guile e.g. greatly lags Racket performance Huh. This has not been my experience, rather the other way around. I do see a whole heap of benchmarks that contradict it, so I probably should put in some effort to find out why, or if I'm just plain wrong... But at a guess? Guile doesn't have Racket's startup time penalty, and most of what I do is IO bound - and Guile's IO story is better than Racket's.

https://ecraven.github.io/r7rs-benchmarks/ For the onlookers, this bunch of microbenchmarks suggests Racket is faster than Guile, but the fastest is Chez (which Racket uses as a substrate).

Yeah, know of it. But no IO, filesystem, network or otherwise. Never found it altogether great as an actual benchmark other than for raw computation.

Not bad at comparing compilers and optimisation. Great for checking R7RS compliance. Not what I'd trust to make decisions with.

Re: Hoot: Scheme on WebAssembly

#39

Post by davexunit »

geon wrote: post #33

repl.wasm is 1.6 MiB Seems a bit much. How large would the todo example be?

This is not the smallest REPL binary out there but it's far from the largest I've seen. My anecdotal evidence suggests it's somewhere in the middle or maybe smaller than average. We haven't configured our web server to gzip these assets (we should). Gzipped repl.wasm is 339K. This binary hasn't been run through wasm-opt, either.

Hoot is primarily an ahead-of-time compiler, not an interpreter, so this REPL demo has a lot of stuff that a production binary wouldn't have like a macro expander, runtime module system, and an interpreter. A significant chunk of extra code. We have a todo list example [0] in a separate repo, btw. On my machine, todo.wasm is 566K uncompressed, 143K gzipped. And that includes a virtual DOM diffing algorithm implemented in Scheme.

That said, there is quite some room to optimize binary size. For example, we know we're generating too many local variables in functions [1], many of which could be optimized away with an additional compilation pass. We expect that to have a significant impact on binary size. There's also certain workarounds we're doing due to features missing from Wasm at the time of implementation that add to total binary size. Lack of native stack switching for continuations is one example. Adopting the stack switching proposal should shave off some bytes.

[0] https://codeberg.org/spritely/hoot-ffi-demo/

[1] https://codeberg.org/spritely/hoot/issues/193

Re: Hoot: Scheme on WebAssembly

#40

Post by davexunit »

shakna wrote: post #38
amanwithnoplan wrote: post #37

Earlier quoted context omitted.

https://ecraven.github.io/r7rs-benchmarks/ For the onlookers, this bunch of microbenchmarks suggests Racket is faster than Guile, but the fastest is Chez (which Racket uses as a substrate).

Yeah, know of it. But no IO, filesystem, network or otherwise. Never found it altogether great as an actual benchmark other than for raw computation. Not bad at comparing compilers and optimisation. Great for checking R7RS compliance. Not what I'd trust to make decisions with.

That's how I see it, too. I used these benchmarks early in Hoot's development as a rough measure of r7rs compliance and only occasionally as a guide for improving performance. I never published my results but I had Hoot passing more of the benchmarks than Guile itself, which I found funny.
Post reply on HN