Hacker News Reader

Comment by pizlonator | Hacker News Reader

> TLDR: 4x slowdown in the normal case

4x slower isn't the normal case. 4x is at the upper end of the overheads you'll see.

That's good to know!

C is immensely powerful, portable and probably as fast as you can go without hand-coding in the architecture-specific assembly. Most of the world's information systems (our cyberstructure) rely directly or indirectly on C. And don't get me wrong, I'm a great enthusiast of the idea of sticking to memory-safe languages like Rust from now on.

The hard truth is will live with legacy C code, period. Pizlo's heroic effort bridges the gap so to speak, it kind of sandboxes userspace C in a way that inherently adds memory safety to legacy code. There are only a few corner cases now that can't be bothered by any slow-down vis-a-vis unsafe C, and the great majority of code across every industry would benefit much more from the reduced surface of exposure.

I'd love to see some practical benchmarks for programs such as grep and other binutils. I'm also pretty curious if it turns up any bugs in them in use.

> 4x is at the upper end of the overheads

This is already quite impressive. Many automatic memory managed languages have more than 4x worst-case slowdown. E.g. Google-backed Golang is ~1.5× to ~4× slower than optimized C++. I suppose there are many ways to further speed-up Fil-C if more resources were given to the project.

This seems likely. I would assume that the vast majority of memory access can be statically proven safe if you throw enough money at the problem, meaning the bookkeeping can be eliminated.

> I would assume that the vast majority of memory access can be statically proven safe if you throw enough money at the problem, meaning the bookkeeping can be eliminated.

You can't really do this without adding the same sorts of annotations as Rust or Safe C++. Especially if you care about keeping modular/separate compilation and code reuse.

You can do it without annotations if you only do it as an optimization that's not guaranteed to succeed.

If it's not guaranteed to succeed it's not really memory safe. The subset that can be fully optimized without any annotations is really limited, more like writing old-style FORTRAN or COBOL code where you don't dynamically allocate at all to begin with. It may be "safe" but it's also not really helpful.

Reply on news.ycombinator.com