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

181–190 of 279 posts

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

#181

Post by vetinari »

josephg wrote: post #134
wtetzner wrote: post #109

Earlier quoted context omitted.

It depends on what kind of efficiency you care about more. Static linking can allow optimizations across library boundaries.

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.

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

#182

Post by palata »

Jach wrote: post #123
taeric wrote: post #33

Earlier quoted context omitted.

Security updates, though? I mean, you aren't wrong. But there were other advantages to dynamic linking.

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

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

#183

Post by Vogtinator »

greyw wrote: post #113
Joker_vD wrote: post #85

Earlier quoted context omitted.

Ah, so I (the programmer) build object files, send them to the distro maintainers, they link them with their specific versions of the libraries, ands send the resulting executable binary to me/other users. ...that's remote dynamic linking, only with (potentially) human intervention in the loop. I kinda see how it would have worked better if the distro maintainers cared about package quality and speedy updates but the…

The distro maintainers take your source code and package it. If they need to update the program due to an outdated dependency they don't need to recompile the whole program but rather just relink their cached object files with the newer version of the static library (if applicable).

Object files are compiled code with the API and ABI already baked in.

This approach effectively combines the downsides of static and dynamic linking.

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

#184

Post by tsimionescu »

pornel wrote: post #37
taeric wrote: post #33

Earlier quoted context omitted.

Security updates, though? I mean, you aren't wrong. But there were other advantages to dynamic linking.

Dynamic linking is not the only way to deliver security fixes, just one particular, limited, C-oriented solution. Note that dynamic linking is also not sufficient to change C++ templates or C header-only libraries. It shifts all of the code replacement complexity from the OS (just replace a file) onto the language and library authors (ABI compat, fragile base classes, no inlining or generics). Rust/Cargo gives you Ca…

Note that dynamic linking is also done in Java, C#, and any dynamic language. It's not something specific to C, not by a long shot.

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

#185

Post by bsaul »

acomjean wrote: post #116
wilg wrote: post #89

Earlier quoted context omitted.

This is all very hand-wavey. Are you just describing a chicken-and-egg scenario? Also, Swift probably can compete with Rust, especially when they finish adding Rust-style lifetimes. But the real advantage of Swift is it has a much more "high-level" feel than Rust – it's much more familiar to use than Rust by virtue of having classes and things. Swift also doesn't instantly force you into weeds of dealing with memory…

I think swift competes more with go than rust.

From an aestethic pov, swift is taking the exact opposite direction than go: it keeps piling on more language features, with much less concerns on keeping the language simple.

As a developer currently working in both, it feels like jumping to another civilisation every time i switch.

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

#186

Post by Vogtinator »

panzi wrote: post #149
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…

Redhat has .drpm, but I'm not sure at what granularity those diffs work. Maybe only on a per-file basis?

In (open)SUSE we also use delta RPMs. They work in a slightly odd way: The CPIO archive of the installed RPM is is rebuilt based on the installed files, then a binary diff is applied to create the new RPM. That is then installed. (ref: https://github.com/rpm-software-management/deltarpm)

It saves a lot of bandwidth, but takes a huge amount of local resources to install them so I just disable deltas everywhere.

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

#187

Post by yakubin »

pjmlp wrote: post #163
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.…

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.

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

#188

Post by palata »

lamontcg wrote: post #143
wongarsu wrote: post #129

Earlier quoted context omitted.

That pretty much sums up what everyone does on Windows. Lots of things are linked dynamically, but apart from the C/C++ runtime library and the OS libraries you just ship all those DLLs with your software. But this works because in Windows each software is installed in it's own folder, and the search path for dynamic linking starts in the binary's folder. That way you can just dump everything in your installation fol…

I did it for 10+ years at my last job, you need a build system that hammers on everything really hard to set the rpath on everything, you shouldn't need wrappers. It definitely isn't idiomatic though.

Could the rpath situation be improved there, or is it fundamentally limited? Seems like you got it to work, right?

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

#189

Post by astrange »

Kranar wrote: post #151
andyonthewings wrote: post #60

Earlier quoted context omitted.

It's a common argument of computers getting powerful so we don't need to care that much for performance and/or efficiency regarding to cpu/memory/storage etc. In some limited cases the argument is valid but most of the time it's not. First of all while maybe desktops and mobile phones are more powerful now, but we're getting more and more lower spec devices, like smart watches. Even when smart watches will be powerfu…

If what you care about is efficiency, then stick to static linking. Dynamic linking inhibits so many optimizations.

This is not the answer the performance engineers at Apple will give you, otherwise they would've done that.

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

#190

Post by astrange »

pkulak wrote: post #73
mr_00ff00 wrote: post #44

Earlier quoted context omitted.

I know this might be opening a can of worms, but technically doesn’t Swift do reference counting? Which is faster than “mark and sweep” GC but will never compare to manual management (like C/C++ and rust ownership) I assume that’s the big reason.

If reference counting was faster, Java would do it. It’s better for UIs and lower latency, but a modern, generational GC can beat C in throughput (because allocations get a lot faster).

If Java cared about being fast it'd have value types.
Post reply on HN