Live data from Hacker News

The Glimmer VM: Boots Fast and Stays Fast

yehudakatz.com

81–90 of 92 posts

Re: The Glimmer VM: Boots Fast and Stays Fast

#81
It's not correct to call this a VM. It's an optimized template language/renderer.

I'd like to see an example of the same static gzipped HTML content delivered to the browser and a template rendered with this.

I have doubts this is any more efficient than the browser's built-in gzip decoder on a time basis nor do I think it beats gzip in terms of space efficiency.

It's hard to take seriously those who claim to be optimizing things when they don't have any measurements on what they are trying to improve vs. the new method.

Re: The Glimmer VM: Boots Fast and Stays Fast

#82

It's not correct to call this a VM. It's an optimized template language/renderer. I'd like to see an example of the same static gzipped HTML content delivered to the browser and a template rendered with this. I have doubts this is any more efficient than the browser's built-in gzip decoder on a time basis nor do I think it beats gzip in terms of space efficiency. It's hard to take seriously those who claim to be opti…

Why not? They have byte code (sort of) that translates to actions...

I don't get the gzip comparison because this is about updating views in an SPA framework (Ember)

Re: The Glimmer VM: Boots Fast and Stays Fast

#83

Earlier quoted context omitted.

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.

Yeah, I was just looking at the Glimmer opcodes format. I'm a bit surprised it's an array of arrays, rather than a flattened array. It looks like it goes `[[1,"id","bar"],[2, ],...]` rather than `[1,"id","bar",2, ,...]`. Wonder why? Monomorphism, or faster dispatch by not having to pass a pc index around? Interesting. The `a(e,"id","bar")` format is what other frameworks produce. It sounds like in Glimmer it would be…

Yea this is sort of a relic of the initial VM architecture we landed originally in Ember 2.10. That architecture was more like Clojure e.g. read -> compile -> execute. So the nested arrays are seen as sub expressions. You are correct this can be linearized.

Re: The Glimmer VM: Boots Fast and Stays Fast

#84

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

The web is the only platform that has solved the sub-100ms install+load problem, which helped it solve the be-on-every-device problem. Solving those problems introduced constraints did make certain things harder. But IMO it was a good trade-off. Being the biggest software platform in the world certainly suggests it was worth it.

Let me know when Windows gets 100ms install+load and I'll be interested in the rendering model. Until then... measuring install time in seconds, or minutes? You can hardly claim to be performance oriented.

Re: The Glimmer VM: Boots Fast and Stays Fast

#85

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

The web is the only platform that has solved the sub-100ms install+load problem, which helped it solve the be-on-every-device problem. Solving those problems introduced constraints did make certain things harder. But IMO it was a good trade-off. Being the biggest software platform in the world certainly suggests it was worth it. Let me know when Windows gets 100ms install+load and I'll be interested in the rendering…

When you can run a real CAD program on a phone, I'll be interested.

The web is for disposable toys, uninteresting ones at that. All of Windows 3.1 could fit in less space than the Apple website. You're telling me a silent install of Windows 3.1 would take more time to install than...Some app to find local hookups by GPS?

Re: The Glimmer VM: Boots Fast and Stays Fast

#86

Earlier quoted context omitted.

Yeah, I was just looking at the Glimmer opcodes format. I'm a bit surprised it's an array of arrays, rather than a flattened array. It looks like it goes `[[1,"id","bar"],[2, ],...]` rather than `[1,"id","bar",2, ,...]`. Wonder why? Monomorphism, or faster dispatch by not having to pass a pc index around? Interesting. The `a(e,"id","bar")` format is what other frameworks produce. It sounds like in Glimmer it would be…

Yea this is sort of a relic of the initial VM architecture we landed originally in Ember 2.10. That architecture was more like Clojure e.g. read -> compile -> execute. So the nested arrays are seen as sub expressions. You are correct this can be linearized.

Also, this particular format is the "wire format", which is the compact representation that we compile templates into to send to the client.

The client then compiles that representation into flat opcodes, in part by specializing the template based on runtime information (like the exact identity of the components in question).

The runtime opcodes are binary (128-bits apiece at the moment) and optimized for reasonably fast iteration. The wire format is, as chadhietala1 said, not as flat or compact as it could be, but still much more compact than our earlier representations (or the representations of competing rendering engines).

We plan to improve the wire format representation in the near future.

Re: The Glimmer VM: Boots Fast and Stays Fast

#88
Based on some of the comments about what a VM actually is, I think this 2-part series might help those who are wondering (me included) about the technicalities of building one's own VM:

- (Part 1) https://www.codeproject.com/Articles/43176/How-to-create-you... - (Part 2) https://www.codeproject.com/Articles/61924/How-to-create-you...

Re: The Glimmer VM: Boots Fast and Stays Fast

#90

Earlier quoted context omitted.

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…

All development is just re-solving or extending? That's a sweeping generalization. My own work is definitely the incremental kind, and maybe yours is too --- but surely you'd agree that someone, somewhere in the world is doing truly innovative work.

No, this is false. All "innovation" can be characterized as re-solving or extending. Pick a computing technology, and I'm happy to do it.
Post reply on HN