Hacker News Reader

Comment by nine_k | Hacker News Reader

> you couldn’t use C arrays on the stack, for example. And if you couldn’t do that, there’s entire classes of applications where the performance just wouldn’t be acceptable

Would you mind naming a few such classes?

Why would arena allocation, or evrn good generational GC fail to deliver the performance when quick allocation / deallocation of (large) arrays is required?

View on HN

Generally one feature GCd languages lack is strong support for value types. Cache thrashing due to pointer chasing is an issue, and even if you can allocate large numbers of small objects quickly, the indirection will kill you. In Swift, many small allocations are avoided entirely by storing the value as part of some other object. For example, imagine you want to store an array of points; it’s usually much better if you can have an array of structs of floats where everything is represented as one flat allocation.

C# had value types from day one.

And ....

Yeah, its one of the few that does. Even then, C# value types are immutable, and there are no value type collections (not a collection of value types, but a collection that is itself a value type). The lack of these two features means it’s not as generally useful as you might like.

An array of value types (including structs) in .NET (not just C#) is laid out contiguously in memory and stored in-place like an array of C/C++ structs would be. The problem of chasing pointers does not exist if you use structs (and don't use non-value types such as strings within those structs). And .NET value types are mutable, of course.

Right, but the array itself has reference semantics.

Not when you allocate it on the stack via stackalloc, as of C# 7 also allowed in safe code.

Oberon, Oberon-2, Active Oberon, Component Pascal, Eiffel, Common Lisp, Modula-2+, Modula-3, CLU, C#, D all have strong support for value types.

Java just made a couple of wrong decisions regarding AOT and value types that are now taking years to correct course, while avoid breaking backwards compatibility.

If something like Modula-3 had been granted Java's success story, we wouldn't be talking about how GC languages don't have good support for value types.

I think we have different definitions of value types - in all Common Lisp implementations I’m aware of values have a uniform representation as a (tagged) pointer.

Also I think C# structs do not have mutable fields, but I could be wrong.

Edit: it looks like C# structs are mutable, my mistake.

Common Lisp is just one example among 11 programming languages that I have listed.

Maybe take some time to check the other ones?

As for value types in Common Lisp, even if one bit is lost for tagging, it doesn't make arrays, structs and primitive values, less of value types.

Reply on news.ycombinator.com