3 ms·

So we are comparing a language with 10+ years of optimizations against a language that just barely released in beta? We have no idea what settings the author ch

So we are comparing a language with 10+ years of optimizations against a language that just barely released in beta? We have no idea what settings the author chose (I'm not implying the author is attempting to deceive) and, assuming they are the defaults, it seems safe to assume Apple would choose very conservative defaults for the beta, especially the first release (it doesn't matter how fast it goes if it doesn't do what it's supposed to). In two months, after people start to understand what's going on, where the trouble spots are, and what the right way to fiddle bits, if we are still seeing performance like this, I'll be interested.

na85 12y ago
Isn't the point of a high-level dynamic language that you shouldn't need to do any bit-fiddling to write performant code? Swift seems self-defeating.
- alejgoon 12y ago
  I think that's hardly the case. Or are javascript and python and ruby self-defeating as well?
  - deleted 12y ago
    [deleted]
  - danbruc 12y ago
    Depends on the way you look at it - on the one hand JavaScript is a terrible language, on the other hand it is (more or less) the only thing you have available in a browser.
- alayne 12y ago
  No, the point is to ease application development.
- Fomite 12y ago
  If you could use a high-level dynamic language to write performant code without "bit-fiddling", why would anyone write in anything else?
  - reeses 12y ago
    The most commonly-heard excuse is that programmers do not like all the parens.
stormbrew 12y ago
Well, to be fair on the optimization story, I assume this is llvm-backed objc vs. llvm-backed swift, and swift is using the well-known, very optimized, message dispatch code that objc does. So there should be similar heft behind the optimizations in each.
- SoftwareMaven 12y ago
  Not always[1] (though, of course, when it does, it should take advantage of it). As TFA mentioned, there will also be a difference between class-based references and C scalar values. Of course, if that is the difference the author is seeing, it is probably far less meaningful for most applications (games would be an obvious exception, but that may be where Metal comes in). 1. http://stackoverflow.com/questions/24022172/does-swift-use-message-dispatch-for-methods http://stackoverflow.com/questions/24022172/does-swift-use-m...
  - stormbrew 12y ago
    I think the speculation in the blog post about it using boxed primitive types exclusively must be wrong, or at least a temporary state of affairs if it's currently correct. I don't have a Mac capable of running any of the dev tools at the moment, but the implications of the section in the manual on the Int* types don't indicate they're boxed at all, nor give any reason why they should have to be. Of course, if he's declared everything as an NSNumber it could explain some of the results. But obviously, so could them currently being boxed. Either would probably account for the ++ performance problem, especially if it's post-increment, since that probably involves making a copy. I think the OP is just confusing the fact that they have expandable type as indicating that they have a virtual type.
reeses 12y ago
I would assert, rather, that we have 60 years of compiler and runtime experience, both academic and industrial. Consequently, I would propose that there is no excuse for a public release of a commercial programming environment to be so slow unless it introduces significant novelty sufficient to render the preceding work inapplicable.
- mistermumble 12y ago
  I agree. Especially if the language is named something that implies high performance. When Golang first appeared it was quite fast. Swift is not, apparently.
  - xooyoozoo 12y ago
    Go's compilation was fast, which made developement much more pleasant. Performance of the actual compiled code was a different matter (hard to get both fast binaries and fast compilations). However, I understand that 1.1 and 1.2 has much improved code performance.
  - axman6 12y ago
    Golang also doesn't do anything particularly interesting as a language, and didn't have to maintain interoperability with a system like Objective-C.

na85 12y ago

Isn't the point of a high-level dynamic language that you shouldn't need to do any bit-fiddling to write performant code? Swift seems self-defeating.

alejgoon 12y ago
I think that's hardly the case. Or are javascript and python and ruby self-defeating as well?
- deleted 12y ago
  [deleted]
- danbruc 12y ago
  Depends on the way you look at it - on the one hand JavaScript is a terrible language, on the other hand it is (more or less) the only thing you have available in a browser.
alayne 12y ago
No, the point is to ease application development.
Fomite 12y ago
If you could use a high-level dynamic language to write performant code without "bit-fiddling", why would anyone write in anything else?
- reeses 12y ago
  The most commonly-heard excuse is that programmers do not like all the parens.

stormbrew 12y ago

Well, to be fair on the optimization story, I assume this is llvm-backed objc vs. llvm-backed swift, and swift is using the well-known, very optimized, message dispatch code that objc does. So there should be similar heft behind the optimizations in each.

SoftwareMaven 12y ago
Not always[1] (though, of course, when it does, it should take advantage of it). As TFA mentioned, there will also be a difference between class-based references and C scalar values. Of course, if that is the difference the author is seeing, it is probably far less meaningful for most applications (games would be an obvious exception, but that may be where Metal comes in). 1. http://stackoverflow.com/questions/24022172/does-swift-use-message-dispatch-for-methods http://stackoverflow.com/questions/24022172/does-swift-use-m...
- stormbrew 12y ago
  I think the speculation in the blog post about it using boxed primitive types exclusively must be wrong, or at least a temporary state of affairs if it's currently correct. I don't have a Mac capable of running any of the dev tools at the moment, but the implications of the section in the manual on the Int* types don't indicate they're boxed at all, nor give any reason why they should have to be. Of course, if he's declared everything as an NSNumber it could explain some of the results. But obviously, so could them currently being boxed. Either would probably account for the ++ performance problem, especially if it's post-increment, since that probably involves making a copy. I think the OP is just confusing the fact that they have expandable type as indicating that they have a virtual type.

reeses 12y ago

I would assert, rather, that we have 60 years of compiler and runtime experience, both academic and industrial. Consequently, I would propose that there is no excuse for a public release of a commercial programming environment to be so slow unless it introduces significant novelty sufficient to render the preceding work inapplicable.

mistermumble 12y ago
I agree. Especially if the language is named something that implies high performance. When Golang first appeared it was quite fast. Swift is not, apparently.
- xooyoozoo 12y ago
  Go's compilation was fast, which made developement much more pleasant. Performance of the actual compiled code was a different matter (hard to get both fast binaries and fast compilations). However, I understand that 1.1 and 1.2 has much improved code performance.
- axman6 12y ago
  Golang also doesn't do anything particularly interesting as a language, and didn't have to maintain interoperability with a system like Objective-C.