>C Is Not a Low-level Language: Your computer is not a fast PDP-11.

>C Is Not a Low-level Language: Your computer is not a fast PDP-11.
What do rustaceans mean by this? Computers are still using a Von-Neumann/Harvard architecture and a Turing machine is still their core abstraction. Therefore they are in a way faster PDP-11s, only with extra bloat and more abstractions.
>inb4 you are wrong
If computers are not fast PDP-11s then what are they?
If C is not a low level language just with super optimized compilers that understand the intent and replace your awful slow code with faster one without telling you then what is it?

CRIME Shirt $21.68

The Kind of Tired That Sleep Won’t Fix Shirt $21.68

CRIME Shirt $21.68

  1. 2 months ago
    Anonymous

    >just with super optimized compilers that understand the intent
    It's better to just be able to specify the intent rather than have the compiler try to reverse engineer it.

    • 2 months ago
      Anonymous

      Yes, and unironically this is exactly where things are going, an interactive dialectic system that is "programmed" in natural verbal and non-verbal human communication that is going to guide you towards expressing and understanding your intent and then proceed to implement your intent in the most optimized way.

      But we are not there yet and this is not the ask of this thread.

      • 2 months ago
        Anonymous

        I get why some look at LLMs and think this but as soon as you deepen the thought you realize how impossible it is. Language is too abstract after a certain level, this is why we program with keywords and data parading as linguistic conventions and I do not see this changing without hundreds of years worth of data.

        • 2 months ago
          Anonymous

          >llm
          I never said llm or ai
          >hundred of years
          Maybe, or maybe next year, or maybe never but things are going towards this direction and I don't see why this couldn't be possible.

      • 2 months ago
        Anonymous

        Doesn't work. If it did C++ was faster than C; it isn't, and anyone who claims otherwise never did any sort of measurement or actively cheated.

        No you fricking homosexuals, I'm not talking about natural language BS, I'm talking about having language features that are oriented to generating IR rather than ASM. I.e. stop pretending to "talk with the hardware" and rather "talk with the compiler", which is what you're actually doing. Most of the new memelangs actually do that.

        • 2 months ago
          Anonymous

          >new
          and old ones don't? midwit

          • 2 months ago
            Anonymous

            What are you talking about?

          • 2 months ago
            Anonymous

            Pretty sure gcc uses an IR too, this isn't new

          • 2 months ago
            Anonymous

            ???
            Do you understand what I typed?

          • 2 months ago
            Anonymous

            Not really, I don't get what
            >talking about having language features that are oriented to generating IR rather than ASM
            means. Can you give a concrete example

          • 2 months ago
            Anonymous

            not him but even old compilers allow you to change one concrete function's optimization level, mark it cold, mark branches in a way that causes compiler to reorder them, restricted pointers... beyond that there's no other magical things

          • 2 months ago
            Anonymous

            It's about having language constructs that are aimed at direct IR generation.
            Let me show you an actual example actually, from another thread a few weeks ago.
            https://godbolt.org/z/Kscj5TYrq
            Bottom thread is the naive approach, top one is using Clang vector builtins, which is what I call IR-oriented primitives (note, this is different from using raw AVX builtins). To quote the original guy "it's exposing the same internals like you see on those LLVM based memelangs with builtin vector type matrix etc only with nice syntax"
            Top solution is extremely explicit about what you're trying to do. It ends up being 6.3 times faster than the bottom solution. Compilers are very limited when it comes to reverse engineer your code's intention, having language features that let you specify them directly is a tremendous help.

          • 2 months ago
            Anonymous

            write recursive factorial and compile with -02 -march=native, midwit, compilers do a lot for you and you need to shut the frick up

          • 2 months ago
            Anonymous

            You're free to add the compilation flags you want and show how any compiler would optimize the naive example better. You can even rewrite it better, as long as you use standard C.
            You will find out there is no standard C code that will generate the same efficient ASM. Even with Polly.

          • 2 months ago
            Anonymous

            the "naive" example with -march=native is gigavectorized, that code is inane magic to me, and that's my point

          • 2 months ago
            Anonymous

            >gigavectorized
            https://godbolt.org/z/cj57Mh8ae
            Wut?

          • 2 months ago
            Anonymous

            add -march=native in the field, there's a reason some people compiler software at home

          • 2 months ago
            Anonymous

            There's "-march=skylake" right there you triple Black person. Same result with native.
            Don't use `native` on Godbolt, you don't know what it's compiled on.

          • 2 months ago
            Anonymous

            I just glanced at the page and saw only -O3 then immediately closed it, because I assumed that you wouldn't (You) me with irrelevant code that I said nothing about, you disingenuous Black person, also I know that they use intel cpus and don't care about your cope since no other architecture is relevant

          • 2 months ago
            Anonymous

            Skylake is Intel you absolute moron.
            It's not vectorized. If you saw some vectorized code with -march=native, post the fricking link instead of writing nonsense.
            >I just glanced at the page
            No, what happened is you lied and just assumed native would produces vectorized code without checking. And now you're reaching for branches on your way down you disingenuous frick.

          • 2 months ago
            Anonymous

            English as 27th language bro, I wrote factorial, it's a specific algorithm. I am not responsible for your bad unrelated to factorial code having bad ISA generation.

          • 2 months ago
            Anonymous

            I didn't ask you about factorial, did I?
            >the "naive" example with -march=native is gigavectorized,
            Then post it. You didn't just say something without checking, did you?

          • 2 months ago
            Anonymous

            >actually English 27th Language

          • 2 months ago
            Anonymous

            Post the link

          • 2 months ago
            Anonymous

            recursive factorial is trivial to write and I have nothing to prove, do your own research

          • 2 months ago
            Anonymous

            Post the link

          • 2 months ago
            Anonymous

            TCO in Clang is super limited. It can only do strict TCO, it can't do tail modulo cons, and it can't do TCO across multiple functions.

          • 2 months ago
            Anonymous

            just inline bro
            Anyway, it's all a threatre, people will forever have to tinker with code and keep giving compilers hints no matter how "close to metal" (lol, lmao) your language gets

          • 2 months ago
            Anonymous

            Well yeah, that's the point, it's better to focus on the language ability to converse with the compiler rather than an fictive metal-closeness.

          • 2 months ago
            Anonymous

            Ah I get what you mean, yeah that could obviously cause a huge performance boost

            write recursive factorial and compile with -02 -march=native, midwit, compilers do a lot for you and you need to shut the frick up

            Why so hostile? And compilers can't really optimize something like
            if (true 99.9% of the time) {....}
            else {....}
            without explicitly saying something.

          • 2 months ago
            Anonymous

            >AOTcompiler cannot know runtime values
            uhhh yeah? Though there are JIT's that can and do

    • 2 months ago
      Anonymous

      Doesn't work. If it did C++ was faster than C; it isn't, and anyone who claims otherwise never did any sort of measurement or actively cheated.

      • 2 months ago
        Anonymous

        of course cnile pushes back in a hot loop without reserving first because his low IQ prevents him from figuring out anything beyond operator[] and push_back

        • 2 months ago
          Anonymous

          >cnile pushes back in a hot loop
          What else do the voices in your head tell you that has nothing to do with reality?

          What produces that report? Is it just perf?

          No, unlike most of IQfy I actually write code.

          • 2 months ago
            Anonymous

            you don't know what you're benchmarking and it shows

          • 2 months ago
            Anonymous

            You don't know what you're supposed to project, and it shows.

          • 2 months ago
            Anonymous

            Well I don't need to project benchmarking my system's allocator, because it's what you did, midwit.

          • 2 months ago
            Anonymous

            >he thinks there's only one
            You're clearly not intelligent enough for this discussion.

          • 2 months ago
            Anonymous

            who are you quoting?

          • 2 months ago
            Anonymous

            >my system's allocator
            >singular
            You.

          • 2 months ago
            Anonymous

            do you know something about my system that I don't?

          • 2 months ago
            Anonymous

            Yeah, obviously:

            Doesn't work. If it did C++ was faster than C; it isn't, and anyone who claims otherwise never did any sort of measurement or actively cheated.

          • 2 months ago
            Anonymous

            I see, didn't know that you backdoored my system then ran benchmarks on it...

          • 2 months ago
            Anonymous

            Your system isn't special. Get over it.

          • 2 months ago
            Anonymous

            Unlike you I configured and compiled my kernel and know what it has and doesn't have, but please tell me more about things you don't know.

          • 2 months ago
            Anonymous

            >I configured and compiled my kernel
            So have I. But the configuration and compilation of a kernel is mostly irrelevant for the crap userspace has to go through, which is why the benchmark clearly states which allocations are probably userspace-based and which are kernelspace-based.

          • 2 months ago
            Anonymous

            >So have I. But the configuration and compilation of a kernel is mostly irrelevant for the crap userspace has to go through, which is why the benchmark clearly states which allocations are probably userspace-based and which are kernelspace-based.
            mfw Linux ignored my configuration and compiled all available allocators despite my requests

          • 2 months ago
            Anonymous

            >he doesn't understand the difference between kernelspace and userspace code
            As I said, you're not intelligent enough for this discussion.

          • 2 months ago
            Anonymous

            tell me more about those hidden different system allocators

          • 2 months ago
            Anonymous

            Doesn't work. If it did C++ was faster than C; it isn't, and anyone who claims otherwise never did any sort of measurement or actively cheated.

          • 2 months ago
            Anonymous

            I see, you don't seem to be intelligent enough to comprehend what I'm actually asking, thank you for your time, have a nice day.

          • 2 months ago
            Anonymous

            You don't know what you're asking because you're not intelligent enough to ask the right questions.

      • 2 months ago
        Anonymous

        What produces that report? Is it just perf?

      • 1 month ago
        Anonymous

        >anyone who claims otherwise never did any sort of measurement or actively cheated.
        Ironically the picture attached to your post is disingenuous

        • 1 month ago
          Anonymous

          Ironically no one outside your head cares whatever nonsense the voices inside your head are screaming at one another.

    • 2 months ago
      Anonymous

      >It's better to just be able to specify the intent rather than have the compiler try to reverse engineer it.
      Depends entirely on the algorithm and the programmer. Sometimes the compiler wins that contest, sometimes a good assembly dev. That said, compilers have to be so aggressive in large part because of the higher level languages that C-haters promote. Babies are crying that C compilers "change the code!!!" while never looking at what gets spit out for their language.

      And aggressive optimization has bled into the CPU die itself. Fricking Apple ARM chips now look at the cache and try to guess which integers are really pointers to prefetch more data. Why? Because everything in higher level languages is scattered across memory. Linked lists with nodes that are linked lists containing nodes to more linked lists. Indirection to indirection, abstraction upon abstraction.

      One of the simplest things you can do in C for performance is think about your problem and, if possible, store the data in a contiguous block. Why? Now any CPU dating back to the 90s can successfully prefetch data while the ALU/FPU are working. Think you can do that with your Java Enterprise objects, indented Python, or functional Haskell?
      >stall stall stall

      • 2 months ago
        Anonymous

        A lot of text to say nothing.
        >Babies are crying that C compilers "change the code!!!" while never looking at what gets spit out for their language.
        Nobody claimed higher level languages don't get transformed.
        >muuuh linked lists
        Do you even realize that nobody uses those in languages that offer better data structures?
        >store the data in a contiguous block.
        C is the worse system language for that due to the reliance on linked lists and arrays of structs. Generics and SoA structs, which are present in all the newfangled system languages, solve that.

        • 2 months ago
          Anonymous

          The only TLA that comes to mind with SoA is Service Oriented Architecture, which is not what I think you mean. What is a SoA in what you write?

          • 2 months ago
            Anonymous

            I figured out what you meant, but I don't think SoA is a particularly great or modern idea in that instruction sets like AVX-512 include scatter/gather instructions (which are quite popular). Why modify the code you are writing to the architecture? Isn't the ideal that the code you write is specialized to the problem itself such that you can express the algorithm with maximum brevity and clarity? If that method is SoA, so be it, but fracturing structures just to provide clarity to an optimizer seems backwards in an ideal world.

          • 2 months ago
            Anonymous

            Well, the nice thing about languages that have Struct of Array data structures, is that you write the same code that would with an AoS structure. For example in Zig, you would write my_soa[i].attribute.You just replace the ArrayList type with a MultiArrayList. Rust has soaderive, and I'm pretty sure Odin has something like that too. C++ has some SoA libraries, but they will remain shitty until the language gets real reflection.
            >AVX-512 include scatter/gather instructions
            Oh man, haven't you heard? The GDS mitigation last summer absolutely destroyed gather instructions. Intel reports you can expect 30 cycles in a gather instruction, and that's assuming everything is already in cache. That doesn't solve the main issue anyway: if you're using AoS and you're traversing an array to only use half the fields, you've effectively divided your memory bandwidth by 2.

          • 2 months ago
            Anonymous

            >you can expect 30 cycles in a gather instruction
            Can't say I'm surprised.

          • 2 months ago
            Anonymous

            >I figured out what you meant...instruction sets like AVX-512 include scatter/gather instructions (which are quite popular).
            Is that what he was getting at? Those do not address what I was getting at in the least. They're not a general solution/alternative for cache prefetch.

            >I also want to push back against the idea that a 'c' style array of structures is somehow inappropriate for modern (very much not PDP-11) architectures.
            >C may not have been designed for the hardware of this era, but its ideas sure seem to work.
            C didn't invent any of that. They just ripped off what other languages did. Arrays of structures are not "C's ideas."

            You miss the point that most languages encourage the opposite.

            literally just read the fricking paper dumbass
            https://queue.acm.org/detail.cfm?id=3212479
            but if you're too brainlet to into that, riddle me this
            >what is NUMA and cache coherency

            >>what is NUMA and cache coherency
            One of the dumbest parts of the paper. Cache is not hidden because of C, it's hidden because outside of niche applications only the hardware can effectively manage it. All common ISAs present a flat memory model, which is what C presents to the programmer.

          • 2 months ago
            Anonymous

            I meant that AoS are going to have very regular access patterns that will be picked up (I assume) by hardware prefetchers.

            >>Oh man, haven't you heard?
            Didn't click, but https://www.phoronix.com/review/downfall (if this is the same vulnerability) seems to indicate current cpus are not affected - which I take to mean sapphire rapids and emerald rapids. Lets call that an implementation detail. At some point this stuff is going to get figured out.

            >>you've effectively divided your memory bandwidth by 2.
            fair.

            >>Well, the nice thing about languages that have Struct of Array data structures
            super interesting. Thanks.

          • 1 month ago
            Anonymous

            > patterns that will be picked up (I assume) by hardware prefetchers.
            That's only relevant for very big structs. For smaller structs you're gonna have to fetch every cache line anyway.

        • 2 months ago
          Anonymous

          >A lot of text to say nothing.
          Just admit you didn't understand it.

          >Nobody claimed higher level languages don't get transformed.
          Now follow through to the next point: if C is faster for any given compiler optimization level, then it's faster for reasons that have nothing to do with compiler optimization. Or is that simple logic too much for you?

          linked lists
          >Do you even realize that nobody uses those in languages that offer better data structures?
          Tell us what you have in mind so I can point out that it also scatters data across RAM.

          the data in a contiguous block.
          >C is the worse system language for that due to the reliance on linked lists
          LMFAO C arrays are just blocks of memory.

          >and arrays of structs.
          Also just blocks of memory unless you implement it differently.

          >generics!
          Have nothing to do with the point.

          • 2 months ago
            Anonymous

            >Now follow through to the next point: if C is faster for any given compiler optimization level, then it's faster for reasons that have nothing to do with compiler optimization. Or is that simple logic too much for you?
            "C" isn't faster, generated code is, you can design language and compiler faster than current C, except that would cost billions of dollarinos because noone wants to do it for free.

          • 2 months ago
            Anonymous

            >"C" isn't faster, generated code is
            Yet it's also faster in general if optimizations are turned off. I guess that simple logic did escape you.

            >Your computer is not a fast PDP-11
            It is. Sneed more troony scum.

            I'm waiting for someone to post a picture of a PDP-11 with a handwritten note:
            >4/14/2024 IQfy

          • 1 month ago
            Anonymous

            >Tell us what you have in mind so I can point out that it also scatters data across RAM.
            Dequeues, Scala arrays (both linked blocks), Numpy arrays (contiguous with skip lists), Arrow buffers (blocks), etc.
            As long as you need a non trivial DS in C, you know you're just gonna use single element linked lists. Don't lie, that's how the kernel does it too.
            >Also just blocks of memory unless you implement it differently
            If you don't understand the issue with AoS, I'm actually not gonna waste my time explaining. Read the Intel doc.

          • 1 month ago
            Anonymous

            >As long as you need a non trivial DS in C, you know you're just gonna use single element linked lists.
            If by that you mean "they're gonna use a pointer somewhere" then maybe so, but you're so far up your own ass that you ought to be seeing daylight through your nostrils by now,.

          • 1 month ago
            Anonymous

            More like "they're gonna use a pointer for every element", which is what you have to do when you use intrusive linked lists, as in the Linux kernel.

          • 1 month ago
            Anonymous

            Hah. Reality is rather more complicated than that. Containment versus referencing isn't simple at all; it's a balanced trade-off and always was.
            Containment, embedding the value within the data structure, is potentially more efficient... but not if you end up having to copy it more often.
            Referencing, just storing a pointer to the value, means you (typically) have more allocations and more overhead... but potentially fewer copies. (Leaning into immutability can help a lot by getting rid of spooky action-at-a-distance interactions.)
            Which is best? It all depends on what you're doing exactly, and how you're doing it.

  2. 2 months ago
    Anonymous

    you sound very knowledge OP, do you have any tech blog recommendations we can read? this is a genuine reply and I am not trying to be disingenuous

    • 2 months ago
      Anonymous

      >knowledge
      knowledgeable*

    • 2 months ago
      Anonymous

      No, I'm stupid, I just possess barely enough "intelligence" to keep breathing, I'm just hoping for a clever anon to explain what this phrase means.

    • 2 months ago
      Anonymous

      C is special because the PDP-11 was special. B, Cs predecessor, was interpreted and did not even have types (Because the PDP-7 didn't). C was a complete overhaul, and of course C was originally used for writing UNIX, so its naturally a low-level language.
      I suppose it was just in the right place at the right time. Computers really haven't changed much... well, the front-ends haven't. We have branch prediction, Out-of-order execution, cache hierarchies, etc., but that's all out of view. If you can drive a small four cylinder Honda you can drive a ten cylinder bus (Perhaps not to well, but driving is still driving!). Compiler abstraction is yet another thing solidifying Cs place in the present moment, since compilers can adapt to new architectures while still implementing the same C standard.

      C isn't going anywhere anytime soon.

      • 2 months ago
        Anonymous

        midwit take, driving a bus requires special license for a reason

        • 2 months ago
          Anonymous

          I didn't need a license, gay.

        • 1 month ago
          Anonymous

          Oi mate! You gotta license for writing that C code?

      • 2 months ago
        Anonymous

        >of course C was originally used for writing UNIX, so its naturally a low-level language.
        Rust and c++ is used to develop linux and windows, are those low level languages?

        • 2 months ago
          Anonymous

          nobody writes Rust for Linux, support for Linux modules in Rust is just a security theatre and will never catch on

      • 2 months ago
        Anonymous

        >C is special because the PDP-11 was special. B, Cs predecessor, was interpreted and did not even have types (Because the PDP-7 didn't).
        The PDP-11 was not special apart from being commercially successful, did not have types, and was not fundamentally different from the PDP-7. It was just newer in terms of build and had some newer opcodes and features.
        https://en.wikipedia.org/wiki/PDP-11_architecture
        http://bitsavers.trailing-edge.com/pdf/dec/pdp7/F-75P_PDP7prelimUM_Dec64.pdf

        With rare historical exception, CPUs deal in binary integers. That's it. If there's a FPU attached then they can also deal in floating point values. You can also find examples that directly supported BCD, but that fell out of favor by the time microprocessors were invented. Every type apart from binary integers and floating points is an abstraction built on one or the other (usually the integers).

        >We have branch prediction, Out-of-order execution, cache hierarchies, etc., but that's all out of view.
        Exactly.

        >C isn't going anywhere anytime soon.
        Nope, and rustroons seethe while lispygays rage.

  3. 2 months ago
    Anonymous

    C is low (intelligence) level language, and that's just a solid fact.

  4. 2 months ago
    Anonymous

    >rustaceans
    they are autisticm all languages compile to 1s and 0s so who the frick cares

    • 2 months ago
      Anonymous

      THIS! SO MUCH THIS! We are all pink in the inside at the end of the day!

      • 1 month ago
        Anonymous

        bot

  5. 2 months ago
    Anonymous

    >What do rustaceans mean by this?
    REEE REEE CHANGE ALL THE SYNTAX REEE REEEEEEEE!!!!!! POSTINCREMENT... LE BAD!!!! POINTERS... LE BAD!!! CHANGE IT ALL!!!!!!!

    • 2 months ago
      Anonymous

      reminder that bitwise not in Rust doesn't do what you expect it to do

      • 2 months ago
        Anonymous

        never used rust. qrd me daddy

        • 2 months ago
          Anonymous

          at some point ~ allocated memory, now it is deprecated, rust trannies cannot use ~ to mean bitwise not due to backwards incompatibility or something

    • 2 months ago
      Anonymous

      Changed syntax is a good thing because it allows cniles suffering from baby duck syndrome to realise that they have a problem and get a diagnosis

  6. 2 months ago
    Anonymous

    >Therefore they are in a way faster PDP-11s, only with extra bloat
    have a nice day NOW

  7. 2 months ago
    Anonymous

    The virtual machine C presents to the hardware is different than what actually exists in modern hardware.

    I’m not smart enough to describe the difference between a PDP-11 and modern hardware, except I guess that we have more concurrency now. But I’m pretty sure the article you’re quoting goes into more details. If you want to know more, you should probably study hardware and compiler design. Pretty interesting topics that I ought to look into myself.

    • 2 months ago
      Anonymous

      Yeah the article is basically complaining about cache locality and multiprocessing. esr wrote a rebuttal to the article years ago that boils down to "serial algorithms are serial, go frick yourselves CEng weenies."

      • 2 months ago
        Anonymous

        not all problems are solved this way, some algorithms like hash table find require random access, but you can still make use of that knowledge, and average moron doesn't.

    • 2 months ago
      Anonymous

      >The virtual machine C presents to the hardware is different than what actually exists in modern hardware.
      It always was because strictly speaking C is a high level language. Lower than most other high level languages, but still an abstraction of the underlying ISA.

      The problem with your statement is the implication that the difference is "more" with "modern" hardware. It is not. In terms of ISA your CPU is either a PDP-11's brother (x86) or first cousin (ARM, MIPS, PowerPC, RISC-V).

      >I guess that we have more concurrency now.
      Superscalar dispatch is below the ISA. It's not something a programmer manages even in assembler. Compilers and assembly devs can follow certain rules and tricks to hopefully avoid stalls, but it's still below the ISA.

      >But I’m pretty sure the article you’re quoting goes into more details.
      The article is easily falsified crap, fyi.

      • 2 months ago
        Anonymous

        >It always was because strictly speaking C is a high level language.
        C left out anything the PDP-11 didn't have because it had the opposite approach that normal high level languages have. Normal high level languages do more than the hardware. C does less. The PDP-11 had flags and C did not. This is why the PDP-11 is more important to the design of C than the original architectures for most languages are to those languages.

        >The problem with your statement is the implication that the difference is "more" with "modern" hardware. It is not. In terms of ISA your CPU is either a PDP-11's brother (x86) or first cousin (ARM, MIPS, PowerPC, RISC-V).
        This is one problem with C. Modern computers (and a lot of old computers) have more instructions. The PDP-11 was too primitive and didn't have support for handing strings or arrays, so C didn't have them, even though other languages on the PDP-11 did. C is holding back hardware design by preventing you from making something designed for modern software. Do you think 747s would be as fast if they had to emulate the controls and appearance of this plane?

        https://worrydream.com/EarlyHistoryOfSmalltalk/
        >Time-sharing was held back for years because it was "inefficient"— but the manufacturers wouldn't put MMUs on the machines, universities had to do it themselves! Recursion late-binds parameters to procedures, but it took years to get even rudimentary stack mechanisms into CPUs. Most machines still have no support for dynamic allocation and garbage collection and so forth. In short, most hardware designs today are just re-optimizations of moribund architectures.

        • 2 months ago
          Anonymous

          >>It always was because strictly speaking C is a high level language.
          >C left out anything the PDP-11 didn't have
          Give a specific example of an architectural feature other systems had which was fundamentally different from what the PDP-11 had. Go ahead. Try to find something. Please.

          >Normal high level languages do more than the hardware. C does less.
          Oh for frick's sake...if you ever, even once, tried to write assembler you would realize how dumb this statement is.

          >The PDP-11 had flags and C did not
          What CPU flags do you think are exposed in higher level languages but not in C? What CPU flags can you directly access or manipulate with Java or Python? Please, I'd love to hear this.

          >This is one problem with C. Modern computers (and a lot of old computers) have more instructions. The PDP-11 was too primitive
          You have never, not once in your entire life, reviewed the opcode list for a PDP-11. And likely not for a modern CPU either. The PDP-11 was not "primitive". It was in fact CISC with a highly orthogonal instruction set. It was very much like an 8086 (minus some of the cruft) or a 68K.

          > and didn't have support for handing strings or arrays
          And now I can confirm that you've never looked at the opcode list for modern CPUs either. CPUs do not understand strings or arrays. Sometimes CISC instructions are named as if they are for those things, but "array" and "string" are not ISA types. Those instructions are just named that way because they can be useful in implementing those abstractions.

          >so C didn't have them, even though other languages on the PDP-11 did
          A string is always a language abstraction. CPUs do not have string registers, do not know ASCII or Unicode. Thank God C does not impose any particular string abstraction on developers. It's the reason why C can be fast at string processing.

          >C is holding back hardware design by preventing you from making something designed for modern software
          You have literally zero understanding of CPU design.

          • 2 months ago
            Anonymous

            >Give a specific example of an architectural feature other systems had which was fundamentally different from what the PDP-11 had. Go ahead. Try to find something. Please.
            Tags and descriptors
            https://en.wikipedia.org/wiki/Burroughs_large_systems_descriptors
            >Pointers are implemented on the B5000 by indexed descriptors. During indexing operations, pointers are checked at each increment to make sure that neither the source nor the destination blocks are out of bound. During a scan or replace operation, the mechanisms used to read or copy large blocks of memory, both source and destination are checked at each word increment for a valid memory tag. Each memory segment is bounded by tag 3 words, which would make such an operation fail. Each memory segment containing integrity sensitive data, such as program code, is stored in tag 3 words, making an uncontrolled read – let alone modification – impossible. Thus a significant source of program errors can be detected early before software goes into production, and a more significant class of attacks on system security is not possible.

            >Oh for frick's sake...if you ever, even once, tried to write assembler you would realize how dumb this statement is.
            In terms of what individual CPU instructions and C syntax does, that's true.

            >What CPU flags do you think are exposed in higher level languages but not in C?
            Overflow checking uses CPU flags. Lisp uses carry flags to implement bignums.

            >You have never, not once in your entire life, reviewed the opcode list for a PDP-11.
            All PDP-11 instructions operate on 1 or 2 bytes of data. Compared to mainframes and even the 8086 it's very primitive.
            https://www.teach.cs.toronto.edu/~ajr/258/pdp11.pdf

            >CPUs do not have string registers, do not know ASCII or Unicode.
            z/Architecture has ASCII and Unicode conversion instructions. Some CPUs have string descriptors.

            >Thank God C does not impose any particular string abstraction on developers.
            It imposes null-terminated strings.

          • 2 months ago
            Anonymous

            >lisp uses carry flags to implement bignums
            ... by being implemented in C that has wide range of support for doing things like that

          • 2 months ago
            Anonymous

            >... by being implemented in C
            No, it's implemented by assembly (Lisp Assembly Program) and Lisp.
            https://github.com/froggey/Mezzano/blob/master/system/numbers/bignum.lisp
            https://github.com/froggey/Mezzano/blob/master/system/numbers/bignum-x86-64.lisp

            >that has wide range of support for doing things like that
            Also known as "inline assembly" which is also supported by Lisp.

          • 2 months ago
            Anonymous

            yeah C also can inline assembly, big deal

          • 2 months ago
            Anonymous

            Inline assembly doesn't mean "being implemented in C."

          • 2 months ago
            Anonymous

            neither is the case in lisp, you can stop coping now

          • 2 months ago
            Anonymous

            >It imposes null-terminated strings.
            It doesn't. Individual APIs do, and the people responsible for them deserve to be exposed to 50 Sieverts, but the language itself has no issues with non-NUL-terminated strings. See https://learn.microsoft.com/en-us/windows/win32/api/subauth/ns-subauth-unicode_string

          • 2 months ago
            Anonymous

            >Burroughs
            I guess I needed to be more clear and it's my fault. I only didn't get vector ops as an answer because Cray had not shipped yet.

            What COMMON features were missing on the PDP-11, which you believe are now missing in modern CPUs "because muh C"? Burroughs architecture is not common. And not because of C, but because not many people thought it worthwhile in general purpose CPUs.

            >In terms of what individual CPU instructions and C syntax does, that's true.
            It's not even remotely true and you're just doubling down on showing everyone here you've never touched assembler.

            >>What CPU flags do you think are exposed in higher level languages but not in C?
            >Overflow checking uses CPU flags.
            And is not directly exposed, and is also not universal across ISAs. C made a choice to wrap. Whether you think it's a bad or a good choice, it is not a choice which is in any way holding processor architecture back as different ISAs do different things here.

            >All PDP-11 instructions operate on 1 or 2 bytes of data. Compared to mainframes and even the 8086 it's very primitive.
            It was a 16-bit machine. Not sure how that's primitive compared to 8086 which also worked on 1 or 2 bytes of data at a time.
            >inb4 muh string instructions!
            Worked on a byte or a word at a time. Instructions like REPE were there for convenience to iterate over bytes/words. It doesn't mean the 8086 understood strings, stored entire strings, or processed entire strings.

            >z/Architecture has ASCII and Unicode conversion instructions.
            No. It has instructions considered helpful for string processing, but it does not convert between character sets in hardware.

            God C does not impose any particular string abstraction on developers.
            >It imposes null-terminated strings.
            No it does not. It uses them for standard library functions, but does not impose them on you the way other languages impose immutable strings.

          • 1 month ago
            Anonymous

            >Tags
            We had a discussion in an old /ais/ thread about tags for CPU registers, and I tnhink Burroughs came up then. It would simplify the opcode map if the processor knew things like effective word size and if the register was signed or unsigned.

        • 1 month ago
          Anonymous

          >Most machines still have no support for dynamic allocation and garbage collection and so forth. In short, most hardware designs today are just re-optimizations of moribund architectures.
          Intel tried that route with their iAPX CPU. Tell me how well it went.

  8. 2 months ago
    Anonymous

    C is a mid-level language, and cRust is inherently further from the machine than C

  9. 2 months ago
    Anonymous

    My guess at what people mean by this is that C code is unrecognizable compared to optimized compiler output for modern processors, while it used to be roughly 1-1 with pdp-11s

    Like, x86-64 has 64 bit registers, and some instructions are applied to basically the entire register at once. If you want to do 4 calculations quickly on 16 bit integers, the best thing to do is to cram them into the same register and do the calculation once.
    There's also stuff like pipelining, specific orders of instructions are way faster than other orders (even though they're the same instructions accomplishing the same task.)
    >If C is not a low level language just with super optimized compilers that understand the intent and replace your awful slow code with faster one without telling you then what is it?
    That's a contradiction. C is a high level programming language, and no one has seriously said otherwise

    • 2 months ago
      Anonymous

      rusttroons and devshitters refuse to accept a computer is a mathmatical entity, turing machines are the way that math describes them.

      There's no runtime difference between adding all 16 bit numbers in the same register and storing the result in place and adding 2 16 bit numbers from 2 different registers and storing it in one of the two registers (or a third register).
      >pipelining
      I am glad you mentioned this, x86 instructions are indeed broken down into primitive instructions that the CPU can actually do. Ex: multiplication. The multiplication instruction MUL EAX isn't actually the primitive, it is pipelined into a bunch of addition operations. Modern CPU's are superscalars and will exdcute out of order leading to more than one operation per cycle so often times this pipeline is still well within a cycle or two despite looking like many operations.

  10. 2 months ago
    Anonymous

    Read this

    https://queue.acm.org/detail.cfm?id=3212479

    • 2 months ago
      Anonymous

      >In summary, it is possible to make C code run quickly but only by spending thousands of person-years building a sufficiently smart compiler-and even then, only if you violate some of the language rules. Compiler writers let C programmers pretend that they are writing code that is "close to the metal" but must then generate machine code that has very different behavior if they want C programmers to keep believing that they are using a fast language.

      Kek cniles will never recover.

      • 2 months ago
        Anonymous

        modern programming is writing some code then compiling it and making sure that it generates good machine code, and it it doesn't, guessing how to rewrite it so compiler generates good code for free, and this is caused by cniles.

  11. 2 months ago
    Anonymous

    They think that because C mirrors the ISA execution and not the OoO microcode execution that it's a lie to say "C is close to the machine", etc. ... while conveniently ignoring that even if you program in assembly you don't get access to that shit. I have to assume they think Itanium was good or something idk, fricking dumb ass argument. The HN frickers are the worst, as if reddit wasn't pedantic enough.

    • 2 months ago
      Anonymous

      >They think that because C mirrors the ISA execution
      It doesn't though, the compiler basically completely rewrites your program, you can see that in godbolt

      • 2 months ago
        Anonymous

        recursive factorial with -march=native really makes you think

      • 2 months ago
        Anonymous

        >compiler janny cleans up my nonsensical program design for FREE
        based, switching to C

        • 2 months ago
          Anonymous

          your code will be slower and buggier than fastest Javasir project if you write it like a moron, but even if I tell you this, it won't stop you from being moronic.

          • 2 months ago
            Anonymous

            go be autistic somewhere else

          • 2 months ago
            Anonymous

            go back to place you came from, morons don't belong on this autistic board

          • 2 months ago
            Anonymous

            the esteemed low level wizard that doesn't know how his own processor's caches work

          • 2 months ago
            Anonymous

            except I do, my intelligence is also proven by the fact that I write 98% of my code in C++ and not C, I know how computers work, I know how my compiler works, I know what to expect from the code I wrote and don't try to larp that cnility is a good thing

    • 2 months ago
      Anonymous

      >Itanium was good or something
      The ideas behind Itanium were good:
      - have the compiler do the instruction ordering at compile time, rather than the CPU do it during runtime
      - multiple status registers with which you can check multiple conditions concurrently (x86 wouldn't have that until SSE/AVX, when you could store the result of vector comparisons into another vector register)

      Out-of-order execution most often boils down to "do I have any memory loads in that chunk of instructions? If so: execute them first. What do you mean, there are dependencies and branches involved? Just tack a generic registry file to the CPU that is mostly divorced from the ISA and add branch predictors and speculative exec- oh? Oh, speculative execution is the source for shit like Spectre and Zenbleed, and rather than fixing it the patches just turn it off?"

      • 2 months ago
        Anonymous

        mitigations=off, not my problem, noone is going to steal my fizzbuzz results

      • 2 months ago
        Anonymous

        >The ideas behind Itanium were good:
        The core idea was not. It sounded good to engineers who should have known better before wasting billions, but it was not.

        >- have the compiler do the instruction ordering at compile time, rather than the CPU do it during runtime
        The compiler cannot know what's best for a chaotic runtime environment. That is one of two reasons why VLIW failed miserably.

        • 2 months ago
          Anonymous

          >The compiler cannot know what's best for a chaotic runtime environment
          And it needs to because ...?
          In my experience CPUs are terrible at avoiding smaller stalls. Not bigger ones, like interrupts would cause, but smaller ones, like having to wait for another 2 uops because a shift has to complete. A compiler which has the time and the knowledge about which instructions have which throughput, which latency, and which dependency is in an inherently better position than the CPU which might know that an interrupt occurred and thus doesn't dispatch other code in favor of that interrupt, but which doesn't have the ability to look at all the minor stalls across the entire pipeline.

          And compilers don't even do that.

          • 2 months ago
            Anonymous

            >And it needs to because ...?
            Because outside of very niche applications computers host very chaotic runtime environments.

            >In my experience CPUs are terrible at avoiding smaller stalls.
            Even with compiler level processing power and time, VLIW compilers couldn't do much better. If you actually looked through the output of an Itanium compiler you would see nops everywhere.

            >A compiler which has the time and the knowledge about which instructions have which throughput, which latency, and which dependency is in an inherently better position than the CPU
            You're making the same mistake they did. I get it. It's an attractive mistake. "Surely my compiler knows better than simple circuitry on the die." Except outside of very narrow, constrained circumstances, it does not.

            The other problem is that the VLIW binary for a specific CPU is useless on the next generation CPU. You have to recompile everything any time there's a major change like more units. VLIW didn't just fail, it failed hard. They promised it would be faster than anything, and at its debut it was getting its ass kicked by CISC.

          • 2 months ago
            Anonymous

            >Except outside of very narrow, constrained circumstances
            Obviously not. Hand-scheduled AVX code, in which I ordered every instruction based on simple calculations with regards to throughput and latency, performed three times better on my machine than whatever slop the compiler with its intrinsics churned out. That's enough evidence for me right there to assume that OoO execution is actively lobotomized for small stalls.

          • 2 months ago
            Anonymous

            >Hand-scheduled code
            where do I learn how to do this?

          • 2 months ago
            Anonymous

            You start off with a list that tells you the throughput and latency of each instruction: https://uops.info/table.html
            , and then you try to avoid input registers that you've used in previous instructions as output registers until the latency period is over and it should be save to access the register. See also: https://en.wikipedia.org/wiki/Register_renaming

          • 2 months ago
            Anonymous

            thanks

          • 2 months ago
            Anonymous

            >Obviously not. Hand-scheduled AVX code
            Is not the same thing.

          • 2 months ago
            Anonymous

            Pretty much is. Even your everyday run-of-the-mill strlen is AVX these days:
            vpxor %xmm0,%xmm0,%xmm0
            vpcmpeqb %(source),%ymm0,%ymm1
            vpmovmskb %ymm1,%eax
            tzcnt %eax,%eax

            Now try and count all the latency uops that you could've executed during the stalls. If you're below 12 I know you're lying.

          • 2 months ago
            Anonymous

            >Pretty much is.
            Oh for frick's sake...

            VLIW was packing a single word with multiple ops for a general purpose instruction set. Each op was working on its own data. One op, one piece of data. An op might take two operands (i.e. an add) but only one register gets modified.

            AVX is vector processing. One op working on multiple instances of data. SIMD. It is not the same thing. And being able to hand pack a SIMD unit proves nothing about being able to pack a VLIW for ALUs and FPUs on general purpose (not SIMD) algorithms. Yes, some "general" algorithms can be run on SIMD units or even GPUs. But not most.

            We're discussing something that is historical. It was tried. It's not a debate. Intel/HP thought they could pull it off and they couldn't. It didn't fail for lack of trying. AMD had to extend x86 to 64-bit because Intel was so committed to Itanium. It failed because the binaries were loaded with nops and the cores struggled with chaos and it all ran slow.

          • 2 months ago
            Anonymous

            >It is not the same thing
            So? This isn't about two things being the same thing or not, this is about two things having the same outcome on superscalar processors. Even with SIMDs there are stalls that out-of-order execution cannot avoid that should be trivial for a compiler to optimize for.

            >We're discussing something that is historical.
            We're not. No one argues that Itanium with its in-order architecture failed miserably. What *I* am arguing that compiler developers have no right to simply give up and leave even the simplest scheduling to the CPU in hopes that it knows what it's gonna do. I'm not arguing that in-order is king, but that out-of-order is no king either.

          • 2 months ago
            Anonymous

            >This isn't about two things being the same thing or not, this is about two things having the same outcome on superscalar processors.
            Being able to pack a SIMD unit does not in any way mean that you can pack a VLIW processor. They do not have the same outcome precisely because they are not the same thing.

            >>We're discussing something that is historical.
            >We're not. No one argues that Itanium with its in-order architecture
            It was up to the compiler to figure out dependencies and make sure each word was packed and got work done in parallel. AFAIK it was not limited to "in order" packaging in the way you're thinking. (All CPUs have to eventually present the results as if they occurred in order.) They couldn't write a compiler to do it. It failed.

            >What *I* am arguing that compiler developers have no right to simply give up and leave even the simplest scheduling to the CPU in hopes that it knows what it's gonna do.
            It knows better than the compiler for the reasons I gave. There's no magic solution here. It's tempting on paper, but it didn't work. We're not talking about some guy in a garage failing to make it happen. Intel and HP both had decades of experience with processors and compilers. They couldn't make it work with all their expertise and money.

            Take note of the fact that IBM, who probably has more experience with processors/languages/compilers than anyone in the world, did not pursue VLIW. They did offer systems based on Itanium when it shipped, but they did not pursue VLIW for their own processors. The R&D that led to RISC at IBM pointed them directly at RISC and away from anything like VLIW.

      • 1 month ago
        Anonymous

        As soon as you have data-dependent code execution, the compiler fails to be the right place to do instruction scheduling. Itanium was a bad idea, it performed worse and failed to find a niche in the market.

    • 2 months ago
      Anonymous

      >OoO
      OoOoOoO SpOoKy!!!!

  12. 2 months ago
    Anonymous

    Frick rustards.

  13. 2 months ago
    Anonymous

    My computer isn't a fast PDP-11, but it should be.

  14. 2 months ago
    Anonymous

    What is the x86 instruction to specify which branch is hot? What about to pin something in the L2 cache? How about telling the CPU that the next 14 operations are not safe to pipeline.
    Assembly is a high level language in the sense that a CPU is an extraordinary elaborate emulator that uses a computational model 10x as complex as the computational model of x86 to try and run assembly generated from C as fast as physically possible. Critically, you have almost zero control of the features of this emulator, you can just give it opcodes and almost all the important performance decisions (caching, pipelining, branch predicting, prefetching, smt, etc.) are made by the CPU without you being able to do anything about it.

    • 2 months ago
      Anonymous

      branch mechanisms are implicit, cpu will expect nearest branches to be most likely, and far jumps to be unlikely, some languages like C++ allow you to tell compiler to generate code that way for specific branches by the standard, others require compiler extensions

      • 2 months ago
        Anonymous

        That's my point, implicit equals higher level. The compiler is working against the abstraction rather than just telling the CPU what to do directly since the internals of the branch system aren't exposed to the programmer. Also modern branch predictors tend to be small neural networks since higher level languages have a tough time reordering the branches at runtime in a lot of situations.

        • 2 months ago
          Anonymous

          branch predictor cannot predict shit without the branch already having happened before, that's where this becomes important

          • 2 months ago
            Anonymous

            also icache matters and explicit hints make the code faster if unlikely code is moved away from hot loops, branch predictor isn't magic

    • 2 months ago
      Anonymous

      >Assembly is a high level language in the sense that a CPU is an extraordinary elaborate emulator that uses a computational model 10x as complex as the computational model of x86 to try and run assembly generated from C as fast as physically possible. Critically, you have almost zero control of the features of this emulator, you can just give it opcodes and almost all the important performance decisions (caching, pipelining, branch predicting, prefetching, smt, etc.) are made by the CPU without you being able to do anything about it.
      And C compilers still have to completely rewrite your code to make C run fast. C is a bad design for the internals of the CPU and the ISA visible to the programmer.

      • 2 months ago
        Anonymous

        > C compilers still have to completely rewrite your code to make C run fast
        This applies to every language.

        • 2 months ago
          Anonymous

          it applying to C too is the problem, cniles larp a lot when in the end their language isn't special, it just has a good compiler out of mere necessity

          • 2 months ago
            Anonymous

            >it applying to C too is the problem, cniles larp a lot when in the end their language isn't special
            In C a string is just an array of bytes. In most other languages it's an opaque and immutable type. In C string processing can be orders of magnitude faster. And in fact many high level languages implement their string functions using C under the hood.

            In C an array of any type is simply a contiguous block of memory. If you want something more sophisticated it's up to you to code it. Iterating over the array is simple arithmetic on a pointer, and the CPU's prefetch can easily predict what you'll need next if you're iterating forward. In many higher level languages the default array/list/etc. is actually a complicated, linked structure under the hood. It's great for resizing when programmers don't know (i.e. don't think about) what size they will end up with, but terrible for performance.

            In C you can treat a block of memory as an array of any type you like at any time you like. This makes it easy to speed up certain operations just by using a wider type. This is completely foreign to just about every other language. There are situations where C basically lets you use the ALU as if it was a vector unit, which is not an option in most other languages.

            C does not have built in complicated types. It's up to you to import or implement them. The source of the "it's a hash problem" copypasta. This at least makes you think about their costs and which is most appropriate. In higher level languages devs blindly use objects, hash maps, lists, dictionaries, etc. without once thinking about their costs because they are there and convenient. If you spent a week watching a C and Java or Python or even C++ dev try to solve the same problem, you would see the C dev making more efficient decisions over and over again.

            I could go on. None of this has anything to do with the compiler.

          • 2 months ago
            Anonymous

            >In most other languages it's an opaque and immutable type.
            And? It's arrays of bytes all the way down, you can't name one language implementation where that's not the case.
            >type punning
            this has everything to do with the compiler
            >C does not have complicated types at all
            language issue
            >There are situations where C basically lets you use the ALU as if it was a vector unit, which is not an option in most other languages.
            this is a thing in every implementation using optimizing compiler, I could probably find SBCL doing this if I tried hard enough.

          • 2 months ago
            Anonymous

            >>In most other languages it's an opaque and immutable type.
            >And?
            And I literally explained to you in detail why that's a fricking performance problem.

            >It's arrays of bytes all the way down, you can't name one language implementation where that's not the case.
            No, but I can give plenty of examples where I can implement a find or a replace that's faster in C than in any language with opaque immutable strings. You've never coded at that level so to you "it's not a problem, my language string primitives are just fine." They may be for your needs, but they also put you in situations where it takes seconds to do what can be done in milliseconds in C.

            >>type punning
            >this has everything to do with the compiler
            No, it has everything to do with the language. Go ahead and do it in Python.

            >>C does not have complicated types at all
            >language issue
            And it's an "issue" that leads to C devs producing faster code. Maybe instead of knee jerk reacting to everything I wrote with two word answers you should actually re-read my post and try to understand it.

            are situations where C basically lets you use the ALU as if it was a vector unit, which is not an option in most other languages.
            >this is a thing in every implementation using optimizing compiler
            Nope. I could give example after example where it's trivial in C and never happens in another language.

          • 2 months ago
            Anonymous

            >And I literally explained to you in detail why that's a fricking performance problem.
            How? It's an implementation detail, a better implementation could be written. Strings in fact are one of most optimized things out there, Python was never slowed down by them, it's quite literally everything else like any value type binding to any variable name being allowed

          • 2 months ago
            Anonymous

            >How? It's an implementation detail
            Because you can do things in C for performance that you cannot do in Java, Python, C#, etc.

            >Python was never slowed down by them
            Python is dog slow on string processing compared to C except for 'run of the mill' cases where the operation to be performed maps 1:1 to a Python string function which, ironically, was written in C.

          • 2 months ago
            Anonymous

            I'm asking why JVM cannot do what is done in C.
            >which, ironically, was written in C.
            especially when it is a JIT optimizing compiler that generates machine instructions the same way C compiler does

          • 2 months ago
            Anonymous

            >I'm asking why JVM cannot do what is done in C.
            Arena allocations. The garbage collector needs allocations with individual lifetimes.

          • 2 months ago
            Anonymous

            what do you think is stored in arenas if not arrays of bytes?
            Anyway, all I'm receiving is cope, anyone can create a language similar to C from scratch
            >inb4 why didn't they do it
            easier to just contribute to C than lock yourself out, but still there's plenty of meme langs and Zig is one of them that do not have problems you mention by design (they have other problems like depending on LLVM bloat instead)

          • 2 months ago
            Anonymous

            >what do you think is stored in arenas if not arrays of bytes?
            Irrelevant question. Your actual question should've been
            >why are general-purpose allocations so different from arena allocations
            And the difference is that arena allocations don't do individual lifetimes unless you explicitly program it in. No object in an arena has a tag that says if it's unoccupied or not and can be reused, which is exactly what a garbage collector needs.

            >all I'm receiving is cope
            No, you're just really mentally ill and should be put in an asylum.

          • 2 months ago
            Anonymous

            >hurr asylum
            cniles don't seem to understand that they'd have same babyduck syndrome no matter what C looked like

          • 2 months ago
            Anonymous

            >babyduck syndrome
            Fun fact: I started off with C++ and fricking hated it, and you're really mentally ill and should be put in an asylum.

          • 2 months ago
            Anonymous

            yeah I also hated it when I was 14, but then I realized that my time isn't worthless

          • 2 months ago
            Anonymous

            >"my time isn't worthless"
            >, he posted on his favorite basketweaving forum

          • 2 months ago
            Anonymous

            your seethe is invaluable, on the other hand, programming is really boring, especially in C, because instead of solving a problem I have to worry about how I will clean up memory with least amount of code after I'm done doing what I'm doing, and writing ladders of goto gets old really fast.

          • 2 months ago
            Anonymous

            Yawn.

          • 2 months ago
            Anonymous

            cool selfie, refer yourself to

            the other day, anon said that sentience means ability to say Black person and I have this AGI code right here so you're wrong:
            #include <stdio.h>
            #include <string.h>

            #define Black folk (4096 / (sizeof("Black person") - 1))

            char Black person[4096];

            int main() {
            memset(Black person, '', sizeof(Black person));

            for (size_t i = 0; i < Black folk; i++)
            memcpy(Black person + i * (sizeof("Black person") - 1), "Black person", sizeof("Black person") - 1);

            while (Black person) {
            fputs(Black person, stdout);
            }
            }

            , I wrote it especially for you, make sure to run it for at least 15 minutes a day

          • 2 months ago
            Anonymous

            >no u

          • 2 months ago
            Anonymous

            I wrote C code without causing a buffer overrun therefore I cannot be a Black person and the accuser is proven to be a Black person automatically.

          • 2 months ago
            Anonymous
          • 2 months ago
            Anonymous

            Yawn.

            cool selfie, refer yourself to [...], I wrote it especially for you, make sure to run it for at least 15 minutes a day

            can you Black folk stop with those infantile insults and go back to quality arguments and esoteric trivia like

            >Except outside of very narrow, constrained circumstances
            Obviously not. Hand-scheduled AVX code, in which I ordered every instruction based on simple calculations with regards to throughput and latency, performed three times better on my machine than whatever slop the compiler with its intrinsics churned out. That's enough evidence for me right there to assume that OoO execution is actively lobotomized for small stalls.

            Pretty much is. Even your everyday run-of-the-mill strlen is AVX these days:
            vpxor %xmm0,%xmm0,%xmm0
            vpcmpeqb %(source),%ymm0,%ymm1
            vpmovmskb %ymm1,%eax
            tzcnt %eax,%eax

            Now try and count all the latency uops that you could've executed during the stalls. If you're below 12 I know you're lying.

            ?
            I'm quite enjoying this thread as a lurker

          • 2 months ago
            Anonymous

            I don't really have anything to add to

            >This isn't about two things being the same thing or not, this is about two things having the same outcome on superscalar processors.
            Being able to pack a SIMD unit does not in any way mean that you can pack a VLIW processor. They do not have the same outcome precisely because they are not the same thing.

            >>We're discussing something that is historical.
            >We're not. No one argues that Itanium with its in-order architecture
            It was up to the compiler to figure out dependencies and make sure each word was packed and got work done in parallel. AFAIK it was not limited to "in order" packaging in the way you're thinking. (All CPUs have to eventually present the results as if they occurred in order.) They couldn't write a compiler to do it. It failed.

            >What *I* am arguing that compiler developers have no right to simply give up and leave even the simplest scheduling to the CPU in hopes that it knows what it's gonna do.
            It knows better than the compiler for the reasons I gave. There's no magic solution here. It's tempting on paper, but it didn't work. We're not talking about some guy in a garage failing to make it happen. Intel and HP both had decades of experience with processors and compilers. They couldn't make it work with all their expertise and money.

            Take note of the fact that IBM, who probably has more experience with processors/languages/compilers than anyone in the world, did not pursue VLIW. They did offer systems based on Itanium when it shipped, but they did not pursue VLIW for their own processors. The R&D that led to RISC at IBM pointed them directly at RISC and away from anything like VLIW.

            . I can believe that multi-billion dollar companies like Intel and HP failed to make compilers with proper scheduling for an aggressively in-order architecture. I refuse to believe that they failed to make a compiler that counts upos and inserts independent instructions into the stream like the code monkey that I am, armed with nothing more than an inline assembler and a database showing me the numbers. If I can tickle an additional 200% runtime (literally, by the way: it went from 90 seconds to 30 seconds) out of some code by rescheduling some registers, then surely Intel can do so, too.

          • 2 months ago
            Anonymous

            You're looking at a specific personal experience with a specific algorithm and thinking that it scales to all cases. But it doesn't. Another key reason can be found right here:
            >If I can tickle an additional 200% runtime
            >then surely Intel can do so, too.
            You're a human being. If Intel engineers were looking at any given piece of code, maybe they could hand pack all the VLIW words finding the parallelism they needed to run faster than competing processors. But they couldn't build a dumb compiler which could do it well enough to pull Itanium ahead of the competition, even apart from the chaotic factor. Perhaps that's part of the reason why it was so tempting to try. In a completely different domain I've had an experience like that.
            >i can do this by hand, surely it's not that difficult to code
            >OH SHIT

            Crazy as it seems, in general a dumb microprocessor can better exploit instruction level parallelism with its tiny but highly focused view of what's happening this clock cycle than a compiler with time to analyze the problem and try to find more. Especially now that simultaneous multithreading is a reality. Today's CPUs can see/schedule instructions that VLIW compilers never could.

            I don't think either of us could fully appreciate why it failed without a VLIW simulator and an attempt to do it by hand followed by an attempt to write a compiler to do it. Both of us would probably hit a point and go "oh shit, now I get it."

            In any case, VLIW didn't fail due to C or any other particular language.

          • 2 months ago
            Anonymous

            >I'm asking why JVM cannot do what is done in C.
            Because we have not achieved AGI and the JVM cannot understand the problem much less write a more efficient solution.

          • 2 months ago
            Anonymous

            the other day, anon said that sentience means ability to say Black person and I have this AGI code right here so you're wrong:
            #include <stdio.h>
            #include <string.h>

            #define Black folk (4096 / (sizeof("Black person") - 1))

            char Black person[4096];

            int main() {
            memset(Black person, '', sizeof(Black person));

            for (size_t i = 0; i < Black folk; i++)
            memcpy(Black person + i * (sizeof("Black person") - 1), "Black person", sizeof("Black person") - 1);

            while (Black person) {
            fputs(Black person, stdout);
            }
            }

          • 2 months ago
            Anonymous

            This is the best argument I've seen so far, and I will need some time to consider it anon.

          • 2 months ago
            Anonymous

            >No, but I can give plenty of examples where I can implement a find or a replace that's faster in C than in any language with opaque immutable strings.
            I hope it would be vectorized code and not baby's first foor loop.
            >No, it has everything to do with the language. Go ahead and do it in Python.
            I can make Python segfault even, you seem to underestimate what they can do.
            >And it's an "issue" that leads to C devs producing faster code.
            if only that were true in practise, the other day I wanted to write a program that outputs into stdout as fast as possible but I couldn't be bothered to use Linux write(2) and coped with fputs which does not provide means to tell it how long the string is, so it has a pointless minimal overhead and C is full of memes like that unless I reimplement stdlib at home
            >Nope. I could give example after example where it's trivial in C and never happens in another language.
            oh yeah go ahead, make sure it doesn't happen in C++

      • 2 months ago
        Anonymous

        >And C compilers still have to completely rewrite your code
        Compilers are much more limited than you'd like to think. For specific sets of calculations (division by 10 comes to mind) they can do absolute wonders. In other instances (inlining after unrolling) they are stupidly moronic. Sometimes they don't use volatile registers unless you direct them to (which is why the "register" keyword still exists, and yet, I've seen it happening with my own eyes, where instead of using a free register the compiler would just generate a block of jumps that controlled what value to actually write into a stack variable because store eliminations are preferable over branch eliminations).

        They also suck at generating SIMD code. Count all the vzerouppers GCC generates in your SIMD code to make sure that non-VEX-prefixed functions don't slow down your entire operation, and then realize that throughput (not even latency) of the command varies so wildly across platforms that an entire fricking L1 store would be preferable to one vzeroupper.

        • 2 months ago
          Anonymous

          I missed this earlier, it's an underrated post.

      • 2 months ago
        Anonymous

        >And C compilers still have to completely rewrite your code to make C run fast.
        moronic statement since every language compiler that's worth a shit applies the same optimizations. C tends to be faster than other languages for any given level of compiler optimization. And for that the be true the reasons would have to be independent of compiler optimizations.

        >C is a bad design for the internals of the CPU and the ISA visible to the programmer.
        I would ask you for specific examples but of course you have none, you're just parroting a catch phrase you read on a web blog. It's actually a very good design, better than pretty much any other popular language.

        • 2 months ago
          Anonymous

          >I would ask you for specific examples
          cniles transheart linked lists and guess how much CPU likes that

          • 2 months ago
            Anonymous

            >cniles transheart linked lists
            No?

            >how much CPU likes that
            The CPU doesn't mind; it just stalls.

          • 2 months ago
            Anonymous

            >no
            every problem is solvable without linked list and yet even Linux has them
            >The CPU doesn't mind; it just stalls.
            my body would also stall if I was jogging while holding my breath to take in fresh air only once a minute

          • 2 months ago
            Anonymous

            Stalls don't affect the voltage supply beyond critical levels though. The CPU is fine with stalling.
            Holding your breath very much affects your oxygen supply beyond critical levels.

          • 2 months ago
            Anonymous

            C likes arrays of contiguous bytes. If you're working in C you should at least try to solve the problem that way since it yields huge performance gains.

            Many other languages don't even present that as an option. An "array" is a linked list under the hood. You don't even have the choice.

          • 2 months ago
            Anonymous

            Even javascript exposes arbitrary arrays that you can do whatever you want to with

          • 2 months ago
            Anonymous

            >Even javascript exposes arbitrary arrays that you can do whatever you want to with
            Which are never used. And if they were, they still would be slower because under the hood array access is implemented as functions for "muh safety" among other things.

            I get it for JavaScript. I totally get the decision. But C is what you use when you don't want to be restrained by such decisions.

    • 2 months ago
      Anonymous

      >Assembly is a high level language in the sense that a CPU is an extraordinary elaborate emulator
      As early as IBM's System/360...even earlier if I felt like checking the history...a processor's ISA was an abstraction of the actual machine. It's a very low level abstraction which gives a great deal of control over the state in the processor. But it is an abstraction. This is not new and it has nothing to do with C.

      >that uses a computational model 10x as complex as the computational model of x86 to try and run assembly generated from C as fast as physically possible
      To execute INSTRUCTIONS as fast as physically possible, regardless of source. It is utter moronation to believe that CPUs are designed they way they are because of C. For frick's sake, C wasn't even that popular when the 8086 or 68K were invented, or when IBM was doing research on RISC. IBM's conclusions that led to RISC were based on statistics gathered from years of their clients executing programs generated from dozens of languages that WERE NOT C. Engineers at Intel, IBM, ARM Holdings, Apple, etc. do not sit around asking "how can we run C code as fast as possible?" They profile code from all sources, including hand assembler, and make decisions about CPU design.

      >and almost all the important performance decisions (caching, pipelining, branch predicting, prefetching, smt, etc.) are made by the CPU without you being able to do anything about it.
      As it should be. Intel and HP spent billions of dollars thinking that a human or compiler could better exploit instruction level parallelism than the microprocessor itself and failed miserably. Why? It wasn't intuitively obvious to them that instruction dispatch planning at the human or compiler level falls apart the moment there's an interrupt. CPUs are better able to see and exploit instruction level parallelism in the chaotic, dynamic environment that is a modern system. Same thing for cache outside of very special, narrow circumstances.

  15. 2 months ago
    Anonymous

    Anon, you’re putting way too much thought into it
    Like everything else involving Rust, it’s a catchy slogan that falls apart under closer inspection but once you do that closer inspection you’ll be accused of bikeshedding
    It’s unironically a cult built around a fricking computer language of all things
    >t. security professional that’s seeing Rust CVEs piling in, only to have the trannies try to redefine them away since Rust is ipso facto "safe"

    • 2 months ago
      Anonymous

      >CVE's piling in
      the side effect of this is that CVE's in LLVM are being fixed and that C++ compiler gets better everyday, thank you trannies for experimenting with edge cases lmao!

  16. 2 months ago
    Anonymous

    >this shit again
    The 'not a fast pdp-11' article is ignorant bullshit, as is 'muh unix haters handbook.' Some people cling to those piles of crap as if they are the gospel truth because they're ignorant about computer architecture and history, and they have a hate boner for C and UNIX. Why? Who the frick knows.

    In the case of C: it makes absolutely zero sense to blame C for the lack of market penetration of Rust or Lisp. If you love one or both of those languages then promote their use by writing useful shit in them. Attacking C with easily debunked arguments only makes you look like an idiot, making people less likely to consider anything you promote. And as for C as a language: it's a great fricking language if you know how and when to use it. It's the language people turn to to build other languages for frick's sake.
    >nooooo muh rust is bootstrapped!
    Don't care. C has been used to create more kernels, OSes, drivers, and languages than any other. Even if your language is now completely independent, odds are it started with an implementation written in C or C++. There's a reason C/C++, especially C, are always chosen for low level shit. Don't like it? Stick to userland.

    And in the case of UNIX? I can only guess that some people get pissed off because "UNIX/Linux hard." Well if you don't like the command line or don't like configuring them then get a fricking Mac. It's that fricking simple.
    >but muh lispy machine!
    >muh garden of eden shared address space!
    >muh special cpus so lispy doesn't run dog slow!
    >WHY DID YOU TAKE THIS FROM ME???
    Because while you were jerking off on your Lispy CPU other people were busy writing useful shit.

    • 2 months ago
      Anonymous

      >There's a reason C/C++, especially C, are always chosen for low level shit.
      I have to give cniles credit where it's due, they know how to write their own compiler, golang for example uses custom compiler, it's not the best but it's years ahead of best LISP machine LOL

  17. 2 months ago
    Anonymous

    >Turing machine is still their core abstraction
    what? no, this has never been the case.
    TMs have only ever been theoretical constructs for theoretical compsci, no one uses them as an underpinning for hardware design
    is this just bad bait?

  18. 2 months ago
    Anonymous

    >If computers are not fast PDP-11s then what are they?
    PDP-11 was not unique. All of its architectural features were shared with other mainframes and minis of the time period. This shit was worked out in the 40s, 50s, and 60s, before the PDP-11 and before C.

    The only real architectural difference between the PDP-11 and many modern CPUs is RISC. RISC has nothing to do with C. RISC was born out of research at IBM, Stanford, and Berkley. And even RISC CPUs are very similar to computers contemporary with the PDP-11. The same architectural features are there, there are just additional rules placed on the opcodes to make pipelining and superscalar dispatch easier/more successful. If you went back in time and showed a PDP-11 developer assembler for an ARM or MIPS they would be able to program it, they would just be confused as to why they had to specify some steps as 2-3 ops instead of 1.

    "Your computer is not a fast PDP-11" is just as ignorant as "your 747 is not a Cessna." All the fundamentals of flight, aircraft engineering, and aircraft control are present in both because that's how you fly. One's bigger and has jets and carries more people. But it still has wings, the same control surfaces, etc. homosexuals act as if we could have flying saucers/radically different CPUs if it wasn't for the FAA/C. They are utterly moronic.

    • 2 months ago
      Anonymous

      >747 is a cessna
      and I take you consider yourself a woman?

      • 2 months ago
        Anonymous

        >everything that flies is LITERALLY the same thing
        >problems with the Boeing 737 MAX are actually fundamentals of flight
        >my 737 MAX IS a fast hot air balloon

        Ironically you're the ones who sound mentally ill.

        • 2 months ago
          Anonymous

          There's very few differences between women and women, the base of them is the same, in fact they develop from same thing and it only branches out due to few hormonal differences and one different chromosome pair, women and women are in fact less different than 747 and a cessna, and you are trying to tell us that they are basically same thing.

          • 2 months ago
            Anonymous

            >I haven't written "men" once where I was supposed to due to my heterosexuality making me obsessed with women
            I need to coom before I post anything else.

      • 2 months ago
        Anonymous

        There's very few differences between women and women, the base of them is the same, in fact they develop from same thing and it only branches out due to few hormonal differences and one different chromosome pair, women and women are in fact less different than 747 and a cessna, and you are trying to tell us that they are basically same thing.

        Guess I have to spell it out for the troons...

        They both have wings, ailerons, rudders, elevators, trim tabs, and thrust producing engines. And they both balance thrust, drag, lift, and gravity in order to fly. At a level equivalent to that of a processor ISA, a 747 and Cessna are architecturally the same. The implementations under the hood are different, but still working to accomplish the same thing.

    • 2 months ago
      Anonymous

      >everything that flies is LITERALLY the same thing
      >problems with the Boeing 737 MAX are actually fundamentals of flight
      >my 737 MAX IS a fast hot air balloon

  19. 2 months ago
    Anonymous

    Threadly reminder that Redox-OS, programmed in Rust, is not going anywhere. After 8 years it is still not self hosting and nowhere like what Linux was after just 4 years.

    • 2 months ago
      Anonymous

      the OS whose one of most important programmers killed himself after porting it to ARM was mentioned

      • 2 months ago
        Anonymous

        True, I forgot to mention that.
        They also had a purge and kicked out another major contributor. That didn't help progress much either. Not surprisingly, the news updates are few and far between.
        In contrast, SerenityOS is charging ahead, is super comfy, has very frequent updates, also on YouTube. In fact some development is done on YouTube, such as when they implemented a graphical file picker in a single session. In TOTALLY unrelated news, Gnome did that shortly theereafter and then closed one of the most putrid long standing bugs.

        • 2 months ago
          Anonymous

          does serenity's filepicker have thumbnails?

          • 2 months ago
            Anonymous

            Seems like it: https://youtu.be/khyD_8r3zRI?feature=shared

    • 2 months ago
      Anonymous

      >Redox-OS
      No disrespect to the author but it was always a meme OS. An OS, or any program for the matter, should be about what it offers, things like features, fixes, new improvements, abstractions, core ideas and so on. Not about trivial things like the language it's written on. I have zero interest in redox because it's not clear what it offers over other OS. I'd rather use temple os or serenity which both have unifying ideas begind them and strong leaders.

      • 2 months ago
        Anonymous

        HaikuOS doesn't mention what language it is programmed in outside its git repo I think

      • 2 months ago
        Anonymous

        >it's not clear what it offers over other OS
        One thing that caugyht my interest, is that they went from "everything is a file" to "everything is a URL". I thought that could be interesting. Now they have essentially retreated from that design, so this is not so interesting to me.

      • 2 months ago
        Anonymous

        True, I forgot to mention that.
        They also had a purge and kicked out another major contributor. That didn't help progress much either. Not surprisingly, the news updates are few and far between.
        In contrast, SerenityOS is charging ahead, is super comfy, has very frequent updates, also on YouTube. In fact some development is done on YouTube, such as when they implemented a graphical file picker in a single session. In TOTALLY unrelated news, Gnome did that shortly theereafter and then closed one of the most putrid long standing bugs.

        The discussion around Redox/Serenity are absolutely moral destroying because people think they're different/novel or particularly impressive; your average programmer thinks writing a OS in 2024 is some kind of black magic when there's literally thousands of hobby and hundreds of commercial OS's in development.

        • 2 months ago
          Anonymous

          >muh fork of Linux/BSD is better and more impressive
          I spit in your face.

          • 2 months ago
            Anonymous

            >My Basic b***h UNIX deviate is impressive
            >B-But it's written from scratch!
            Literally 1st year CS students write a significant percentage of a V7 implementation.

          • 2 months ago
            Anonymous

            yes I'm sure they write 46 million line projects in one course all by themselves and then there's professors who verify and grade that, very believable.

            Stalls don't affect the voltage supply beyond critical levels though. The CPU is fine with stalling.
            Holding your breath very much affects your oxygen supply beyond critical levels.

            the cpu is fine with stalling but literally takes x10000 longer to do trivial things

          • 2 months ago
            Anonymous

            >46 million line
            >V7
            >stalling
            >x10000 longer
            Jesus Anon, you should really stop pretending like you know shit.

          • 2 months ago
            Anonymous

            >muh toy kernel that does nothing is le... V7 and basically like Linux
            yes I'm the moron here

            >the cpu is fine with stalling but literally takes x10000 longer to do trivial things
            And it's fine with that. The user may have a conniption, but no one cares.

            I care and I hate cniles who do this

          • 2 months ago
            Anonymous

            >I care and I hate cniles who do this
            Boo hoo. Good thing you're powerless to stop them.

          • 2 months ago
            Anonymous

            I can write C too, actually.

          • 2 months ago
            Anonymous

            So? Doesn't stop us.

          • 2 months ago
            Anonymous

            >I care and I hate cniles who do this
            If you did you wouldn't be praising Unix/Linux which by their fundamental design cause your CPU to stall every 3-4 instructions.

          • 2 months ago
            Anonymous

            hallucinated it again award

            So? Doesn't stop us.

            patching cnile software and not submitting the patches to upstream repo is something I've done many times and will continue doing

          • 2 months ago
            Anonymous

            Sure, if you want to waste your life doing that. Battle against windmills and all that.

          • 2 months ago
            Anonymous

            It's not a waste if it stops performing poorly (despite being C code)

          • 2 months ago
            Anonymous

            >the cpu is fine with stalling but literally takes x10000 longer to do trivial things
            And it's fine with that. The user may have a conniption, but no one cares.

        • 2 months ago
          Anonymous

          >The discussion around Redox/Serenity are absolutely moral destroying because people think they're different/novel or particularly impressive;
          Redox started with a novel idea before they ran off into the weeds. SerenityOS is willing to break API/ABI and has the opportunity to learn from the mistakes made in Linux. That alone makes it interesting. What impresses me with SerenityOS is the speed this is evolving at, and that they are able to maintain a comfy style. I fyou want impressive, I'd say TempleOS qualifies.
          >your average programmer thinks writing a OS in 2024 is some kind of black magic when there's literally thousands of hobby and hundreds of commercial OS's in development.
          I know there are many:
          https://wiki.installgentoo.com/wiki//aosg/_Alternative_Operating_System_General
          We live in stagnant times, I celebrate everyone making an effort to break with this trend.

          • 2 months ago
            Anonymous

            Another 'thing' people who aren't deep into this subject won't understand is you can't really be different or original kernel wise, there's only really a handful of ways to do stuff especially when your talking to hardware, all of which has been done previously. In the end you always end up just recreating Multics/Unix/NT/DOS no matter how hard you try.

          • 2 months ago
            Anonymous

            >there's only really a handful of ways to do stuff especially when your talking to hardware
            Bollocks. I/O parallelism is still a complete mess because none of the contemporary kernels foresaw any need for it. Try and open 64K file handles at once with either Windows or Linux and without copious amounts of syscalls.
            >inb4 io_uring
            Has still plenty of issues, and who knows if they're ever going to get fixed.

            And I didn't just pull the 64K number out of my arse; that just how many commands modern NVMe support in just one of their 64K command queues: https://en.wikipedia.org/wiki/Native_Command_Queuing

          • 2 months ago
            Anonymous

            io_uring is a high-level abstraction, it doesn't even touch the hardware let alone talk to it. I'm talking on the level of PIC and APIC controllers.

          • 2 months ago
            Anonymous

            >I/O parallelism is still a complete mess because none of the contemporary kernels foresaw any need for it.
            Mainframes handled it in the 60s.

          • 2 months ago
            Anonymous

            And I assume you had direct control over the I/O controller in the 60s? Because all I really need to look at are the interfaces both kernels expose:
            https://man7.org/linux/man-pages/man2/open.2.html
            https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/nf-ntifs-ntcreatefile
            No ability to deal with hundreds or thousands of files during one execution, it's all limited to one instance as if syscalls don't exist.

          • 2 months ago
            Anonymous

            Linux and Windows NT aren't mainframe operating systems.

          • 2 months ago
            Anonymous

            Then why even bring it up?

          • 2 months ago
            Anonymous

            Because you said "none of the contemporary kernels foresaw any need for it" and mainframes did have a need for it. They could have just copied what mainframes already did.

          • 2 months ago
            Anonymous

            >They could have just copied what mainframes already did.
            Well, I asked you what mainframes did in the 60s:
            >And I assume you had direct control over the I/O controller in the 60s?

            Why would anyone need more? All of this is relatively "slow" and complicated in any case.

            >Why would anyone need more?
            Because your process may have encountered an edge case that required copious amounts of memory (16 GiB for instance) when it usually required 512 MiB. I'd like that memory back, if you don't terribly mind.

          • 2 months ago
            Anonymous

            >Because your process may have encountered an edge case that required copious amounts of memory
            I never saw this happen before, what would be an example of this? Normally memory usage scales the same for a particular problem.

          • 2 months ago
            Anonymous

            Database engines that cache their results before writing it out to the client.

          • 2 months ago
            Anonymous

            their caches don't store gigabytes of data in RAM, surely?
            Also WAL writes to disk as far as I know

          • 2 months ago
            Anonymous

            >their caches don't store gigabytes of data in RAM, surely?
            Depends on the columns selected and the rows returned. Some designs I've seen just set up a shared mapping between client and server and store the data there, and naturally the mapping can grow and shrink there.

          • 2 months ago
            Anonymous

            column sizes are mostly fixed, and that grows linearly with amount of rows, so seems like a bad design problem if this causes high RAM usage only in some cases

          • 2 months ago
            Anonymous

            >column sizes are mostly fixed
            I didn't talk about column sizes, but about columns selected.

            SELECT foo, bar, boo FROM muh_table JOIN muh_table_2 on foo = feh JOIN ...

            The engine can't know that until the request comes in.

          • 2 months ago
            Anonymous

            well yes, but it's standard to have a sane limit on rows that you want to be returned per query, instead of letting engine just fetch petabytes of data all at once

          • 2 months ago
            Anonymous

            Sure. That's the reserve range then. But we've been talking about commit charge thus far.

          • 2 months ago
            Anonymous

            just write to disk faster?

          • 2 months ago
            Anonymous

            Databases don't just write; they also read. And I've been talking about the reading part thus far.

          • 2 months ago
            Anonymous

            yes not reading entire database into memory is also a good idea

          • 2 months ago
            Anonymous

            >Yeah, we don't do that.
            Why?
            >Because it's just not a good idea.
            ... we're changing vendors.

          • 2 months ago
            Anonymous

            how do you fit petabytes of disk data into like few terabytes of memory at most?

          • 2 months ago
            Anonymous

            >there's only really a handful of ways to do stuff especially when your talking to hardware
            Bollocks. I/O parallelism is still a complete mess because none of the contemporary kernels foresaw any need for it. Try and open 64K file handles at once with either Windows or Linux and without copious amounts of syscalls.
            >inb4 io_uring
            Has still plenty of issues, and who knows if they're ever going to get fixed.

            And I didn't just pull the 64K number out of my arse; that just how many commands modern NVMe support in just one of their 64K command queues: https://en.wikipedia.org/wiki/Native_Command_Queuing

            If you want to see this in action check out Oberon, Lisp Machines and Amiga, they present the end-user (programmer) completely different API/ABI's but on a fundamental level they work almost identically.

          • 2 months ago
            Anonymous

            >you can't really be different or original kernel wise
            That is the kind of thinking that keeps us in stagnation. In any case you have exploratory OS such as Synthesis. Not every part has to be revolutionised to improve the state of the art.

            The alternative is for the Linux kernel people to declare a flag day: rip out all the misbegotten features and break as much API/ABI as you need. The old style can be maintained for 5 years but most will go for the new branch. Unfortunately they have made a promise that this will never happen.

          • 2 months ago
            Anonymous

            kernel's job is to interface with hardware, nothing more, noone needs 50 different firmwares when even ones provided by companies are buggy garbage

          • 2 months ago
            Anonymous

            *laughs in nVidia*

          • 2 months ago
            Anonymous

            yeah goodluck innovating when novideo will not give a frick about your kernel

          • 2 months ago
            Anonymous

            Nobody is going to dump their existing code base because you think a revolutionary OS that upends everything about the last century of EE is just around the corner. What do you want or hope to gain that's not already there?

          • 2 months ago
            Anonymous

            >Nobody is going to dump their existing code base
            I never throught so either.
            >What do you want or hope to gain that's not already there?
            Less bloat, fewer security issues, better uptimes.

          • 2 months ago
            Anonymous

            >Less bloat, fewer security issues, better uptimes.
            And...what architectural features do you think that requires that do not exist because of C?

          • 1 month ago
            Anonymous

            Perhaps you confuse me with someone else, but I never throught C was at fault here. I hear Rust is heralded as the next big thing, yet Redox-OS has faltered. SerenityOS is written in C++ but I never claimed that had any impact on this question.

          • 1 month ago
            Anonymous

            >Perhaps you confuse me with someone else, but I never throught C was at fault here.
            Apologies anon, I did confuse you with someone else.

            Tagged memory and descriptors.
            http://lispm.de/genera-concepts

            >Tagged memory and descriptors.
            >http://lispm.de/genera-concepts
            These were not a general feature of processors. It's not like everyone had these except the PDP-11, most systems did not. And if the EE community felt they were important now, they would not hold back on implementing them due to C. There might be a problem implementing them due to the entire existing code base being written as if they do not exist, because they don't currently. But that includes EVERY language, not just C. EVERY language would require changes, which would mean changes to code. Only the highest level languages could make this mostly invisible to programmers.

            Are you sure that would really increase security? Really?
            I suspect that the real source of your security right now is that nobody wants to write Lisp.

            This anon gets it.

          • 1 month ago
            Anonymous

            Tagged memory and descriptors.
            http://lispm.de/genera-concepts

          • 1 month ago
            Anonymous

            Are you sure that would really increase security? Really?
            I suspect that the real source of your security right now is that nobody wants to write Lisp.

          • 2 months ago
            Anonymous

            This anon gets it.

            >there's only really a handful of ways to do stuff especially when your talking to hardware
            Bollocks. I/O parallelism is still a complete mess because none of the contemporary kernels foresaw any need for it. Try and open 64K file handles at once with either Windows or Linux and without copious amounts of syscalls.
            >inb4 io_uring
            Has still plenty of issues, and who knows if they're ever going to get fixed.

            And I didn't just pull the 64K number out of my arse; that just how many commands modern NVMe support in just one of their 64K command queues: https://en.wikipedia.org/wiki/Native_Command_Queuing

            >Bollocks. I/O parallelism is still a complete mess because none of the contemporary kernels foresaw any need for it.
            It's a complete mess because you eventually hit a bottleneck: at the lowest level main memory can only deal with one master at a time. Same for any given bus and most device chip sets. Note that this has nothing to do with C or PDP-11s.

            And I assume you had direct control over the I/O controller in the 60s? Because all I really need to look at are the interfaces both kernels expose:
            https://man7.org/linux/man-pages/man2/open.2.html
            https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/nf-ntifs-ntcreatefile
            No ability to deal with hundreds or thousands of files during one execution, it's all limited to one instance as if syscalls don't exist.

            >No ability to deal with hundreds or thousands of files during one execution, it's all limited to one instance as if syscalls don't exist.
            Define "one execution." You can't have a hundred simultaneous reads from RAM. You can't have 100 different chips trying to transmit file bytes to a SSD at once. NCQ does not mean that a SSD can read/write 64k files simultaneously. NCQ allows a device...HDD or SSD...to re-order commands for performance because commands are coming in faster than they can be satisfied. With a HDD that means it looks through its queue and grabs everything it can at the current head position to avoid seeks back and forth, as but one example. It doesn't mean files are being read, written, or processed in parallel.

            What do you expect to be able to do with your userland process?

          • 2 months ago
            Anonymous

            >You can't have a hundred simultaneous reads from RAM.

            Technically, that is something you can have, with a given cache line in lots of cpu's L1. It only becomes a problem when you try to write.

          • 2 months ago
            Anonymous

            That made me smile anon.

          • 2 months ago
            Anonymous

            Thanks! But it is a real optimization/approach - and one absolutely blessed by hardware designers.

          • 2 months ago
            Anonymous

            I didn't mean to imply that it wasn't, I smiled because
            >oh shit he's right

  20. 2 months ago
    Anonymous

    You constructed a strange strawman. I've never heard anyone claim Rust is lower level than C. How is Rust more appropriate for non Von-Neumann architecture?

  21. 2 months ago
    Anonymous

    Current x86 computers are very fast IBM 5150s, IBM 5150 was slow PDP-11, therefore current PCs are fast PDP-11s.

  22. 2 months ago
    zibzub

    >>C Is Not a Low-level Language: Your computer is not a fast PDP-11.
    >What do rustaceans mean by this?

    I don't have intimate knowledge with that affirmation but common problems raised by rustaceans and modern C++ developers is that using C limits you to using an extremely limited set of low level instructions. Basically stuff from way back when C was first released, in fact some say that modern CPU even emulate old instructions generated by C compilers for backwards compatibility.

    I the only nicety that C++ and Rust have natively is has that I know of is safe constructs for pointer sharing, that can be super handy for multi-threaded code, which would cause you to use a lot more of your CPU potential.

    • 2 months ago
      Anonymous

      >I don't have intimate knowledge with that affirmation but common problems raised by rustaceans and modern C++ developers is that using C limits you to using an extremely limited set of low level instructions.
      Which is absolutely dead wrong. Anyone offering that argument is clueless about both CPU architecture and C. They took the "C is a lower level language" meme literally. It is "lower" than most other languages, but still very much a high level language. It's not imposing anything on any hardware.

      And beyond that, we know that simpler instruction sets (RISC) can yield greater speed, all other factors being equal. (Die space, cache size, clock speed.) The world very much moved to RISC with the only holdouts doing so for backwards compatibility with all code, not C code. (Those would be x86 and some shit for IBM mainframes, along with some CISC embedded cores.)

      >in fact some say that modern CPU even emulate old instructions generated by C compilers for backwards compatibility.
      Anyone saying that is ignorant. No CPU is doing that.

      >I the only nicety that C++ and Rust have natively is has that I know of is safe constructs for pointer sharing, that can be super handy for multi-threaded code
      Rust and C++ are not easier to thread than C. Threading is difficult for anything outside the class of embarrassingly parallel problems (i.e. graphics; http server). How difficult or easy threading is depends very much on the APIs available to you on whatever platform you're developing for. Not the language.

  23. 2 months ago
    Anonymous

    >morons arguing with another moron that doesn't know the difference between a flush and stall
    Battle of the low IQ's.

  24. 2 months ago
    Anonymous

    mfw I have to cause buffer overruns to be accepted by cniles

  25. 2 months ago
    Anonymous

    >>C Is Not a Low-level Language: Your computer is not a fast PDP-11.
    You know how a bunch of media-illiterate females watched Barbie and thought it was about how males are bad because they don't know that Greta Gerwig hates females? This blog post is kinda like that. If you read his other shit it's way more obvious what he means by it, but none of the rustoids know that.

  26. 2 months ago
    Anonymous

    modern computers aren't anything like a pdp-11 if you consider the now ubiquitous gpu as a first level compute engine (which it is). The hillarious bit about this is the idea behind gpu compute is SPMD - single program multiple data - running the same program on every 'pixel' or really structure across some large data set. And even in this new world, 'c' syntax works great. 1st with the intel ispc compiler , and now with dpc++.

    imho 'c' is looking a bit long in the tooth, but modern c++ is a fricking stallion, good for the foreseeable future, and in truth being tweaked based on some rust ideas.

    • 2 months ago
      Anonymous

      Also, and this is above my abilities, I have to wonder if some c++ ideas maybe could be back-ported into c, maybe in 10 or 15 years. It might be nice to get templates in 'c', or maybe 'c' should remain as it is, I dunno.

  27. 2 months ago
    Anonymous

    I also want to push back against the idea that a 'c' style array of structures is somehow inappropriate for modern (very much not PDP-11) architectures. Laying out your structures linearly or in an array in memory (c style) makes a great deal of sense when you deal with massive parallelism. Why force whatever compute engines you have to deal with unnecessary pointer chasing? You, the programmer may not even have a clear idea of the compute engines your runtime may be targeting, ex. opencl or vulkan compiling compute shaders at runtime.

    C may not have been designed for the hardware of this era, but its ideas sure seem to work.

    • 2 months ago
      Anonymous

      >I also want to push back against the idea that a 'c' style array of structures is somehow inappropriate for modern (very much not PDP-11) architectures.
      >C may not have been designed for the hardware of this era, but its ideas sure seem to work.
      C didn't invent any of that. They just ripped off what other languages did. Arrays of structures are not "C's ideas."

    • 2 months ago
      Anonymous

      https://en.wikipedia.org/wiki/Cache_prefetching

      • 2 months ago
        Anonymous

        >https://en.wikipedia.org/wiki/Cache_prefetching

        Yes! let the hardware work for you.

    • 2 months ago
      Anonymous

      your RAM isn't actually an array, it only works because of virtual memory hiding it

      • 2 months ago
        Anonymous

        and of course, this causes unnecessary pointer chasing built into hardware itself

        • 2 months ago
          Anonymous

          >this causes unnecessary pointer chasing built into hardware itself
          Can be mitigated by using bigger pages: https://en.wikipedia.org/wiki/Translation_lookaside_buffer

          • 2 months ago
            Anonymous

            bigger pages cause unnecessary RAM waste, allocation is done per page and if you have even one byte allocated in it, entire physical memory that the page points to is now held hostage by the process

          • 2 months ago
            Anonymous

            >bigger pages cause unnecessary RAM waste
            So does allocating 2 MiB with normal pages and then only using 5 KiB.
            >inb4 but on Lin-
            Lazy commitment is moronic, Windows does it the right way.

          • 2 months ago
            Anonymous

            >So does allocating 2 MiB with normal pages and then only using 5 KiB.
            I'm using 8KiB and the rest were never faulted

          • 2 months ago
            Anonymous

            >only using 2 TLB entries
            You're clearly not the target group for bigger pages, then. 2 entries is negligible if you have 4096 4-KiB entries in your TLB. I'm talking big-balls programs here.

          • 2 months ago
            Anonymous

            well, thankfully on Linux you can hint kernel to ask it to use big pages when you need to, but normally it's not useful.
            Also lazy allocation is good, I can allocate 100GB and let it fault only for as much memory as I use without actually running out of RAM. If you want you can even ask Linux to explicitly prefault it so it works like windows or whatever.

          • 2 months ago
            Anonymous

            >well, thankfully on Linux you can hint kernel to ask it to use big pages when you need to
            What exactly are you talking about? MAP_HUGE_2MB/MAP_HUGE_1GB aren't hints, but requirements, and trying to tell the kernel to use transparent hugepages via madvice is a fricking mess because knowing guarantees you get a properly aligned address from mmap in the first place.

            >I can allocate 100GB and let it fault only for as much memory as I use without actually running out of RAM
            Until it does and then randomly kills processes. Windows' approach is better, where you can reserve virtual address space and then commit and decommit it as you need it. In terms of costs it's a mode switch either way.

            >If you want you can even ask Linux to explicitly prefault it
            What if I want more granular control though?

          • 2 months ago
            Anonymous

            >Until it does and then randomly kills processes.
            but my process is what will get killed first so it's not a problem

          • 2 months ago
            Anonymous

            >so it's not a problem
            For whom?

          • 2 months ago
            Anonymous

            for me, I can concede that my program is bad if it gets killed

          • 2 months ago
            Anonymous

            You're underestimating how desperate users can get, though: https://github.com/strace/strace/issues/14

          • 2 months ago
            Anonymous

            but my program won't segfault from this, just get killed for using too much memory
            And anyway, I'd only do this for something not done everyday, just a batch job with bump allocator where it has to run as fast as possible and it's ok if it uses 10+GB quickly then quits, and all it cost me was one mmap call

          • 2 months ago
            Anonymous

            >What if I want more granular control though?
            use for loop and access first byte of every page lol

          • 2 months ago
            Anonymous

            That's just the committing part, but I deliberately mentioned decommitting, too. The best madvice can offer is MADV_DONTNEED.

          • 2 months ago
            Anonymous

            Why would anyone need more? All of this is relatively "slow" and complicated in any case.

      • 2 months ago
        Anonymous

        At the lowest level it actually is. And besides, when you get down to the level of creating a memory controller in a HDL, you open various pages and streaming data from that open page is very fast. Iirc you can basically interleave starting read and write commands while previous reads and writes are ongoing. (been a few years since I did that). But anyway if your reads are predictable, and your writes can be buffered it is a huge win.

        Accessing (ddrx) sdram randomly is very, very slow.

        • 2 months ago
          Anonymous

          I wrote my own toy kernel before and it isn't one big array, I got several fricked up disjoint ranges that made no sense whatsoever, RAM manufacturers are homosexuals

          • 2 months ago
            Anonymous

            Are you confusing RAM with address space? Because yeah, hardware allocates ranges in that address space to allow the kernel to communicate with it.

          • 2 months ago
            Anonymous

            No I'm talking about physical address ranges that are actually indexable, kernels have to setup page tables manually for some stupid reason and remap everything, since RAM sticks are N chips o M size, I'd expect those ranges to match it, but instead I had something completely inane that does not correlate to that at all, maybe it's just dead cells

          • 2 months ago
            Anonymous

            >maybe it's just dead cells
            unless you are running ECC ram, your computer can't even detect that. If you do have ECC ram, I'd guess you would get a NMI on a un-correctable error (but don't really know).

          • 2 months ago
            Anonymous

            I was just lazy and got limine bootloader to get the addressable physical memory ranges, luckily I don't have to deal with stuff like this on a daily basis, so maybe virtual memory isn't that bad.

          • 2 months ago
            Anonymous

            Sounds very cool, but I suspect you should be b***hing at your bios vendor or the modern pc architecture.

  28. 2 months ago
    Anonymous

    literally just read the fricking paper dumbass
    https://queue.acm.org/detail.cfm?id=3212479
    but if you're too brainlet to into that, riddle me this
    >what is NUMA and cache coherency

  29. 2 months ago
    Anonymous

    >Your computer is not a fast PDP-11
    It is. Sneed more troony scum.

    • 2 months ago
      Anonymous

      PDP-11 is a product made by a specific company. It's a specific instruction set, not slang for "generic von Neumann architecture."
      >your 747 IS a fast Cessna

  30. 1 month ago
    Anonymous

    So how is Rust closer to modern hardware than C?
    It's shit at multiprocessing, doesn't do anything special for cache locality, and gets beaten by speed tests in C on modern hardware

    • 1 month ago
      Anonymous

      does it even have treads yet

    • 1 month ago
      Anonymous

      >and gets beaten by speed tests in C
      Early tests showed the opposite, have the compiler writers improved their game?

      • 1 month ago
        Anonymous

        >tests and benchmarks
        What drives me nuts about benchmarks is that every time I implement an algorithm in multiple languages...for fun (LeetCode/HackerRank puzzles) or out of curiosity...C beats everything else. It wins even if the algorithm is the same, wins by a wide margin if done "the C way." Tests and benchmarks tell me, for example, that "Java is fast sar", but when I try it, it's dog slow, and that's after I account for the JVM getting to a usable state.

        I should clarify: same implementation of an algorithm might use structs in C and objects in OOP languages, but is otherwise the same solution. Naturally if C++ has the exact same code as C then it's going to turn in the same times. "The C way" means the solution is similar but I'm taking advantage of something I can easily do in C

        >it applying to C too is the problem, cniles larp a lot when in the end their language isn't special
        In C a string is just an array of bytes. In most other languages it's an opaque and immutable type. In C string processing can be orders of magnitude faster. And in fact many high level languages implement their string functions using C under the hood.

        In C an array of any type is simply a contiguous block of memory. If you want something more sophisticated it's up to you to code it. Iterating over the array is simple arithmetic on a pointer, and the CPU's prefetch can easily predict what you'll need next if you're iterating forward. In many higher level languages the default array/list/etc. is actually a complicated, linked structure under the hood. It's great for resizing when programmers don't know (i.e. don't think about) what size they will end up with, but terrible for performance.

        In C you can treat a block of memory as an array of any type you like at any time you like. This makes it easy to speed up certain operations just by using a wider type. This is completely foreign to just about every other language. There are situations where C basically lets you use the ALU as if it was a vector unit, which is not an option in most other languages.

        C does not have built in complicated types. It's up to you to import or implement them. The source of the "it's a hash problem" copypasta. This at least makes you think about their costs and which is most appropriate. In higher level languages devs blindly use objects, hash maps, lists, dictionaries, etc. without once thinking about their costs because they are there and convenient. If you spent a week watching a C and Java or Python or even C++ dev try to solve the same problem, you would see the C dev making more efficient decisions over and over again.

        I could go on. None of this has anything to do with the compiler.

        that a developer wouldn't necessarily do even in C++ because it's not proper or 'how you do things', and can't do in something like Python.

        Granted I've never included Rust before so maybe it would surprise me. Occasionally C++ surprises me and wins, there are occasions where the compiler knows more from a C++ solution. But as a general rule I see:
        C
        C++
        C#
        JavaScript (it's actually decent on performance)
        ...
        Java off in the distance
        Python (and I've seen Python beat Java)

        Of course someone could argue that my puzzle algorithms are even less valid than a carefully chosen benchmark suite...but it just shocks me that I never see what common benchmarks claim.

        • 1 month ago
          Anonymous

          JS over Java? Usually I see Java over JS, but since that I despise Java, I want to believe this.

          • 1 month ago
            Anonymous

            >JS over Java? Usually I see Java over JS, but since that I despise Java, I want to believe this.
            That's what I've seen. Again...this is LeetCode/HackerRank puzzles. Which raises the same question as any synthetic benchmark: how relevant to the real world? And did the tester (me) frick up something in the install/config? But Java often disappoints, and is the most glaring example of me looking at the times vs. published benchmarks and thinking
            >wtf is going on?
            If it was one example I could believe it was something in my code. If it's most, including other people's solutions...wtf? Unfortunately I never dug deeper.

          • 1 month ago
            Anonymous

            Eh, doesn't really matter. I hope I never have to touch java.

            C, Go, JS and python for dirty scripts is the comfiest zone.

          • 1 month ago
            Anonymous

            Outside of puzzles and algorithm testing, I despise Java. It's not the language per se. Just the overly complex, academic "enterprise objects" complexity that grew out of it. That and the fact that it's flooded by a certain type of programmer... Even for puzzles, I only ever use it to test it. Otherwise frick it.

  31. 1 month ago
    Anonymous

    I can't believe this dumpster fire of a thread is still going

    • 1 month ago
      Anonymous

      Luckily no one gives a shit what you're believing.

  32. 1 month ago
    Anonymous

    lisp is low level

    • 1 month ago
      Anonymous

      By what metric??

  33. 1 month ago
    Anonymous

    We are falling off page 10 very soon.
    Any interest for an /aig/?

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