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

Tree-shaking, the horticulturally misguided algorithm (2023)

wingolog.org

Post reply on HN
Print view View original

141–150 of 151 posts

Re: Tree-shaking, the horticulturally misguided algorithm (2023)

#141

Post by dwoldrich »

wizzwizz4 wrote: post #66
dwoldrich wrote: post #58

My philosophy is to work hard at optimizing my javascript with algorithms and design simplifications for size/performance to make room (in bundle size and CPU) for parts of my code that require brute force compute to solve. In my ClubCompy project, I use WASM to implement a FAT filesystem atop local storage, which has proven to be very computationally expensive. And, I plan to use WASM for pixel-perfect sprite collis…

1fps is the kind of frame rate you should be getting with 20000 collisions, not 256. Your algorithm is the bottleneck, here, not the programming language. You say "pixel-perfect". If you have enough spare memory, one simple algorithm would be: render an offscreen canvas of the whole arena, draw each sprite as a stencil in a different colour, and test against that. Linear time, and no need to segment anything. (You mi…

True, many factors at play.

The last time this code ran was in 2012, and computers and JS engines were slower then.

Also, my Comfy language interpreter is easy to bog down with sprite signal processing. The only cure for that is improving interpreter performance. I need it to run good on tablets and phones, lots of tuning to do in general.

I like your algorithm idea! Stensils are indeed a fast way to work. I think I'll still do better on a worker thread with bit swizzling in the CPU rather than reading back stencil video memory. I'll have to spike it.

Re: Tree-shaking, the horticulturally misguided algorithm (2023)

#142

Post by remexre »

dartos wrote: post #131
crabmusket wrote: post #125

Earlier quoted context omitted.

> 1. avoid floats (fixed point arithmetic saved quite a bit of space) This is really interesting, since WASM has built in float types of course - is there any more detail you can go into / examples you can show us? I have a problem at work where I was thinking fixed point arithmetic might help, because I know my maximum resolution needs (e.g. I know the problem will never care about sub-millimetre positioning). I'd b…

They said why right there. Floating point numbers take up more space in memory and can only store smaller values than internet.

Are you sure they're not talking about code size? Not sure what limiting instantiations would have to do with heap size...

(I also find it surprising that avoiding floats helps anything; maybe just in avoiding more instantiations? Because if the std floating point functions don't fully inline, you've got bigger problems than wasm blob size...)

Re: Tree-shaking, the horticulturally misguided algorithm (2023)

#143

Post by jonnycomputer »

lxgr wrote: post #85
jonnycomputer wrote: post #76

Earlier quoted context omitted.

Lot I don't know about how browsers are shipped, but it seems to me like browsers could easily get away with packing in a few languages and their STLs as part of their default installs. Python is what, 25MB? Would another couple hundred megs of disk space be such a big deal?

Possibly – if you can find a single version of Python that everybody will be happy with, forever. Being able to cache runtimes and libraries like that across sites would be nice, though (but probably enables fingerprinting, so one Python runtime per origin it is).

Fair point. I didn't think of that.

Re: Tree-shaking, the horticulturally misguided algorithm (2023)

#144

Post by p_l »

gardenhedge wrote: post #81
sroussey wrote: post #31

Why did tree shaking as a phrase come to exist when “dead code elimination” had been around forever?

I like dead code elimination much better.

Tree-shaking originated because it wasn't just about unreachable code, but also all other kinds of data in a live image.

Re: Tree-shaking, the horticulturally misguided algorithm (2023)

#145

Post by paulddraper »

naasking wrote: post #63
em-bee wrote: post #46

Earlier quoted context omitted.

dead branches and loose leaves are connected to a real tree in the same way that dead code is connected to the program in a file. if you break off the dead branch, nothing happens to the tree, just like when you remove unused code, nothing happens to the program.

> if you break of the dead branch, nothing happens to the tree, just like when you remove unused code, nothing happens to the program. Indeed, and this has been known since the 80s as dead code elimination. So why are we using a new, less descriptive, more confusing term again?

IDK why language evolves.

It's more succient I suppose

Re: Tree-shaking, the horticulturally misguided algorithm (2023)

#146

Post by konstantinua00 »

torgoguys wrote: post #90
SkyPuncher wrote: post #28

Earlier quoted context omitted.

Many things in software are misnomers. Personally, I think it’s an amazing name. The first time I saw the term, I knew exactly what it was without any further research. You shake a tree to remove the loose things. In this case, it was clear that unused packages are being “shaken” from the tree.

The reason I didn't like the name when I first came across it is that I think of shaking the tree for harvesting the fruit. The fruit is what you want, not what you want to eliminate. But it's an ok term overall.

funny, but my life experience showed that fallen apples get damaged and rot faster

and shaking pine tree always showered me with dried needles

so I didn't even think about "shaking for the fruit" association xD

Re: Tree-shaking, the horticulturally misguided algorithm (2023)

#147

Post by __s »

remexre wrote: post #142
dartos wrote: post #131

Earlier quoted context omitted.

They said why right there. Floating point numbers take up more space in memory and can only store smaller values than internet.

Are you sure they're not talking about code size? Not sure what limiting instantiations would have to do with heap size... (I also find it surprising that avoiding floats helps anything; maybe just in avoiding more instantiations? Because if the std floating point functions don't fully inline, you've got bigger problems than wasm blob size...)

I'm talking about code size. Wasm has efficient encodings for small integers, but constants for floats always take up 5/9 bytes

Re: Tree-shaking, the horticulturally misguided algorithm (2023)

#148

Post by titzer »

layer8 wrote: post #65
titzer wrote: post #2

Tree-shaking is such a bad misnomer. Virgil's compiler calls this "reachability analysis" and it's built into the compilation model. The compiler will parse and typecheck a program's (and libraries' code), and run initializers, but after that the compilation proceeds by exploring from the main entrypoint(s) and only reachable code is analyzed and ends in the final binary. It will happily generate a program (without r…

The correct general term is “dead-code elimination” [0]. Reachability analysis is commonly used do determine what code can be removed, but other methods are possible, and the analysis by itself doesn’t remove any code, that’s a subsequent step. “Tree-shaking” as commonly used implies that the granularity of the removal is functions, whereas dead-code elimination can generally be at arbitrarily fine levels, for exampl…

FWIW, the reachable analysis in Virgil eliminates not only dead code, but dead fields, objects, metadata, etc. It's not just code.

Re: Tree-shaking, the horticulturally misguided algorithm (2023)

#149

Post by crabmusket »

__s wrote: post #147
remexre wrote: post #142

Earlier quoted context omitted.

Are you sure they're not talking about code size? Not sure what limiting instantiations would have to do with heap size... (I also find it surprising that avoiding floats helps anything; maybe just in avoiding more instantiations? Because if the std floating point functions don't fully inline, you've got bigger problems than wasm blob size...)

I'm talking about code size. Wasm has efficient encodings for small integers, but constants for floats always take up 5/9 bytes

Oh I see! Was this the main benefit, not the use of fixed point algorithms?

Re: Tree-shaking, the horticulturally misguided algorithm (2023)

#150

Post by yencabulator »

ElectricSpoon wrote: post #4

> Wasm makes it thinkable to do DOM programming in languages other than JavaScript Does it really? AFAIK, if I want to do any kind of DOM manipulation in say, rust, I need bindings that will basically serialize calls to be done on the JS side. So with the current incarnation of wasm, I believe you're still stuck with JS.

As far as I understand:

The intent of WASI is to provide (among other things) a direct to DOM API. One where e.g. a DOM implemented in Rust can be used from a WASM module written in Rust without executing any Javascript.

Some of that gets fiddly because the DOM API is sort of specified with Javascript semantics.. so they're going for things with less Javascript legacy baggage first, like HTTP requests (server & client), TCP sockets, filesystem access.

Post reply on HN