Why is C slower than Bolin?(bolinlang.com)
bolinlang.com
Why is C slower than Bolin?
https://bolinlang.com/c_sometimes_slow
5 comments
Just following up on this, in my opinion there would be more value in writing better C compilers and cross-compilation toolchains, linting tools, static analysis and optimization tools, and alternative standard libraries, than doing things like starting a new language altogether (e.g. Rust, Go, V, etc. etc.)
This is not to say that those languages don't have value: they are awesome and I am very attached to a couple.
However I still recognize that they are all trying to do something right by reinventing the wheel. Rather than building a "new" C from scratch, I think it would be better for everyone if we built on top of C.
This is not to say that those languages don't have value: they are awesome and I am very attached to a couple.
However I still recognize that they are all trying to do something right by reinventing the wheel. Rather than building a "new" C from scratch, I think it would be better for everyone if we built on top of C.
One constraint C has is its ABI. Bolin compilation model is different (article went up last week) and being constrained by it would be pointless. C allows unsigned variables to wrap, bolin doesn't (not enforced yet, beta is 0.1.0). If my team and I wanted to compete with speed we'd be handicapped by C constrains. This current article shows a reason why you might want to use posix read instead of fread/fgets, the Bolin compiler doesn't use libc or any other lib at the moment because we wanted it to be fast and because we knew we'd be writing our own libraries.
How do you suppose people can get rid of constrains that would make their language slower? I hear the whole reason carbon exist is because google couldn't get the C++ committee to budge on ABI
How do you suppose people can get rid of constrains that would make their language slower? I hear the whole reason carbon exist is because google couldn't get the C++ committee to budge on ABI
Bolin isn't the only language that can be faster than C. For processing arrays of numbers, Fortran is still likely to be the most performant.
Is there an easy way to implement tree structures (as needed for example in a compiler)?
PS: anyone who is interested should definitely click the download link and read the EULA...
Is there an easy way to implement tree structures (as needed for example in a compiler)?
PS: anyone who is interested should definitely click the download link and read the EULA...
There are always going to be tradeoffs -- as your article admits, the differences themselves come down to a 1 cycle difference, which would show up as about 1ms. If performance is really critical for an application, things like this are more than capable of being rewritten in an optimized form rather than relying on the standard library, which understandably doesn't try to cater to every use case. Or in other words, when performance is a concern, C is more than capable of providing the necessary tools to achieve it.
I don't think a comparison like this will convert anyone from C to Bolin. Where a possible argument may be made is that Bolin is a better language, and argue for the design decisions that were made in its implementation. Even so, people are bound to disagree, and the bottom line is that while C is imperfect, that's what makes it perfect.
C does not enforce rules on how its authors thought code ought to be written, and neither does C enforce one type of memory management over another. C has no preference over the way packages are managed, and neither does C prefer one standard library over another. C is unopinionated: it lets you do whatever you want to do however you want to do it.