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

The Glimmer VM: Boots Fast and Stays Fast

yehudakatz.com

Post reply on HN
Print view View original

41–50 of 92 posts

Re: The Glimmer VM: Boots Fast and Stays Fast

#41

Post by lightblade »

curveship wrote: post #37
ibdknox wrote: post #7

Earlier quoted context omitted.

In this particular case, I believe there are 3 reasons: 1) Size - turning each op into a couple of bytes means that the size of your template is significantly smaller. If each instruction is 4 bytes, I could get ~20 instructions in the space of just one function with a setAttribute call: function t(e) {e.setAttribute("id", "bar")} Size is much more important on the web than it is in other places especially as the nex…

For 1) and 2), some frameworks solve the size issue by creating functions for the basic DOM ops, which then get minimized to single character names in production. So in your example, there might be a setNodeAttribute(node, name, val) function, such that the final code isn't `e.setAttribute("id", "bar")` but just `a(e,"id","bar")`, where `a` is the minimized name of setNodeAttribute. There's really not much noise in t…

Well, Glimmer actually compiles opcodes to just numbers. So it wouldn't be `a(e,"id","bar")`, it's actually [1,'id','bar']. Opcodes' wire format is an array. I haven't see it being a tree yet. If this is the case, stream parsing is definitely possible.

Re: The Glimmer VM: Boots Fast and Stays Fast

#42

Post by ibdknox »

lightblade wrote: post #41
curveship wrote: post #37

Earlier quoted context omitted.

For 1) and 2), some frameworks solve the size issue by creating functions for the basic DOM ops, which then get minimized to single character names in production. So in your example, there might be a setNodeAttribute(node, name, val) function, such that the final code isn't `e.setAttribute("id", "bar")` but just `a(e,"id","bar")`, where `a` is the minimized name of setNodeAttribute. There's really not much noise in t…

Well, Glimmer actually compiles opcodes to just numbers. So it wouldn't be `a(e,"id","bar")`, it's actually [1,'id','bar']. Opcodes' wire format is an array. I haven't see it being a tree yet. If this is the case, stream parsing is definitely possible.

You could do even better than this if you wanted. Since there are only between 100-200 dom attributes, you can pack that into the opcode itself. Assuming 6 bits for the opcode (64 ops) and 8 bits for the dom attribute (256 attrs), you still have another 18bits to play with in a 32 bit int. If you wanted to allow arbitrary attributes, you could dictionary encode them and then use the full 26 bits for a total of 67M possible attribute names. Alternatively, you can reduce that entire op down to just the opcode by dictionary encoding the operand and packing that in as well. How many programs have more than 262,000 static strings? :)

Compared to the string encoding above we went from 14 chars (1-4 bytes each, we'll just say 2) at 28 bytes to 4 bytes for our 32 bit int.

Re: The Glimmer VM: Boots Fast and Stays Fast

#43

Post by hl5 »

analognoise wrote: post #6

Isn't this just re-solving a decades old problem, with the (unnecessary) constraints caused by modern web systems?

It used to be called mail merge. Now that there are so many abstractions layers, it's apparently best performance wise if you add a VM running inside a VM running inside a VM.

Re: The Glimmer VM: Boots Fast and Stays Fast

#45

Post by bluepnume »

I'm a big fan of what I'm seeing in Glimmer so far. I had fun adding support for xcomoponent yesterday, making Glimmer components work as cross-domain components.

https://medium.com/@bluepnume/introducing-support-for-cross-...

I'd love it if it were a little more flexible to get started with though. Rather than fire up ember-cli, I'd love to just be able to:

1. Load glimmer.js from a CDN

2. Extend glimmer.Component

3. Render my component into an element

I know ember-cli solves this problem for a lot of users, but I'd love for the number of steps to get a "hello world" working to be as simple as the above. I think that's one of the reasons React has been so successful: it's stupid-simple to get started with, and it draws you in from there.

Re: The Glimmer VM: Boots Fast and Stays Fast

#46

Post by pjmlp »

pcwalton wrote: post #39
astrobe_ wrote: post #38

Earlier quoted context omitted.

Smalltalk?

Smalltalk isn't native!

It is a matter of implementation.

It was native on the Alto, as the primitives were implemented in microcode, which could be a FPGA nowadays.

Also Squeak and Pharo are implemented in Smalltalk.

Re: The Glimmer VM: Boots Fast and Stays Fast

#47

Post by ibdknox »

curveship wrote: post #37
ibdknox wrote: post #7

Earlier quoted context omitted.

In this particular case, I believe there are 3 reasons: 1) Size - turning each op into a couple of bytes means that the size of your template is significantly smaller. If each instruction is 4 bytes, I could get ~20 instructions in the space of just one function with a setAttribute call: function t(e) {e.setAttribute("id", "bar")} Size is much more important on the web than it is in other places especially as the nex…

For 1) and 2), some frameworks solve the size issue by creating functions for the basic DOM ops, which then get minimized to single character names in production. So in your example, there might be a setNodeAttribute(node, name, val) function, such that the final code isn't `e.setAttribute("id", "bar")` but just `a(e,"id","bar")`, where `a` is the minimized name of setNodeAttribute. There's really not much noise in t…

In terms of #3, if you're yielding until the next requestAnimationFrame, the browser is telling you when you have the opportunity to do more work. Is there something that isn't covered by that?

> they're already fast enough that most of the time is spent in rendering, not in javascript DOM manipulation

That hasn't been my experience, but it's been awhile since I've benchmarked any of the frameworks in common use. Change tracking, diffing, and then the dom calls have all been the bulk of the work in large updates. Assuming you're doing those in a dom fragment I'm not sure how "rendering time" (I'm taking that to mean compositing and painting?) could be the bottleneck in that scenario.

Re: The Glimmer VM: Boots Fast and Stays Fast

#48

Post by okket »

bluepnume wrote: post #45

I'm a big fan of what I'm seeing in Glimmer so far. I had fun adding support for xcomoponent yesterday, making Glimmer components work as cross-domain components. https://medium.com/@bluepnume/introducing-support-for-cross-... I'd love it if it were a little more flexible to get started with though. Rather than fire up ember-cli, I'd love to just be able to: 1. Load glimmer.js from a CDN 2. Extend glimmer.Component 3…

This is simply not possible with what Glimmer tries to achieve. (Did you even read the article?)

Re: The Glimmer VM: Boots Fast and Stays Fast

#49

Post by gavinjoyce »

chubot wrote: post #8

What IS the glimmer VM? I didn't see any links on the page. Is this it? https://github.com/glimmerjs/glimmer-vm It is JavaScript code or native code?

Here's a playlist of technical videos which explore the Glimmer VM internals:

https://www.youtube.com/playlist?list=PLpAr6J-75N24C-XQgIUDM...

Re: The Glimmer VM: Boots Fast and Stays Fast

#50

Post by Pxtl »

matthewmacleod wrote: post #10
analognoise wrote: post #6

Isn't this just re-solving a decades old problem, with the (unnecessary) constraints caused by modern web systems?

While being technically correct, your statement is pretty much pointless. All development is 'just' re-solving an existing problem with better performance, or 'just' extending an existing algorithm to be more resilient, or 'just' implementing a legacy interface on a new platform. There are lots of very obvious reasons that the web has the constraints that it does and describing them as 'unnecessary' adds literally no…

Yes, but the point here seems to be that once again, the web platform is obstructive and forcing us to build abstractions on abstractions.
Post reply on HN