5 ms·

Great post. An issue I have with it is the way it frames the speed of a language, e.g., Python, C, etc., especially here: > I implemented the same program usi

• JonChesterfield 2y ago
  The C runtime doesn't really show up on a profiler though. It's crawl the init_array then jump to main. Small enough that a lot of people don't notice the C runtime exists at all. Compiling C to efficient machine code is a much easier problem than compiling Go to similar machine code since all the heavy lifting is done by the programmer.
  • YZF 2y ago
    C doesn't really have a "run time". The startup code is optional and I wouldn't really call it a "run time" in the sense that Go has a runtime for managing goroutines and GC. It's not that easy to write Go code with no dynamic memory allocations and no GC pressure. I think it's fair to say "C is faster than Go". It's not purely a function of the language but a combination of factors including the quality of the compiler/optimizer, available libraries, and language features (and their performance cost).
    • yxhuvud 2y ago
      Yes it typically does have a runtime. For example, it has persistent structures in memory related to malloc/free, and the manipulation of those most definitely show up when you profile.
      • jstimpfle 2y ago
        It's a bit funny to call this "runtime" when malloc/free are nothing but library functions.
        • yxhuvud 2y ago
          Yes, it is a runtime provided by libc, but how on earth is it not a runtime?
          • jgalt212 2y ago
            Maybe the poster considers a runtime something more similar to a global event loop than a set of global functions.
            • yxhuvud 2y ago
              But libc is more than a set of global functions - it has a bunch of global state associated with them as well. And manipulation of that is what I consider a runtime.
              • jstimpfle 2y ago
                You can live entirely without malloc(). You don't need it. You can even allocate memory dynamically without malloc, just call a different API. On Windows, it's typical to use e.g. VirtualAlloc(). So thinking of malloc as runtime seems extremely strange to me. libc is not the only library that has "global state". There is nothing special about it. You don't need libc (yes, some compilers / platforms somewhat expect you to bundle libc). And malloc is not libc, although some of the functionality in libc uses malloc internally / gives you back memory that you are expected to free().
                • hnlmorg 2y ago
                  You can get different standard libraries and runtimes for other languages too. That doesn't mean that their de facto compilation and execution method isn't via a runtime.
    • JonChesterfield 2y ago
      It certainly does have a runtime and it isn't optional. It's usually in object files starting with crt, e.g. crt1.o. "c-run-time-1.o". That does whatever is necessary to make the machine look like the C world expects. Setting up the stack pointer before jumping to main is important. Arranging for argc/argv to work. Waking init array or section for global constructors. There's also libc which is roughly a pile of more-or-less useful functions, some of them implemented in terms of syscalls. That one is nominally optional. There's probably a compiler runtime involved as well, libgcc or libclang_rt.builtins or similar, which is likely to be cyclically dependent on libc. Compiler-dependent whether that is optional, and thus likely whether libc is optional in practice.
      • PhilipRoman 2y ago
        You absolutely can write void _start(void) and as long as you finish using exit() everything will work just fine. I've written some super small programs this way (on the order of few kilobytes) which don't interface with system libraries in any way.
        • planede 2y ago
          C code conforming to the ISO C standard generally requires a (very small) runtime.
        • JonChesterfield 2y ago
          That'll work on some systems and not others. Whatever compiled and linked your C arranged to _start to be at the place the instruction pointer starts from. Setting up your own stack from C is dicey but sometimes the default value for the stack register is usable as-is. I tend to go with ffreestanding and the crt*.o for the platform instead of going from _start directly but sure, you can write whatever startup code your platform wants yourself and link with -nostdlibs or similar. Some platforms are OK with just the address of the entry point burned into an elf. Compiler test code sometimes looks like that.
      • jstimpfle 2y ago
        Any other language can implement the same conventions, and those conventions aren't specified in the C standard but really platform specific.
• ternaryoperator 2y ago
  The golang runtime has a penalty due to the fact that it sets up memory for GC at startup. It is legitimately C runtime vs. go runtime.
  • cxr 2y ago
    So you agree with me.
  • Cthulhu_ 2y ago
    So the measurement is total application execution, not just the XML processing part itself? That's a bit of an unfair comparison, but then, it's a "micro"benchmark that should be taken with a grain of salt.
• hnlmorg 2y ago
  Some language paradigms are always going to produce less optimised binaries. Such as garbage collected languages vs non-garbage collected languages. And Python enables meta programming, which itself massively reduces the performance of the language (from a purely computational perspective). While C compilers do generally have much better support for optimisations, the language itself was initially designed to sit pretty close to assembly. So even unoptimised C will perform better than the equivalent code written in Go or Python using their respective idioms.
  • neonsunset 2y ago
    Garbage collection is completely orthogonal to the quality of emitted codegen. What GC does have impact on is the way VM handles memory management: - Cost of allocation helper calls / are they (partially) inlined - Cost of write barriers - Cost of GC pauses, their frequency or the cost paid in other places if it's shifted from GC pauses (which Go does) - Cost of thread suspension/yielding strategy - relates to the previous point but is distinct should a GC have full stop-the-world phase Generally speaking, Go's compiler is weak but where Go manages to get performance back are two areas: - Go forces you to write a lot of, effectively, manually inlined code by virtue of being painful to use abstractions and generics in - By constraining the range of tools you can use, it focuses on providing lightweight implementation for those (e.g. channels) This allows Go to excel at particular niche it is targeted at (networked back-end services) but results in its severe underperformance against expectations the moment you step away from that use case. Both JVM and .NET are good counterexamples to Go that being garbage collected does not mean sacrificing performance. Unfortunately, historical choices in JVM prevent it from reaching zero-cost abstraction + low/zero-allocation style of performance oriented code in C, C++ and Rust so C# remains pretty much the only GC-based language that lets you do so. Swift receives honorable mention but it appears to consistently have much worse performance due to ARC and virtual dispatch so it can't really compete unless you write totally-not-C code in it.
    • hnlmorg 2y ago
      You’re arguing against my point while going on to make the same point. Please note that I said “optimised” and not “quality”. The GP said quality but I deliberately didn’t. I want to be clear that myself and the author were strictly talking about code that is optimised for execution speed. There are a few other issues with your comment too. Such as conflating inlining with code deduplication wrt generics.