[swift-evolution] Yet another fixed-size array spitball session

[Michael Ilseman]

If you replace “heap access” with “heap allocation/deallocation” in the argument, then the performance differences become very relevant.

> On May 31, 2017, at 10:15 AM, David Waite via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On May 31, 2017, at 9:28 AM, Robert Bennett via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> Without static arrays, swift cannot be used in high performance applications. The cost of repeated heap accesses is simply too high. And tuples are not ergonomic enough to use in the same manner as arrays. So I think we do need to add static arrays to Swift, if not necessarily in Swift 4.
> 
> I don’t quite understand why there is such a massive heap access cost vs stack. My understanding is the instructions for both are pointer dereferences, both stack and heap memory equally cache, neither require read or write barriers with swift, and the MMU isn’t set to fault heap memory (except as a general virtual memory policy).
> 
> I understand memory-sensitive applications using static arrays within data structures, but high performance applications using stack-allocated static arrays sounds pretty restrictive in terms of use. Given value semantics, there is a lot of pressure on the optimizer to prevent those arrays from being copied on mutation and being passed into calls. The chessboard example may have been 64 bytes, or may have been 512 bytes - quite expensive if the optimizer decides a method invocation needs a copy.
> 
> -DW
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution