Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Swift Achieved Dynamic Linking Where Rust Couldn't (2019)

faultlore.com

Post reply on HN
Print view View original

191–200 of 279 posts

Re: Swift Achieved Dynamic Linking Where Rust Couldn't (2019)

#191

Post by Ygg2 »

pjmlp wrote: post #164
pornel wrote: post #50

Earlier quoted context omitted.

Apart from most perf critical cases, it's a good idea to run plugins in a separate process anyway. This way a bad plugin won't crash or corrupt your own process. You will be able to stop and unload it without risk of leaving locks locked or thread-locals leaking. And also there's WASM now which has even better sandboxing and OS/architecture independence.

WASM is nothing new, just a recyling of old ideas with refueled marketing.

Doesn't it work on all platforms? In theory, at least?

Re: Swift Achieved Dynamic Linking Where Rust Couldn't (2019)

#192

Post by josephg »

vetinari wrote: post #181
josephg wrote: post #134

Earlier quoted context omitted.

Yep. For hot call sites, these optimizations & inlining opportunities make a massive difference to performance. Static linking also allows for faster application startup time. (Though I don't have an intuition for exactly how slow dynamic linking is). The only argument for dynamic linking being more efficient is that each dynamic library can be shared between all programs that use it. But not a net win in all cases.…

> When you dynamically link a library, the entire library is loaded into RAM. It doesn't. When you dynamic link a library, no part of it is loaded into RAM. It is page-faulted in, as it is used. In the end, only parts that were really used were loaded into RAM.

A page will be loaded in if any part of it is useful. Given that functions will be laid out more or less randomly throughout a shared library, and programs use a randomly scattered subset of the functions, I think its safe to say that you'll get a lot of bytes read in to ram that are never used.

Especially when we take the filesystem's read-ahead cache into account - which will optimistically load a lot of bytes near any executed function.

If your program makes use of some arbitrary 10% of the functions in a shared library, how much of the library will be read from disk? How much will end up in RAM? Its going to be much more than 10%. I'd guess that you'll end up with closer to 50% of the library loaded in memory, in one way or another. (Though I could be way off. I suspect most of the time the filesystem cache will end up loading the whole thing.)

If its 50% loaded, a shared library thats used once will waste 90% of its download size & disk space and 50% of its ram usage compared to the equivalent static library. And make the application slower to start because it needs to link at runtime. And make the program slower to run because of missed inlining opportunities.

Re: Swift Achieved Dynamic Linking Where Rust Couldn't (2019)

#193

Post by ahartmetz »

gumby wrote: post #145

The TL;DR is: Swift strives for ABI stability, Rust does not. There's also a driveby comment that C++ doesn't really support dynamic linking because of all the templates in its standard library, which is a weird statement to make.

Yeah - the big, complicated parts of platform libraries for which post-release bugfixes make sense are usually not templated. The vector container class is a template, but Korean input method support is not.

Re: Swift Achieved Dynamic Linking Where Rust Couldn't (2019)

#194

Post by mid-kid »

greyw wrote: post #31

Dynamic linking is in my opinion not that useful anymore in this day and age where the few MB of RAM and disk space you save is not worth the hassle. The amount of dynamic linking issues I encountered on GNU/Linux was insane (fuck libstdc++). Not even glibc manages to keep forward compatibility working (breaking memcpy, breaking DT_HASH, ...)! It's much better to just statically link your binaries (unfortunately many…

> Just keep the object files around and relink them against the updated version of the static libraries.

This wouldn't work, as extra care needs to be taken to not break the ABI of a shared library. We have various conventions to aid with this including but not limited to "so versions", but these must be kept in mind by the library developer. Object file ABI stability isn't even guaranteed by the compiler.

Also, these days with LTO, the linking step takes a tremenduous amount of time anyway. Doing this wouldn't help much.

Re: Swift Achieved Dynamic Linking Where Rust Couldn't (2019)

#195

Post by pjmlp »

Ygg2 wrote: post #191
pjmlp wrote: post #164

Earlier quoted context omitted.

WASM is nothing new, just a recyling of old ideas with refueled marketing.

Doesn't it work on all platforms? In theory, at least?

Like plenty of other bytecode formats that predated it.

Re: Swift Achieved Dynamic Linking Where Rust Couldn't (2019)

#196

Post by pjmlp »

yakubin wrote: post #187
pjmlp wrote: post #163

Earlier quoted context omitted.

Dynamic linking also allows for extensible applications that have to otherwise be implemented with slower OS IPC calls, and higher resource costs in process and CPU cores management.

Which also prevents good privilege separation/sandboxing. See PAM vs BSD Auth, where the former cannot be secured with anything like pledge/unveil or Capsicum, but the latter can.

True, the question is if everyone is willing to accept the higher resource costs in process and CPU cores management to make it a non-issue.

Which given the mikrokernel hate in some circles, doesn't seem like it.

Re: Swift Achieved Dynamic Linking Where Rust Couldn't (2019)

#197

Post by audunw »

greyw wrote: post #31

Dynamic linking is in my opinion not that useful anymore in this day and age where the few MB of RAM and disk space you save is not worth the hassle. The amount of dynamic linking issues I encountered on GNU/Linux was insane (fuck libstdc++). Not even glibc manages to keep forward compatibility working (breaking memcpy, breaking DT_HASH, ...)! It's much better to just statically link your binaries (unfortunately many…

> Dynamic linking is in my opinion not that useful anymore in this day and age where the few MB of RAM and disk space you save is not worth the hassle

But space in fast cache IS worth the hassle. It's still extremely limited, and since we're hitting the limits of moore's law we're not getting much more of it.

The article touches on this. Statically linking can be a case of "tragedy of the commons" if you statically link a single program, you only see the benefits. But if you statically link all programs in a system, vs dynamic linking of all programs, you're giving up on the chance of having shared caching of commonly used pieces of code between programs, and you're giving up on minimizing code size so you don't have to prematurely evict useful code from the cache.

The article touches on this subject:

> It’s worth noting that the Swift devs [...] care much more about code sizes (as in the amount of executable code produced). More specifically, they care a lot more about making efficient usage of the cpu’s instruction cache, because they believe it’s better for system-wide power usage. Apple championing this concern makes a lot of sense, given their suite of battery-powered devices.

Re: Swift Achieved Dynamic Linking Where Rust Couldn't (2019)

#198

Post by Jach »

palata wrote: post #182
Jach wrote: post #123

Earlier quoted context omitted.

I like SDL2's approach to enable both: https://old.reddit.com/r/linux_gaming/comments/1upn39/sdl2_a... A game can statically link the library, but the user can with an environmental variable override the functions to point at their dynamic library instead. Very useful especially with games as you can then keep them running on new platforms or fix certain bugs even though the developers have long since disappeared or…

But then if it works with shared libs, you kind of lose the advantage of the static linking which was mostly (if I understand correctly) that dynamic library was not working well...

It's up to the user if they want to see whether the dynamic library is "working well". They work well for many people! But the statically linked version will be used unless their custom env variable is declared, everyone can be happy.

Re: Swift Achieved Dynamic Linking Where Rust Couldn't (2019)

#199

Post by lll-o-lll »

pcwalton wrote: post #176
jasmer wrote: post #117

Earlier quoted context omitted.

Rust will not replace C++. Everything is thrown out the window, including developer productivity in order to provide the 'zero overhead runtime guarantee' feature. The code ends up quite laborious, and it's just not suitable for many things, and it doesn't play so easily with C. Most projects do not require what Rust provides at the cost it provides it at. C++ people really wants a C++ that is clean, modern, parsable…

> Most projects do not require what Rust provides at the cost it provides it at. If this is true, it's because most projects should use a GC'd, memory safe language, not because most projects should use memory unsafe languages. There is little to no place for memory unsafe languages such as C++ for new projects in 2023. > Also I think that Rust is a 'V1' version of a borrow checker and I can't wait for newer iteratio…

Swift is memory safe. It’s the better C++ I want, just out of reach because Apple. There is at least one memory safe alternative to Rust that doesn’t require a GC.

I’ve made this argument before but here we go again. GC is great and works better and faster than reference counting in most cases, but there are degenerate cases and they matter on phones. One degenerate case is memory pressure. A GC running out of memory will perform terribly. Another case is bounded latency. Most obvious with hard real-time, but also a problem for any system where a long GC pause will lead to failure modes or user dissatisfaction. RC allows for predictable (albeit slower) performance.

So if we can agree that “no GC” is preferable in a constrained environment like a phone, but you still want memory safety, then you are left with “is Swift or Rust better for productivity?” It’s pretty obvious that the answer is resoundingly “Swift”.

Re: Swift Achieved Dynamic Linking Where Rust Couldn't (2019)

#200

Post by imron »

pjmlp wrote: post #177
imron wrote: post #174

Earlier quoted context omitted.

That doesn’t negate anything I said.

The way you phrased it kind of implies it being legacy and we still need to deal with it.

It kind of is legacy.

Yes, lower-level modern APIs are written in it, but you can write a modern windows GUI app without really needing to touch COM directly because there are other abstractions built on those APIs.

This was not as true of Windows programming 20 years ago.

Post reply on HN