4 ms·

That can't be right though. Java and Kotlin have generics, fast programmers, fast compile times and as generics are erased there's no more binary bloat than wit

That can't be right though. Java and Kotlin have generics, fast programmers, fast compile times and as generics are erased there's no more binary bloat than without them. I think the assumption implicit in that statement is "generics over value types compiled AOT". But that's not the only way to do it.

dilap 7y ago
But slower than optimal execution times! Since everything is boxed.
- thu2111 7y ago
  For generics over primitives, yes, but the JVM only has a small number of those so they can be easily hand specialised: http://trove4j.sourceforge.net/html/overview.html http://trove4j.sourceforge.net/html/overview.html The rest of the time you're dealing with references anyway, so there's no boxing.
  - dilap 7y ago
    Well, sure, in the context of a language that doesn't really have value types and is already doing everything w/ dynamic dispatch, you can have "zero cost" generics, in the sense that there's no code bloat and no perf penalty, vs what you already had. But that's because your language is already leaving some performance on the table! If you want a language that's as fast as possible, you want something like GenericContainer<Foo> foos = ...; for(var f in foos) f.DoSomethingFooish() to be able to transform into a contiguous chunk of "Foo"s in memory, that the loop is traversing, and doing no dynamic dispatch (and potentially inlining!) in each of the "DoSomethingFooish" calls. I don't think you can have a generics system capable of achieving that level of performance w/o also brining w/ it the downside of more code generation & extended comp time. (P.S. Also, Java is getting support for user-defined value types, right? How will those interact w/ the generics system?)
    - thu2111 7y ago
      Yes, that's a good point. I'd counter though that in C++ and similar languages value types and memory management get conflated in ways that hurt performance. Java has a really, really fast heap and allocations get laid out contiguously by the GC in ways that have a measurable + significant impact on cache hits and performance. In C++ you see std::vector with large-ish values all the time, even when it doesn't really have any memory layout justification because that way you get semi-automatic memory management and with pointers you don't. This can easily lead to large amounts of pointless code bloat, hurting icache hit rates, compile times, binary sizes and more, even in cold paths where memory layout is the least of your concerns. Not sure yet how generics in Java and value types will interact. There have been some prototypes of generics specialisation so it'll probably end up like C++ but, hopefully, with way less use of value types - restricted only to places where they make a real improvement. That'll be a lot easier to measure in Java because as long as you stay within the value-allowed subset of features you will be able to convert between value and non-value types transparently without rewriting use sites. So you can just toggle it on and off to explore the tradeoffs between code generation and pointer indirection.

dilap 7y ago

But slower than optimal execution times! Since everything is boxed.

thu2111 7y ago
For generics over primitives, yes, but the JVM only has a small number of those so they can be easily hand specialised: http://trove4j.sourceforge.net/html/overview.html http://trove4j.sourceforge.net/html/overview.html The rest of the time you're dealing with references anyway, so there's no boxing.
- dilap 7y ago
  Well, sure, in the context of a language that doesn't really have value types and is already doing everything w/ dynamic dispatch, you can have "zero cost" generics, in the sense that there's no code bloat and no perf penalty, vs what you already had. But that's because your language is already leaving some performance on the table! If you want a language that's as fast as possible, you want something like GenericContainer<Foo> foos = ...; for(var f in foos) f.DoSomethingFooish() to be able to transform into a contiguous chunk of "Foo"s in memory, that the loop is traversing, and doing no dynamic dispatch (and potentially inlining!) in each of the "DoSomethingFooish" calls. I don't think you can have a generics system capable of achieving that level of performance w/o also brining w/ it the downside of more code generation & extended comp time. (P.S. Also, Java is getting support for user-defined value types, right? How will those interact w/ the generics system?)
  - thu2111 7y ago
    Yes, that's a good point. I'd counter though that in C++ and similar languages value types and memory management get conflated in ways that hurt performance. Java has a really, really fast heap and allocations get laid out contiguously by the GC in ways that have a measurable + significant impact on cache hits and performance. In C++ you see std::vector with large-ish values all the time, even when it doesn't really have any memory layout justification because that way you get semi-automatic memory management and with pointers you don't. This can easily lead to large amounts of pointless code bloat, hurting icache hit rates, compile times, binary sizes and more, even in cold paths where memory layout is the least of your concerns. Not sure yet how generics in Java and value types will interact. There have been some prototypes of generics specialisation so it'll probably end up like C++ but, hopefully, with way less use of value types - restricted only to places where they make a real improvement. That'll be a lot easier to measure in Java because as long as you stay within the value-allowed subset of features you will be able to convert between value and non-value types transparently without rewriting use sites. So you can just toggle it on and off to explore the tradeoffs between code generation and pointer indirection.