Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I can't really believe the Swift implementation needs to be that slow. Objective-C used to be 100% C compatible and Swift more or less has complete bridging to C because of the need to use these API's.

Objective-C was often called slow because iteration NSArray was much slower than doing it in C. Well, if you needed to do it fast in Objective-C you wouldn't do it using the user friendly and safe (for 1984) higher level objects.

I think only Rust really allows you to write really safe and still really fast code though.



Yes, we could write most of the critical part in C and it would probably be faster. But then it wouldn't be a Swift driver.


Are these benchmarks single-threaded? I took a brief look at the Swift codebase, and I noticed that you are using semaphores, but there doesn't seem to be any parallel execution anywhere in the project.


The Semaphore is only used during initialization, never in the critical path, see profiling results in the main repo


I don't think you need to write the critical part of the driver in C to speed up the swift implementation.

I clicked through to a performance analysis showing ARC taking about 3/4 the time (in the release build).

You don't really need to be doing a lot of ARC in the inner loops if you don't want to.


Yes, we do if we want to have an idiomatic interface for the application on top of the driver.

Pull requests proving otherwise are welcome


I don’t think it’s idiomatic to do a bunch of unnecessary memory management in inner loops, right?


The memory management is being done by the language.


ARC is implemented at the language level but it's not required. You can use it when and where you like.

One fundamental aspect of swift is the distinction between reference types -- which are reference counted -- and value types -- which are not. Generally in Swift you'd use a value type over a reference type unless you have reasons not to. E.g.: https://developer.apple.com/documentation/swift/choosing_bet...

I mean, I don't know what the right approach for this library is. The authors are going to have to fix their own code. IMO, coming up with a demonstrably poor solution and trying to defend it as "idiomatic" is pretty weak.


Well if the C# and Java implementations use C they're definitely not C# and Java drivers. But you don't need to use C directly, just use the C features that are supported by Swift itself.


C isn't in the critical path of either of those two implementations. GP is saying that it would be in a Swift version. Whether or not that's accurate I have no idea.


> I think only Rust really allows you to write really safe and still really fast code though.

Snabb (https://github.com/snabbco/snabb/) is written in LuaJIT . I assume an equivalent project in Rust would be a lot more expensive in implementation time and also lines of code.

There is also Common Lisp and SBCL in particular, which can produce extremely fast code without compromising on safety.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: