4 ms·

Objective-C and then Swift are surely the most serious goes at fast widely used RC languages. Neither requires mutating the reference count on every store, and

Objective-C and then Swift are surely the most serious goes at fast widely used RC languages. Neither requires mutating the reference count on every store, and neither seems at risk of growing a tracing GC. ObjC had some elision tricks like objc_retainAutoreleasedReturnValue, but more importantly the optimizer was taught about RC manipulation. Swift then extended this with a new ABI that minimizes unnecessary mutations. The big advantages of this scheme are efficient COW collections and a simpler FFI (very important with Swift). More generally RC integrates better. Imagine teaching the JS GC to walk the Java heap!

pjmlp 7y ago
So efficient that Swift's RC implementation loses against all major tracing GC implementations. https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages
- jmull 7y ago
  That project doesn’t compare GC implementations, so it’s probably not that useful here. Also, the Swift implementation is a bit questionable if performance is a goal. That is, why not try to remove the memory management from the inner loop? Probably the first thing to try is value types instead of reference types, which are more generally preferred anyway.
  - pjmlp 7y ago
    Sure it does, memory management impacts the performance of the task being achieved, writing an high-speed network driver.
    - jmull 7y ago
      By that measure, every project is a good measure of GC performance. Is that really a good argument? I believe all general purpose languages let the code allocate memory and therefore will let you allocate memory in a way inefficient to your task.
      - pjmlp 7y ago
        The argument is that to eventually write Swift code whose performance matches the competition, one needs to work around ARC's implementation. Hence why there is so much emphasis on value driven programming alongside protocols at WWDC talks.
- ridiculous_fish 7y ago
  My claim was about efficient COW collections and the FFI. The point of COW collections is enabling a simpler programming model.
mpweiher 7y ago
> ObjC had some elision tricks like objc_retainAutoreleasedReturnValue, but more importantly the optimizer was taught about RC manipulation. Cough. Actually, before ARC the ownership rules really kept RC traffic very low, and you could drive it lower still if you knew a bit about how ownership worked in your code ("these will balance and the object is already owned elsewhere..."). ARC just went mad with trying to give guarantees it really had no business making, and then hoping the compiler would be able to remove them again (difficult with message sending). This caused some amusing bugs, for example a crash in the following method: -someMethod:arg and:arg2 { return 0; } How could this possibly crash? All it could possibly do is clear register AX and return. Well, with ARC enabled and in debug mode, it inserted code to first retain all the arguments, and then immediately release all the arguments. Apparently one of the args was a bogus pointer (framework-provided, so out of our control) and so it crashed.
- tinus_hn 7y ago
  So the result of your instructions that have undefined behavior turned out to be not what you wanted? That’s hardly a problem with the language.
  - mpweiher 7y ago
    Interesting that return 0 is now considered "undefined behavior". Whatever.
    - tinus_hn 7y ago
      Obviously the problem is with using objects in the message which are invalid. The compiler may or may not work as you expect and that’s your problem, not the compilers. You can try to defend yourself by stating the call is done by some framework but that just means the problem is still not in the language, it’s in the framework.
      - mpweiher 7y ago
        First, the compiler and framework come from the same vendor, so it's perfectly fine to blame them. Unless you consider things like compilers and frameworks to be independent subjects capable of being blamed. Second, whether the behavior is defined or undefined, the compiler has no business touching arguments that the code didn't tell it to touch. If it does so, it isn't fit for purpose and can be criticised as being unfit for purpose. And the C standard is very clear and adamant that being in compliance with the standard is not, and in many ways cannot be, equivalent to being fit for purpose. Last not least, I think we are probably not going to agree as to whether dereferencing unused arguments is a valid response to the presence of undefined behavior. See https://blog.metaobject.com/2018/07/a-one-word-change-to-c-standard-to-make.html https://blog.metaobject.com/2018/07/a-one-word-change-to-c-s...

pjmlp 7y ago

So efficient that Swift's RC implementation loses against all major tracing GC implementations. https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages

jmull 7y ago
That project doesn’t compare GC implementations, so it’s probably not that useful here. Also, the Swift implementation is a bit questionable if performance is a goal. That is, why not try to remove the memory management from the inner loop? Probably the first thing to try is value types instead of reference types, which are more generally preferred anyway.
- pjmlp 7y ago
  Sure it does, memory management impacts the performance of the task being achieved, writing an high-speed network driver.
  - jmull 7y ago
    By that measure, every project is a good measure of GC performance. Is that really a good argument? I believe all general purpose languages let the code allocate memory and therefore will let you allocate memory in a way inefficient to your task.
    - pjmlp 7y ago
      The argument is that to eventually write Swift code whose performance matches the competition, one needs to work around ARC's implementation. Hence why there is so much emphasis on value driven programming alongside protocols at WWDC talks.
ridiculous_fish 7y ago
My claim was about efficient COW collections and the FFI. The point of COW collections is enabling a simpler programming model.

mpweiher 7y ago

> ObjC had some elision tricks like objc_retainAutoreleasedReturnValue, but more importantly the optimizer was taught about RC manipulation. Cough. Actually, before ARC the ownership rules really kept RC traffic very low, and you could drive it lower still if you knew a bit about how ownership worked in your code ("these will balance and the object is already owned elsewhere..."). ARC just went mad with trying to give guarantees it really had no business making, and then hoping the compiler would be able to remove them again (difficult with message sending). This caused some amusing bugs, for example a crash in the following method: -someMethod:arg and:arg2 { return 0; } How could this possibly crash? All it could possibly do is clear register AX and return. Well, with ARC enabled and in debug mode, it inserted code to first retain all the arguments, and then immediately release all the arguments. Apparently one of the args was a bogus pointer (framework-provided, so out of our control) and so it crashed.

tinus_hn 7y ago
So the result of your instructions that have undefined behavior turned out to be not what you wanted? That’s hardly a problem with the language.
- mpweiher 7y ago
  Interesting that return 0 is now considered "undefined behavior". Whatever.
  - tinus_hn 7y ago
    Obviously the problem is with using objects in the message which are invalid. The compiler may or may not work as you expect and that’s your problem, not the compilers. You can try to defend yourself by stating the call is done by some framework but that just means the problem is still not in the language, it’s in the framework.
    - mpweiher 7y ago
      First, the compiler and framework come from the same vendor, so it's perfectly fine to blame them. Unless you consider things like compilers and frameworks to be independent subjects capable of being blamed. Second, whether the behavior is defined or undefined, the compiler has no business touching arguments that the code didn't tell it to touch. If it does so, it isn't fit for purpose and can be criticised as being unfit for purpose. And the C standard is very clear and adamant that being in compliance with the standard is not, and in many ways cannot be, equivalent to being fit for purpose. Last not least, I think we are probably not going to agree as to whether dereferencing unused arguments is a valid response to the presence of undefined behavior. See https://blog.metaobject.com/2018/07/a-one-word-change-to-c-standard-to-make.html https://blog.metaobject.com/2018/07/a-one-word-change-to-c-s...