Yeah, cheap local heap alloc + borrowing would be great
if swift will have moveonly value-types(moveonly struct) and borrowing rules like in rust(based on which to implement RAII) then there will be probability of higher swift performance without ARC and GC.
This is about implementing ownership and borrowing in swift similar to rust lang.
Yes Please!
It was addressed to @CTMacUser questioning, but i liked your answer a lot.
Some threads are already running to speak about some topics, and there's a trouble about community driven design at some point, that it works like a self-fulfilling prophecy.
You designed a language a certain way, and that turned that language popular to some crowd with a particular set of tastes. This in turn will make the majority of the people that consume your language ask for more of the things that appeal to their tastes, but by doing this, the language might not be appealing to other crowds that are not covered by your current language.
Sometimes, to make that big turn, to also appeal to other crowds, you must instead of just hearing the inner bubbles, see the people who are not being covered and therefore are not even speaking.
Swift have everything. A super nice language, its optimized for LLVM, have a great relationship with C and C++. Now there' s a couple of miles that if it goes for it, it will also make the language competitive with C++ and Rust. (Its all more or less defined in the 'ownership manifesto') All of this without stopping being a pleasant programming experience with initial baby-steps covered for the beginners and people that wont need to dive too much in the details (unlike the likes of C++ and Rust).
Speaking of Java, Java have promissed the world, and even when doing a lot, it couldnt deliver its promisse. The first language after Java that can actually deliver that promisse for me at least is Swift.
If it can be powerful as Java and C#, with good FP paradigms but being open and performant as C++, it will be a language to rule the world :).
4 Likes
It's great for iOS but Swift is cross platform and need to perform well on non-Apple hardware too.
If Swift performances are only optimized for Apple Silicon (or in this case not optimized because the hardware seems to be taking over that part), it's going to make Swift less attractive for other uses than making Apps.
9 Likes
Agree, and honestly we don't want to rely on hardware to cover up software API's that encourage inefficient behaviors. As we move towards being able to more clearly direct the CPU and memory subsystems to efficiently execute our intentions in ways that are natural for them (grabbing global locks to work on compute on one thread isn't natural), we will free up all the hardware to really "sing".
1 Like
Just to wrap this up- C, C++, Rust don't force global allocation, Swift ARC in effect does. This discussion has about adding ways to allow different kinds of local allocations, sub heaps, pools, etc. that would be tied with a single execution context (queue/thread) and therefore not need a lock to be accessed, dramatically increasing performance. - thanks guys and gals
This is an odd way to look at it. Swiftâs structs and enums are allocated directly and lack reference counts, just like the analogous features in Rust. If you use a class, you will incur allocation and reference-count costs, just as you would in Rust if you use Arc<>. Rust does have the ability to have unique references and non-atomic references, which Swift does not currently, but those are on the roadmap.
15 Likes
I think John was referring to Swift, not Rust. I think the roadmap he is referring to is the Swift roadmap.
1 Like
Let's remember that Swift engages more expensive subsystems when dealing with collections, mutable structs, strings, and other dynamic data. You can deal with each of these things in C/C++ without performance cratering. The idea is to figure out a way to do that in Swift without resorting to Unsafe.
Yes the regex-redux was terrible and was easy to get a big improvement over the code that was included in the repo.
In the end, the performance of that test relies on the underlying regex library, in this case ICU wrapped by NSRegularExpression.
The C implementation uses a different underlying regex library and is also made quicker by avoiding a memcpy of the new string, which Swiftâs implementation does not avoid. I looked at at briefly, and think it might be able to be made more efficient using replacementString(for:in:offset:template:) rather than stringByReplacingMatches(in:options:range:withTemplate:).
Not baffling, so much as it is telling of that the programmer wasnât particularly familiar with Swift + Foundation.
IS that the point?
I donât think that it is.
Taking the exact same line-by-line algorithm and writing it in different languages isnât reflective of what an experienced programmer might do when trying to write performant code in the language of choice.
For a realistic benchmark, Iâd expect each version to be written in a manner that was well-suited to the language employed, using the experienced developerâs knowledge of the languageâs idioms and constructs to produce performant code thatâs in the âspiritâ of the language.
(This is as opposed to an âall-outâ competitive benchmark, where the only goal is the best possible number, regardless of what insanity you need to do to get there.)
Ideally, the ârealistic benchmarkâ would also be the easy and straightforward implementation.
2 Likes
I agree with you 100%. To paraphrase (iirc) Larry Wall, the primary difference between programming languages is what they make easy. To adapt to benchmarking, we need to consider which algorithms the language's constructs, standard library and compiler make fast.
The question that should be answered in such comparisons is: when written using a language's idioms for time-efficient code, which language offers the best performance?
3 Likes
Why is this thread just arguing about goddamn benchmarks? The reality that I ran into with Swift is that I implemented a wire protocol parser in Swift that was way, way slower than doing the same thing in C++ because doing it the naive swift way meant that there was a ton of ARC overhead. Ok so I do some tricks to avoid copies and arc overhead as best I can and the thing is still dog slow. Could I continue to make it faster? Maybe, but it would mean learning the proper incantations du jour that will probably require rewriting in a couple of versions of Swift. OR I can just write it in C++ and even if I do a piss-poor job it'll still run faster than in Swift.
I haven't really been using Swift as much recently so I'm not up-to-date on the latest developments with Swift 5.1/5.2 (this thread is from a year ago) so maybe things have changed a little bit. But as far as I can tell in this thread (since I keep getting emails about it) is it's mostly people arguing about benchmarks or the philosophy behind benchmark or why this benchmark isn't relevant to swift or whatever.
At the end of the day people are going to experience crappy performance out of Swift and see better performance out of other languages that are targetting similar niches. Even if the code is naive. If you have to scale a mountain to get the thing to be a mere 400% slower than C++ rather than the usual 1200% slower is it really worth the effort?
4 Likes
Apologies for the frustrated post, my looking at this thread has been limited to reading the occasional email I get about it. I see that there's been more depth than the way I portrayed the discussion in here.
1 Like
All the more reason not to let a thread lives for too long.
You can also mute the thread.
2 Likes
I do think that this thread has gone on long past the point of productive discussion. I'm asking the moderators to consider locking it.
2 Likes
Cool is this transparent. How does one take advantage of this?
The push here is for the core team to make it transparent. We built an API way to do it, that we don't believe should be pushed to public consumption. The performance is great.
2 Likes