Hacker News Reader

Comment by meisel | Hacker News Reader

Although this project is undoubtedly very cool, and maybe simplifies build processes by having a single binary, is there any other reason to use it? How does it compare in terms of performance, static linkability, standards conformance, etc. with musl and glibc? I’m curious because I’m picking a libc at the moment for my project.

View on HN

> How does it compare in terms of performance

I tried rsync for Windows from its "cosmos" pile of binaries (https://github.com/jart/cosmopolitan/releases/download/3.3.1...), and it was too slow to be usable compared to WSL rsync.

For many other utilities I use Busybox for Windows (https://github.com/rmyorston/busybox-w32) which is well maintained, fast, and its maintainer is also very responsive to bug reports.

You're basically just benchmarking the WIN32 filesystem versus a Linux VM in that case. The Windows file system is famously slow. It'd make more sense to compare a Cosmo binary running on WIN32 with a WIN32 native program. For example, Emacs has a WIN32 port where they wrote all the Windows polyfills on their own, and because they aren't experts on Windows, the official GNU Emacs Windows releases go a lot slower on Windows than if you just compile Emacs from source on Linux using Cosmo and scp the the binary over to run on Windows. See https://justine.lol/cosmo3/

I would argue it's less about the build process and more about the user experience - no install, no "pick the right binary for your platform", just "download this file and run it". I don't think it's literally a static binary, but on anything but a `FROM scratch` container it might as well be.

Also I think there were some numbers showing that it sometimes had better performance than alternatives, but I can't seem to find the post right now.

The number of people this effects seems like it must be pretty small. There's the subset of people that have more than one OS. There's the subset of those that use command line tools (this explicitly doesn't do GUIs). There's the subset of those that would even think about some convenience of downloading a single binary command-line tool for multiple-OSes rather than use (a) something compiled specifically for that OS or (b) using something specific to that OS (rmdir on windows, rm on linxu/mac).

I use git, I've never felt especially put out that it's a different executable on mac, windows, and linux (situation "a"). I also just use what's common for the OS I'm on since there's so may other differences (C:\foo/bar) vs (/foo/bar) etc... (situation b)

You feel comfortable with git because someone put a lot of work into making its source code and ecosystem portable.

https://github.com/search?q=repo%3Agit%2Fgit+WIN32+OR+mingw+...

If no one had done that work, you'd have to port it yourself.

Cosmo provides a development environment that can ease this work. It's not only about the fat binary.

That's a good point. I guess I'd be more likely to pick some library because even if the binary is portable, the OS is not. Understanding where to store user preferences for example. (unix usually puts them in ~/.somefolder but on Windows it's somewhere in LocalAppData and on mac it's often in ~/Application Support). Understanding that paths have different parts, ... I'm sure there's more.

I don't know to what level C++20 does all this now with filesystem and threads etc... There's also things like libuv, Abseil, etc. But, maybe I'll check out cosmo next.

Even if you have to do some runtime detection/self-configuration, cosmo is great because it lets you pack that logic into a single binary and pick it at runtime, so the user experience is still "download a single file and run it and it works" regardless of their OS.

There are all sorts of issues in trying to come up with a single abstraction for multiple platforms. It's an impedance mismatch problem, there is no single best solution.

I like where cosmo is putting effort. The self-hosting toolchain and build system for example. That was always a knowledge barrier for me (I'm a webdeveloper, I know nothing).

Personally, it was so different and shocking, that I started to understand a lot of things by the contrast it created with other code. Cosmos's Makefiles were different, the linker was being used in a way that made me notice it as a distinct part of the toolchain, the demos actually worked, etc. It made me interested in that stuff, made it more acessible.

I don't know enough to compare to musl, but I suspect being ISC licensed (similar to musl's MIT license) allows for static linking without upstream impact such as GPL.

Would be curious regarding features and performance comparisons with musl, which seems to come up a little short compared to say gnu libc.

I suspect parent commenter isn't just asking about static linking from the perspective of licensing but about technical feasibility; at least part of the reason people use musl is that static linking glibc isn't well supported.

Cosmo author here. We used to build our code with musl-cross-make. Once Cosmopolitan got good enough that we could compile GCC using Cosmo, our build latency dropped in half. https://x.com/JustineTunney/status/1726141024597324189

Cosmopolitan Libc is 2x faster than Musl Libc for many CLI programs like GNU Make and GCC because it has vectorized string libraries like strlen(). Musl won't merge support it on x86. I even mailed Rich patches for it years ago.

Cosmopolitan's malloc() function is very fast. If you link pthread_create() then it'll create a dlmalloc arena for each core dispatched by sched_getcpu(). If you don't use threads then it'll use a single dlmalloc arena without any locking or rdtscp overhead.

Cosmo has pretty good thread support in general, plus little known synchronization primitives from Mike Burrows. You can do things like build a number crunching program with OpenMP and it'll actually run on MacOS and Windows.

Cosmopolitan plays an important role in helping to enable the fastest AI software on CPUs. For example, Mozilla started an open source project called LLaMAfile a few months ago, which runs LLMs locally. It's based off the famous llama.cpp codebase. The main thing Mozilla did differently was they adopted Cosmopolitan Libc as its C library, which made it easy for us to obtain a 4x performance advantage. https://justine.lol/matmul/ I'm actually giving a talk about it this week in San Francisco.

At the AI engineer fair, or some other event?

"We used to build our code with musl-cross-make."

Wish there was something like musl.cc, i.e., static GCC less than 250 MiB, for cosmo libc.

It's called cosmocc. https://github.com/jart/cosmopolitan/releases/download/3.5.1... the documentation is here: https://github.com/jart/cosmopolitan/blob/master/tool/cosmoc... and here https://justine.lol/cosmo3/#install

static musl make is at least 4x smaller than cosmo make

cosmo make probably works on at least 4x the number of operating systems

   # cd /usr/local/bin
   # file make
   make: /usr/local/bin/make: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), static-pie linked, stripped
   # stat -c %s make
   297104
   # cd
   # tnftp -4o make https://cosmo.zip/pub/cosmos/bin/make
   # stat -c %s make
   1397059

The file size is larger, but it can use less memory than an x86-only Linux binary for musl libc: https://justine.lol/cosmo3/

Reply on news.ycombinator.com