Why is C slower than Bolin? (bolinlang.com)

You are comparing file IO, string to int, raw processing, and text output speed all at the same time. There are pros and cons associated with the choices made in both sets of libraries and compilers for each of those aspects. What exactly are you trying to measure? Can you isolate those parts more specifically and compare them instead? That would probably be more informative.

Spoiler: the title is clickbait and the article actually says that C isn't really slower.

The initial C implementation written by the author that was passed off as representative of C was naive and had a couple of performance blockers. The author points out those performance blockers, and once the author gets rid of those blockers and re-tests te conclusion is that C isn't actually slower.

When I run the "faster" C code, it takes 176 ms. When I run this C++ code:

  #include <iostream>
  #include <fstream>
  int main() {
    auto& out = *std::cout.rdbuf();
    std::filebuf in;
    in.open("/tmp/numbers", 
      std::ios::in);
    for (int c, n = 0; 
         (c = in.snextc()) != EOF;) {
      if (c != '\n') {
        n = n * 10 + (c - '0');
      } else {
        out.sputc((n & 7) + '0'), n = 0;
      }
    }
    std::cout << '\n';
  }

it takes 84 ms (and presumably 90 ms on the author's machine).

So, why is Bolin slower (and longer) than C++? And why is so much of published code so bad?

    #include <stdio.h>
    #include <stdlib.h>
    #include <sys/mman.h>
    #include <sys/stat.h>
    #include <fcntl.h>
    #include <string.h>
    #include <errno.h>


    int main(int argc, char *argv[])
    {
        int arraySize = 4096;
        char*array = (char*)realloc(0, arraySize);

        int f = open("/tmp/numbers", O_RDONLY);
        if (f < 0) { return EXIT_FAILURE; }

        struct stat fstat;
        stat("/tmp/numbers", &fstat);

        char* buf0 = mmap(NULL, fstat.st_size, PROT_READ, MAP_PRIVATE, f, 0);
        char* buf = (char*) buf0;

        int i = 0;
        for (; buf < buf0 + fstat.st_size;)
        {
            if (i >= arraySize) {
                arraySize *= 2;
                array = (char*) realloc(array, arraySize);
            }

            int sv = 0;
            unsigned long value = 0;
            
            for (;;sv=1) {
                
                int c = *buf++ - '0';
                
                if (c < 0 || c > 9)
                    break;
                
                value = value * 10 + c;
            }
            
            if (sv) {
                array[i++] = (value & 7) + '0';
            }
        }
        array[i++] = '\n';
        fwrite(array, 1, i, stdout);
    }


  $ time ./mmap-ver | sha1sum 
  9fb65214d11697bf66753db443edb017b7f08fdf  -

  real    0m0.346s
  user    0m0.304s
  sys     0m0.060s

  $ time ./second-article-ver | sha1sum 
  9fb65214d11697bf66753db443edb017b7f08fdf  -

  real    0m1.168s
  user    0m1.019s
  sys     0m0.028s

  real    0m0.854s
  user    0m0.564s
  sys     0m0.054s

  #include <stdio.h>
  int main() {
    FILE* in = fopen("/tmp/numbers", "r");
    for (int c, n = 0; (c = getc(in)) != EOF;) {
      if (c != '\n') {
        n = n * 10 + (c - '0');
      } else putchar((n & 7) + '0'), n = 0;
    }
    putchar('\n');
  }

  #include <sys/mman.h>
  #include <unistd.h>
  #include <fcntl.h>
  #include <cstdlib>
  int main()
  {
    int fd = ::open("/tmp/numbers", O_RDONLY);
    auto end = ::lseek(fd, 0, SEEK_END);
    char const* in = (char*) ::mmap(
      nullptr, end, PROT_READ, MAP_PRIVATE, fd, 0);
    char const* inpos = in;
    char* out = (char*) std::malloc(end), *outp = out;
    for (int n = 0; inp != in + end; ++inp) {
      if (*inp != '\n') {
        n = n * 10 + (*inp - '0');
      } else *outp++ = ((n & 7) + '0'), n = 0;
    }
    *outp++ = '\n';
    ::write(1, out, outp - out);
  }

Better title: why are some C stdlib functions slower than some Bolin stdlib functions. Unlike with many other languages, it's totally fine to write C code and (almost) completely ignore the stdlib functions. The C stdlib is essentially just the least common denominator to get trivial cmdline tools working (badly) across platforms, but that's about it.

I think there is merit to these discussions. One has to ask what the most natural/idiomatic program to solve a problem is, and sometimes the performance of that matters more than the utmost performance you can get from the language.

I'm know to be a rust fanboy, so I'll talk about C++ instead. C++ is known to be fast, but theres also some known logic that you should use smart pointers to have more memory safety than raw pointers. If you follow that you'll end up with a slower program. Of course, you can remove those and manage the pointers yourself, but then you have to deal with documenting the lifetimes properly.

These are trade offs people agree to when using a language. The easier thing might be slower and that's ok. Speed isn't always critical, so you can't exactly rate languages by that metric alone

Nobody understands C use fgets when he/she wants speed.

The whole point of C is the programmer decides the performance himself, not trying to the fastest. None of the popular languages consistently deliver this.

According to the website [1] there is a strict license to this programming language.

> The License is intended for free learning and hobbyists and is a personal use license which means the Software may be installed and run only on Licensee computer as required for the purposes of Licensee’s code to produce a binary executable output (the “Executable Product”) only on Licensee-controlled Endpoint. An Endpoint is defined as a computer operating system (“OSE”) of any type physically hosted, but limited to Licensee’s internal personal use and not for distribution or any other use. For certainty, Licensee may not: distribute, assign, sell or grant any rights in or to the Software OR the binary executable product created by using the Software.

People of course can license the fruits of their labor however they wish to, I just can’t understand why someone would license their compiler in a way that prohibits me from sharing a useful program I made with my family or friends.

[1] https://bolinlang.com/eula