Hacker News Reader

Comment by SoftwareMaven | Hacker News Reader

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.

View on HN

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.

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.

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.

Golang also doesn't do anything particularly interesting as a language, and didn't have to maintain interoperability with a system like Objective-C.

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.

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-m...

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.

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.

I think that's hardly the case. Or are javascript and python and ruby self-defeating as well?

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.

No, the point is to ease application development.

If you could use a high-level dynamic language to write performant code without "bit-fiddling", why would anyone write in anything else?

The most commonly-heard excuse is that programmers do not like all the parens.

Reply on news.ycombinator.com