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 > <[email protected]> wrote: > > >> On May 31, 2017, at 9:28 AM, Robert Bennett via swift-evolution >> <[email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
