Anyone claiming something like this obviously hasn’t dig into GCs. You honestly think that writing into memory at each access, especially atomically is anywhere near the performance of a GC that can do most of its work in parallel and just flip a bit to basically “having deleted” everything no longer accessible?
Tracing is batched up in GC pauses, rather than on every access as with naive RC. It is necessary to stop the world, but the work done in the pause does not need to use atomic operations.
Atomics are handy in a parallel/multi-core tracing collector, but IME pointer chasing in tracing somehow manages to cover the time it takes to do atomic operations.
This isn't the kind of program Swift was designed to perform well for.
Nor is wallclock speed even what the system should be optimizing for, since you buy phones to run apps not to run the system. You should be measuring how well it gets out of the way of the important work.
"From its earliest conception, Swift was built to be fast. Using the incredibly high-performance LLVM compiler technology, Swift code is transformed into optimized machine code that gets the most out of modern hardware. The syntax and standard library have also been tuned to make the most obvious way to write your code also perform the best whether it runs in the watch on your wrist or across a cluster of servers.
Swift is a successor to both the C and Objective-C"
It usually isn't. Reference counting is good when you need to rather tightly limit memory use, are wedded to RAII, or need something simple enough that a programmer can knock it out in an afternoon.
Anyone claiming something like this obviously hasn’t dig into GCs. You honestly think that writing into memory at each access, especially atomically is anywhere near the performance of a GC that can do most of its work in parallel and just flip a bit to basically “having deleted” everything no longer accessible?
a bit flip is not writing?
Also do traces not have to work atomically? The program needs to stop, you can’t have it check roots as it runs.
I’ll admit I am no GC researcher with ph.D experience, but your comment makes it seem you aren’t either.
Tracing is batched up in GC pauses, rather than on every access as with naive RC. It is necessary to stop the world, but the work done in the pause does not need to use atomic operations.
Atomics are handy in a parallel/multi-core tracing collector, but IME pointer chasing in tracing somehow manages to cover the time it takes to do atomic operations.
That depends. Deallocating a zillion little objects one a a time can be slower than doing them all in a batch.
Not really, here it is winning hands down over Swift's ARC implementation.
https://github.com/ixy-languages/ixy-languages
Wasn't this the comparison that decided to use reference types for everything for no real reason?
The reason being comparing how various schemes of automatic reference memory management perform.
Naturally if the purpose was to compare stack allocation performance other approach would have been taken.
5 replies →
I don’t know anything about the benchmark, but how would you test GC implementations without reference types?
3 replies →
This isn't the kind of program Swift was designed to perform well for.
Nor is wallclock speed even what the system should be optimizing for, since you buy phones to run apps not to run the system. You should be measuring how well it gets out of the way of the important work.
Ah the excuses when facts are put on the table.
"Fast. Swift is intended as a replacement for C-based languages (C, C++, and Objective-C). "
-- https://www.swift.org/about/
"From its earliest conception, Swift was built to be fast. Using the incredibly high-performance LLVM compiler technology, Swift code is transformed into optimized machine code that gets the most out of modern hardware. The syntax and standard library have also been tuned to make the most obvious way to write your code also perform the best whether it runs in the watch on your wrist or across a cluster of servers.
Swift is a successor to both the C and Objective-C"
-- https://developer.apple.com/swift/#fast
[flagged]
[flagged]
It usually isn't. Reference counting is good when you need to rather tightly limit memory use, are wedded to RAII, or need something simple enough that a programmer can knock it out in an afternoon.