3 ms·

Your example really clicked with me, having written a substantial quantity of JS in a "memory managed" way to avoid GC, and avoiding memcpy by passing buffers i

by tomxor 5y ago

Your example really clicked with me, having written a substantial quantity of JS in a "memory managed" way to avoid GC, and avoiding memcpy by passing buffers in place of pointers. My initial instinct is that putting such considerations behind a preprocessor syntax has the disadvantage of making them more opaque and magic, and that I personally would continue to do such things more explicitly - which I realise is an ironic thing to say about an untyped, interpreted language, it's probably just the little pseudo "grey beard" on my shoulder which occasionally whispers silly things about "building their own computer out of rocks and twigs". I guess the point is that there's a balance to the cost vs benefit: making it more convenient (what you call ergonomics), making it more accessible to those that were less likely to manually use that technique, and perhaps resulting in an average of more performant code; but at the cost of more obscurity, and more "magic", perhaps resulting in less educated programmers. I'm probably overthinking it. Ultimately this argument even applies to for loops, but it's worth being conscious of that cost - it's likely a good idea.

janpaul123 5y ago
Yeah I hear you; and even allude to that in some parts of the article, like this part: > Another idea to make Typescript–– a bit less restrictive and more ergonomic, would be to use reference-counting of objects, and then try to optimize most away using compile-time reference counting as pioneered by Lobster. This gives most of the advantages of manually managed memory, but makes the ownership model much easier to reason about. It is however slightly less performant, and more importantly, makes performance less predictable, since it becomes more reliant on compiler cleverness. Even Rust can hide actual performance behind abstractions, and I've already been bitten by that a few times.. Not sure what the right solution is here, but I agree that it's super important to think about this when designing a language like this.
triyambakam 5y ago
> having written a substantial quantity of JS in a "memory managed" way to avoid GC, and avoiding memcpy by passing buffers in place of pointers. What projects were you working on that required that? It sounds interesting
- tomxor 5y ago
  Mostly a variety of web based science education simulations. Usually boiling down to some kind of miniature specialist physics engine or procedural animation. Beyond that, it's more of a personal philosophy than a requirement (I could easily have done all those things more carelessly, but the result wouldn't be so nice, some people's laps would be hotter, and some people would end up with a slow or jerky simulation). I like things to be efficient, I enjoy finding a balance between "efficient" and "minimal". That doesn't mean I avoid GC all over the place adding unnecessary complexity and over optimizing, it just means being considerate where it matters and "idiomatic" where it doesn't - in a physics engine (or any kind of posteriori simulation) it matters because it's running on an interval and will constantly cause perceptible GC hiccups if you don't be considerate with memory.
  - fancy_hammer 5y ago
    Would love to read a blog post about what this kind of code looks like!
- Jasper_ 5y ago
  I've done this before for plenty of tight loop code. Nothing irks me than staring a profile and seeing "Major GC" multiple times in the middle of a big algorithm. It's certainly not helped by the latest language fads just completely flooring the GC gas pedal; special mention should go to for...of creating a brand new object for each loop iteration. That's usually the first thing I rip out of tight loops. A bit of care can make this stuff go 3x fast on PC, and I've gotten completely unusable experiences on mobile (most websites) to be 30-40fps.
  - triyambakam 5y ago
    Do you have any resources you like for diving deeper into profiling and learning the nature of the JS GC?

by tomxor 5y ago

janpaul123 5y ago

Yeah I hear you; and even allude to that in some parts of the article, like this part: > Another idea to make Typescript–– a bit less restrictive and more ergonomic, would be to use reference-counting of objects, and then try to optimize most away using compile-time reference counting as pioneered by Lobster. This gives most of the advantages of manually managed memory, but makes the ownership model much easier to reason about. It is however slightly less performant, and more importantly, makes performance less predictable, since it becomes more reliant on compiler cleverness. Even Rust can hide actual performance behind abstractions, and I've already been bitten by that a few times.. Not sure what the right solution is here, but I agree that it's super important to think about this when designing a language like this.

triyambakam 5y ago

> having written a substantial quantity of JS in a "memory managed" way to avoid GC, and avoiding memcpy by passing buffers in place of pointers. What projects were you working on that required that? It sounds interesting

tomxor 5y ago
Mostly a variety of web based science education simulations. Usually boiling down to some kind of miniature specialist physics engine or procedural animation. Beyond that, it's more of a personal philosophy than a requirement (I could easily have done all those things more carelessly, but the result wouldn't be so nice, some people's laps would be hotter, and some people would end up with a slow or jerky simulation). I like things to be efficient, I enjoy finding a balance between "efficient" and "minimal". That doesn't mean I avoid GC all over the place adding unnecessary complexity and over optimizing, it just means being considerate where it matters and "idiomatic" where it doesn't - in a physics engine (or any kind of posteriori simulation) it matters because it's running on an interval and will constantly cause perceptible GC hiccups if you don't be considerate with memory.
- fancy_hammer 5y ago
  Would love to read a blog post about what this kind of code looks like!
Jasper_ 5y ago
I've done this before for plenty of tight loop code. Nothing irks me than staring a profile and seeing "Major GC" multiple times in the middle of a big algorithm. It's certainly not helped by the latest language fads just completely flooring the GC gas pedal; special mention should go to for...of creating a brand new object for each loop iteration. That's usually the first thing I rip out of tight loops. A bit of care can make this stuff go 3x fast on PC, and I've gotten completely unusable experiences on mobile (most websites) to be 30-40fps.
- triyambakam 5y ago
  Do you have any resources you like for diving deeper into profiling and learning the nature of the JS GC?