3 ms·

Someone really needs to crack simple generic type systems with native levels of performance to get all of this to work. Performance comes from optimizing the u

Someone really needs to crack simple generic type systems with native levels of performance to get all of this to work. Performance comes from optimizing the usage of state against hardware, modularity comes from code satisfying the properties of composition which is best left stateless (and high levels of modularity must come from abstraction and conventional practice, incurring further debts on the programmer and machine.) It's a tension that I haven't seen fully resolved but I'm very very very open to being wrong. Many languages seem to be experimenting in this space with some preference for one side of the equation for another.

zozbot234 7y ago
> Someone really needs to crack simple generic type systems with native levels of performance to get all of this to work. We know how this works, at least in broad theoretical terms. Zero-cost abstractions are quite feasible within a self-contained module/component, but their scope is ultimately limited by ease of building and deployment. Nevertheless the performance impact of having to support high levels of abstraction across modules/components is quite reasonable, even if not literally "zero" cost.
- bambataa 7y ago
  Do you have any resources on this you could recommend?
- bordercases 7y ago
  I'm thinking supercompilation might be another part of the equation as long as we're talking extended composition of modules and types whose behavior is totally closed. Having a pipeline that can supercompile when systems are pushed in production even if some compilation time is traded for performance at development (maybe "local" supercompilation for subsystems relevant to a development team?) would be an interesting thing. But I don't know.
  - jlokier 7y ago
    Fwiw, I agree about supercompilation. Some have noted that JIT systems perform many of the same things as supercompilation, and it seems reasonable to consider that JIT is part of the equation for optimising performance when systems are pushed to production. We've been doing that for decades now, with increasing sophistication in the details. Profile driven, multiple stages of specialisation and optimisation. Not quite to the levels of proof systems (and therefore supercompilation as envisioned) yet - there's plenty of room to get better at it - and we need to go there if we want those "zero cost abstractions" across modules that aren't designed for it, often with significant impedance mismatches.

zozbot234 7y ago

> Someone really needs to crack simple generic type systems with native levels of performance to get all of this to work. We know how this works, at least in broad theoretical terms. Zero-cost abstractions are quite feasible within a self-contained module/component, but their scope is ultimately limited by ease of building and deployment. Nevertheless the performance impact of having to support high levels of abstraction across modules/components is quite reasonable, even if not literally "zero" cost.

bambataa 7y ago
Do you have any resources on this you could recommend?
bordercases 7y ago
I'm thinking supercompilation might be another part of the equation as long as we're talking extended composition of modules and types whose behavior is totally closed. Having a pipeline that can supercompile when systems are pushed in production even if some compilation time is traded for performance at development (maybe "local" supercompilation for subsystems relevant to a development team?) would be an interesting thing. But I don't know.
- jlokier 7y ago
  Fwiw, I agree about supercompilation. Some have noted that JIT systems perform many of the same things as supercompilation, and it seems reasonable to consider that JIT is part of the equation for optimising performance when systems are pushed to production. We've been doing that for decades now, with increasing sophistication in the details. Profile driven, multiple stages of specialisation and optimisation. Not quite to the levels of proof systems (and therefore supercompilation as envisioned) yet - there's plenty of room to get better at it - and we need to go there if we want those "zero cost abstractions" across modules that aren't designed for it, often with significant impedance mismatches.