Rust to drop GNU ld for Rust-lld

https://blog.rust-lang.org/2024/05/17/enabling-rust-lld-on-linux.html
Your thoughts, schizo?

Unattended Children Pitbull Club Shirt $21.68

DMT Has Friends For Me Shirt $21.68

Unattended Children Pitbull Club Shirt $21.68

  1. 1 week ago
    Anonymous

    I am not sure. Is this dynamic linking?
    If so then rust desperately needed that.

    • 1 week ago
      Anonymous

      eww no, its not about dynamic linking

    • 1 week ago
      Anonymous

      its static linking, to use that in dynamic linking they'd have to modify the kernel

  2. 1 week ago
    Anonymous

    Interesting that they don't discuss lld in any depth on this post. They just assume the reader knows or doesn't care exactly why it is so much faster, and don't even provide a link to more information about it.

    • 1 week ago
      Anonymous

      GNU ld is single core, rust-lld is multicore.

      • 1 week ago
        Anonymous

        >There are different linkers, however, and the usual advice to improve linking times is to use one of these newer and faster linkers, like LLVM's lld or Rui Ueyama's mold.
        >...
        >Some of the big gains in performance come from parallelism, which could be undesirable in resource-constrained environments.
        I don't think the article needs more information than "lld is newer and multithreaded", they might not even know themselves. It's clearly faster and it seems to work.

        I guess running in parallel is self-explanatory enough, it just seemed strange to me how they only attributed to that "Some of the big gains" instead of "most". But with further thought, they can't exactly allocate any given speed-up to any particular design element, and it would vary from codebase to codebase. I also didn't notice that the first code block use of the name "lld" is, strangely, actually a link to a site where I could have grabbed the information I was expecting to be linked to. So, I guess mostly my bad here.

    • 1 week ago
      Anonymous

      >There are different linkers, however, and the usual advice to improve linking times is to use one of these newer and faster linkers, like LLVM's lld or Rui Ueyama's mold.
      >...
      >Some of the big gains in performance come from parallelism, which could be undesirable in resource-constrained environments.
      I don't think the article needs more information than "lld is newer and multithreaded", they might not even know themselves. It's clearly faster and it seems to work.

  3. 1 week ago
    Anonymous

    >linking problems start to popup
    >slowly but surely the linking times get slower and slower
    only death can cure mental illness

  4. 1 week ago
    Anonymous

    will this fix oom when i link big programs or not

    • 1 week ago
      Anonymous

      No but upgrading your 2GB RAM will.

  5. 1 week ago
    Anonymous

    why do rust trannies fear dynamic linking

    • 1 week ago
      Anonymous

      static linking is strictly superior. I dont expect fizzbuzz artists to understand.

      • 1 week ago
        Anonymous

        you are dumb

      • 1 week ago
        Anonymous

        >100MB for my special snowflake program
        >what do you mean the novel bytes are 150KB
        >I NEED those dependencies, you don't understand
        >what do you mean that every other fricking process running on the device uses those same libraries but isn't moronic like my special program?

        • 1 week ago
          Anonymous

          Dynamic linkage takes more space because the users need to install the entire Qt platform for only a part of Qt.

          Not that nocoders like yourself will understand, go back to your tinker troony minimal desktop threads

          • 1 week ago
            Anonymous

            you could say it takes less space than static linking when you have 2 apps that depends on a bunch of common shared objects, you only got to have 1 copy for both apps.

            both static and dynamic linking have its uses, but homosexual non coders usually prefer static because it's much easier to understand

          • 1 week ago
            Anonymous

            >when you have 2 apps that depends on a bunch of common shared objects,
            The likelyhood of 2 different apps using the same version of a library is very thin.

          • 1 week ago
            Anonymous

            I just told you, it depends on the case, for most cases static linking is the right choice, but for special cases dynamic linking is much superior, your DE uses dynamic linking, imagine if every program of your DE loaded their own libraries to memory instead of just one copy for all

          • 1 week ago
            Anonymous

            They wouldnt load the entire library, they would load the part of the library they need because of dead code elimination.

          • 1 week ago
            Anonymous

            dead code elimination isn't the panacea you imagine, library code is much more interwoven than you seem to realize and often the use of 1 function of a library pulls in more than half of its code
            it might work on an intentionally small libc like musl, but won't prove particularly handy in the general case.

            >when you have 2 apps that depends on a bunch of common shared objects,
            The likelyhood of 2 different apps using the same version of a library is very thin.

            tracking different versions of dependencies is usually a meme done by homosexuals coming from webdev
            in the world of binary software, APIs don't change drastically between releases, so unless glaring bugs are fixed or critical features are released you stick with either the distro's repo version or the latest support release at packaging time.

            static linking is strictly superior. I dont expect fizzbuzz artists to understand.

            static linking is strictly inferior in a POSIX environment; the OS can re-use code and data pages from a preexisting process that loaded a shared library without fetching from disk, reallocating memory pages, or even reinitializing static constructors.
            further, any page of library text that doesn't get used is never loaded into main memory if a process doesn't access it.
            this is strictly better than dead code elimination because both disk and system memory usage is lower and load times are decreased after the first execution. additionally, performance upgrades can be distributed to all dependents of a library with zero rebuild of the dependent code

          • 1 week ago
            Anonymous

            But I want to be lazy and use this metric ton shitty dependencies that break every two versions, you wouldn't understand.

          • 1 week ago
            Anonymous

            >library code is much more interwoven
            No, not really. The API endpoints can lead to a vastly different path of binary and its far, far slimmer than having the entire framework installed in your system. You don't need to load QNdefNfcUriRecord for your simple Qt todo app no matter how "interwoven" you fantasise libraries to be.
            > APIs don't change drastically between releases
            That maybe what you think but outside your obscure bubble, if an app needs Qt 5.7 symbols that are absent in 5.3, your program will not work. It's not a plug and play lego set like you think they are.
            >static linking is strictly inferior in a POSIX environment
            Static linking is strictly superior, POSIX or not. You are not special for using Linux.
            >OS can re-use code and data pages from a preexisting process
            Sounds like a single point of failure security nightmare.
            >any page of library text that doesn't get used is never loaded into main memory if a process doesn't access it.
            So just like static linkage except it does store the useless binary in the system? Ok.
            >both disk and system memory usage is lower
            How the hell is the disk usage lower? You are installing the entire framework?
            >rest of the AI written gibberish
            Pointless.

            The simple fact that you do not comprehend the fact that dynamic libraries are a bloat and these libraries are interchangeable indicates your severe lack of understand of the topic.

          • 1 week ago
            Anonymous

            since you don't seem to have dealt with this problem enough to make an informed comment, I'll resort to a simple fallacy:
            people smarter than you figured out that dynamic linking was a good idea decades before you were born and people smarter than you will continue to use and improve dynamic linking long after your twisted mutilated body turns to dust in an early, self-inflicted grave marked with the name your parents gave you at birth.

          • 1 week ago
            Anonymous

            I accept your concession. If you invested time in actual programming instead of rotting your brain with porn and tranime, you wouldn't be in this position of defeat and bitterness.
            If you are older than 25, give up. You are too old for it. Find a different hobby.

          • 1 week ago
            Anonymous

            sorry buddy, but my dynamically linked code with 125 executables and 250 dynamic libraries runs 20 million dollar robots from the bottom of the ocean to the edge of space.
            but sure I'll concede that static linking is maybe useful when making a game that uses bullet

          • 1 week ago
            Anonymous

            People in the past used dynamic linking because disk space was a concern and it had to be done. Its still done in the unix world today due to tradation and for mostly moronic invalid autistic reasons that distro maintainers give that even Linus has called moronic for. Vast majority of reasons people have for dynamic linking aren't good reasons for it.

          • 1 week ago
            Anonymous

            disk space isn't the only thing limited.
            memory is limited, file handles are limited, swap space is a huge risk to use, etc.
            limiting the amount of pages allocated and files loaded is always good, and dynamic linking of common libraries helps tremendously.

          • 1 week ago
            Anonymous

            >People in the past used dynamic linking because disk space was a concern and it had to be done.

            static linking waste both disk and memory, if two programs use the same code, why the frick you are going to load it twice?

            >Its still done in the unix world today due to tradation and for mostly moronic invalid autistic reasons that distro maintainers give that even Linus has called moronic for.

            it is still done because no one came up with a better approach over the years, but don't worry bro, you can keep static linking your hello world apps, actual programmers will keep using dynamic linking when necessary.

          • 1 week ago
            Anonymous

            The only thing the codes usually share is libc, thats it. Dynamic linking is deprecated.

          • 1 week ago
            Anonymous

            >The only thing the codes usually share is libc
            all rustslop fizzbuzz clones use the same ncurses rewrite though

          • 1 week ago
            Anonymous

            That's because Rust can't into GUI yet
            And no it's not funny, in fact, experts say it's a sign of healthy progress. And you don't need a GUI for most things anyway so what's the hurry?

          • 1 week ago
            Anonymous

            >Rust can't into GUI
            Black person, there is an entire Desktop Environment written in Rust. The frick are you on about?

          • 1 week ago
            Anonymous

            >the same ncurses rewrite
            And what library would that be?

          • 1 week ago
            Anonymous

            >Its still done in the unix world today due to tradation and for mostly moronic invalid autistic reasons that distro maintainers give that even Linus has called moronic for.
            Unix shills were the only people complaining about dynamic linking. Dynamic linking works fine everywhere else. Windows uses it for everything. DLL stands for Dynamic Link Library.

          • 1 week ago
            Anonymous

            >we can waste storage space and memore because we live in DA FUTURE
            Also, I would love to see you trying to statically link OpenGL

          • 1 week ago
            Anonymous

            You can do that with Mesa if you're deranged enough.

          • 1 week ago
            Anonymous

            What are you, some kind of gnomosexual? Don't you already have Qt installed?

          • 1 week ago
            Anonymous

            Because I have a job and I cannot afford to waste my time debugging KrashDE. I have better hobbies.

          • 1 week ago
            Anonymous

            They wouldnt load the entire library, they would load the part of the library they need because of dead code elimination.

            Compilers are terrible at purging unused sections. "Dead code elimination" is a meme because your program is allowed to create arbitrary function pointers to library code (this applies to both C/C++ and unsafe Rust, so the compiler can't take any chances). It does work better if you compile the whole program as a single unit (in other words, you have source available).

          • 1 week ago
            Anonymous

            So basically static linking? Oh wow who knew.

          • 1 week ago
            Anonymous

            Static libraries contain machine code, not source code. rustc produces rlibs and gcc/clang produce archive libraries (.a files). You have to do a lot more work to compile your program as a single unit with all library source code.

          • 1 week ago
            Anonymous

            >Compilers are terrible at purging unused sections
            Stop using shit compilers. Lisp has been eliminating dead code from the 60's.

        • 1 week ago
          Anonymous

          >100MB for my special snowflake program
          Oh, the horror!
          It isn't 1980 anymore who gives a shit?

          • 1 week ago
            Anonymous

            that's 100MB each time your program is executed.
            hope you don't get run in a shell script

          • 1 week ago
            Anonymous

            One day, we, the sane programmers of the world will come together and initiate Total Unixtard Death, and we won't have to worry about your autistic self-imposed problems anymore.

          • 1 week ago
            Anonymous

            >trannies
            >sane
            here's to hoping you make it past 45!

        • 1 week ago
          Anonymous

          Windows is much better for your cases

  6. 1 week ago
    Anonymous

    Compile times are irrelevant. Compilation happens once but same software is ran possibly billions of times. Devs are moronic.

    • 1 week ago
      Anonymous

      Your point being? Shorter compile times lead to better software.

      • 1 week ago
        Anonymous

        It doesn't. If anything long compile time hives programmer reason to think of what he is making instead of twiddling with shit until it magically works.

        • 1 week ago
          Anonymous

          >hives
          gives

    • 1 week ago
      Anonymous

      >This good thing is meaningless because it's not this other good thing that nobody mentioned.
      Really good criticism there, anon. Please go derail some other thread.

    • 1 week ago
      Anonymous

      >Compilation happens once
      tell me you've never worked in the industry without telling me you've never worked in the industry

      • 1 week ago
        Anonymous

        this is not unreasonable
        picture made by someone uninitiated

  7. 1 week ago
    Anonymous

    Rust is not using GNU ld now, it's using LLVM's lld, so it will eventually drop LLVM lld for its own rust-lld

  8. 1 week ago
    Anonymous

    > some ramblings about GNU
    > they're merely moving on from LLVM
    > somehow LLVM is now GPL
    rust troony Black folk are the most profoundly moronic troony Black folk i've ever seen. frick off and die, thanks. you dumb fricking trannies don't even know what the frick you are shilling.

    • 1 week ago
      Anonymous

      Jesse what the frick are you talking about

  9. 1 week ago
    Anonymous

    linking time is negligible, rust will always have a slow compilation phase

  10. 1 week ago
    Anonymous

    It makes sense for a language to have its own linker. Unfortunately, this is literally just switching to lld from LLVM. It's not a linker implemented in Rust.

  11. 1 week ago
    Anonymous

    Man in the middle attack

  12. 1 week ago
    Anonymous

    LMAO why did it take them so long? why don't they just copy the Go way of compilation and forget about slow compilation times?

    • 1 week ago
      Anonymous

      Go has no static dispatch.

      • 1 week ago
        Anonymous

        >static dispatch
        not an argument
        it has dynamic reception which is 10x better

        • 1 week ago
          Anonymous

          You mean 10 times slower.

  13. 1 week ago
    Anonymous

    Good. There's thousands of compilers but only a handful of linkers around. More choices is a good thing, unless you're a communist that is.

  14. 1 week ago
    Anonymous

    did gcc rust compiler drop already
    not going to use rustc because of circular dependency hell (having to compile every single rustc to compile current rustc)

    • 1 week ago
      Anonymous

      Why are you compiling rustc? Don't you have anything better to do?

Your email address will not be published. Required fields are marked *