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

141–150 of 279 posts

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

#141

Post by saghm »

andyonthewings wrote: post #60
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…

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…

> 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 powerful enough one day, there will be eventually smaller computers, like smart contact lens, nano robots that run in blood vessels etc.

My desktop/laptop distro dynamically link everything by default just so it can be slightly less work to port to a smartwatch? That sounds like a reasonable argument for having dynamically linking be possible, but it doesn't seem compelling for it being the default for the entire world.

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

#142

Post by riscy »

sweetjuly wrote: post #84
alin23 wrote: post #13

This past week I’ve been reverse engineering the macOS IOMobileFramebuffer to find a way to disconnect displays in software for Lunar ( https://lunar.fyi/ ). And I kept stumbling upon these witness tables while debugging. This led me to find this write-up and the much more interesting story behind it. The end note was priceless ^_^ collapses

I feel your pain, reverse engineering Swift is such a nightmare. I don't know if Ida handles it better but both Ghidra and Binja produce entirely inscrutable disassembly.

Hopper has support for Swift: https://www.hopperapp.com/

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

#143

Post by lamontcg »

wongarsu wrote: post #129
lamontcg wrote: post #108

Earlier quoted context omitted.

If you don't care about saving disk space then just ship all your dynamic libraries with your binaries.

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.

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

#144

Post by rektide »

charcircuit wrote: post #125
rektide wrote: post #87

Earlier quoted context omitted.

We run hundreds of processes on big nodes at work & we absolutely would save hella hella memory & have way better cache utilization if we could share the massive massive massive reams of code each process duplicates for itself. Static linking is basically like running Electron. You take a wonderful multi-machine capable environment then use it to run a single thing, exacerbating the size of what should be minor overh…

>We run hundreds of processes on big nodes at work & we absolutely would save hella hella memory & have way better cache utilization if we could share the massive massive massive reams of code each process duplicates for itself. Assuming those hundreds are mostly duplicates why can't they all share their entire code section?

There's ~60 different things we run. It would be tempting to try to make some kind of a group scheduler. But on the other hand, we get some nice load levelling/load-averaging from having mixed processes. Ultimately there's not really any reason for us to have static linking, but it's just "how it's done" now and it's unquestioned and there aren't as many well established alternatives as there ought to be.

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

#147

Post by travisgriggs »

What a great write up.

> Swift reserves a callee-preserved register for a method’s self argument (pointer) to make repeated calls faster. Cool?

Years ago (2000 I think), I remember Eliot Miranda explaining that the biggest optimization—-over and above all the jit stuff—in the VisualWorks Smalltalk VM basically came down to something very similar: very specific management of registers for the commonest of calling patterns.

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

#148

Post by Shorel »

malkia wrote: post #39
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…

You can't ship reasonable plugin for most of the popular content creation tools - be it audio, video effects, 3d modelling, etc. without support for dynamic/shared libs. Okay, maybe you can - at the risk of performance cost - e.g. your out-of process plugin that need to move data in/out with a cost, and then it over complicates - because the plugin process might've died - how do you restart it, how do you get it back…

You can, just change the strategy.

Shared memory exists.

That's how we read timing information from AMS, Project Cars 2, AMS2, rFactor2, etc.

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

#149

Post by panzi »

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?

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

#150

Post by musicale »

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…

Interesting suggestion - basically treating a statically linked binary as a cache which is invalidated when any of the dependencies is updated, triggering either proactive or reactive relinking.

The disadvantage vs. dynamic linking is that you can't easily replace libraries on the fly. It is less flexible but it might actually be better for security. Dynamic linking could be emulated, albeit slowly, by relinking each time a program is launched. This would be slower but potentially useful for certain purposes such as debugging.

Post reply on HN