Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The case against a C alternative

c3.handmade.network

Post reply on HN
Print view View original

281–290 of 388 posts

Re: The case against a C alternative

#281

Post by jstimpfle »

badpun wrote: post #270
jstimpfle wrote: post #234

Earlier quoted context omitted.

I wholeheartedly agree, the speed of processing includes annoys me most about C. The sad part is that the mainstream alternatives that I have on the radar are _even slower_ to build. And usage of the preprocessor in APIs is allowing for good things, at least for a compiled systems language like C: Macros allow to get rid of boilerplate on the syntax level and if-defs allow for compatibility. Both points' significance…

What bother me most is not even the speed of compilation (although it's a major pain too), but the fact that I need to create a header file for every .c file I want to have used from outside it's compilation unit, and add method declarations in it. In 2022 it's SO BACKWARDS it hurts.

I almost never found that painful. Maybe a couple things that help: 1) Improve modularization. APIs should be small (as a rule). 2) Don't write a new file for each "class". It's not a problem to have files with more than 1 KLOC. But it is problematic to have a lot of really small files, as is (I think) customary with say Java.

Re: The case against a C alternative

#282

Post by aerxes »

mwcampbell wrote: post #211
jcelerier wrote: post #208

Earlier quoted context omitted.

> I don’t know dude, if you want to write software for the worst performers instead of commodity hardware that’s up to you I want to write software that people, most people, not only those with SV salaries able to buy a computer every year, can use. Here's the current best seller laptop in Amazon in my country: https://www.amazon.fr/Dell-Inspiron-i5-1135G7-Ordinateur-por... It's half past 2022 and the most sold lapto…

Thank you! Please keep pushing such certifications until they become regulations that, like GDPR, even we American developers cannot ignore. Then I can make a strong business case to move away from Electron in the product I'm currently working on. Edit to add: Related to your links to best-selling computers, I've been thinking about downgrading to a low-spec PC as my daily driver, and using a remote machine for the t…

I’m not advocating making software multithreaded only, since obviously that doesn’t make sense.

But, in many modern languages (including c++) multi threading 1. Doesn’t significantly detract from the performance of single core systems 2. Can massively improve the performance of multi core systems, even with 2 cores or more.

For appropriate applications, the memory overhead and the cost of the bootstrapping code for instantiating a worker thread should be dwarfed by the time of actually computing the task (we’re talking about actions 100ms or longer). Not using multiple threads when you could reasonably half or quarter that time (without needing to drop support for single-core systems) is just foolish. If you’re that worried about single core performance then maintain two code paths, but at least recognize that the majority of commodity systems sold today, including the ones you listed, have multiple threads available to them to do the work that have the most painful wait times.

Re: The case against a C alternative

#283

Post by rowanG077 »

aerxes wrote: post #279
rowanG077 wrote: post #216

Earlier quoted context omitted.

You should always write software for the worst performers. Unless you have a very good reason not to. Writing for the top performers is how we got into the silly mess where computers from 30 years ago have much higher ux then now.

If we were arguing about designing vehicle safety testing suites for the worst performers (a very real problem that we have right now) we wouldn’t even be having this conversation. Writing multithreaded applications increases the performance ceiling . If an application can’t take use of multiple threads, but is written in a multi-threaded way, there’s no harm done. It simply runs the multi threaded code in a single t…

I don't disagree with your specific point here, it's easy to dynamically allocate threads based on system cores. But I disagree that you should write your code for a medium speced system.

Re: The case against a C alternative

#284

Post by aerxes »

rahen wrote: post #222
aerxes wrote: post #195

Earlier quoted context omitted.

I don’t know dude, if you want to write software for the worst performers instead of commodity hardware that’s up to you Just that single core systems are dying and probably won’t come back. Even Raspberry Pi’s are quad core now.

Writing for the top performers is the main reason why computers turn into e-waste. It's Wirth law applied. I wish more developers would work on RPIs for the same reason.

The point that I’m making is that you can write multi threaded applications without dropping support for single core systems.

Re: The case against a C alternative

#285

Post by badpun »

jstimpfle wrote: post #281
badpun wrote: post #270

Earlier quoted context omitted.

What bother me most is not even the speed of compilation (although it's a major pain too), but the fact that I need to create a header file for every .c file I want to have used from outside it's compilation unit, and add method declarations in it. In 2022 it's SO BACKWARDS it hurts.

I almost never found that painful. Maybe a couple things that help: 1) Improve modularization. APIs should be small (as a rule). 2) Don't write a new file for each "class". It's not a problem to have files with more than 1 KLOC. But it is problematic to have a lot of really small files, as is (I think) customary with say Java.

I come from the Java world, so I'm very used to every semantically separate bit of code sitting in its own file. I think it's superior to having multi-KLOC source files (as is common in C/C++ world, because it minimizes the header writing and maintenance busywork), because then you can browse code via a file browser, which is typically a panel in your IDE. The C alternative to that would be having the same file opened in multiple tabs, and heavy usage of (IDE) bookmarks? I don't find that as convenient.

As to improving modularization, in order to fix compilation speed issues I was trying out the "program as a single compilation unit" approach advocated by handmade people, and I found that I had to spent a good amount of time in moving code between modules, and their subsequent headers. So annoying... Perhaps it wouldn't be so infuriating if I didn't spend the past 15 years coding in languages where this is a problem solved automatically and invisibly by the compiler.

Re: The case against a C alternative

#286

Post by enqk »

temac wrote: post #245
enqk wrote: post #180

Earlier quoted context omitted.

check this out: https://github.com/WebKit/WebKit/blob/main/Source/bmalloc/li...

Interesting but I'm not sure about the relevancy to the above comment. On a sidenote, it has weird claims: > obviating the need for ownership type systems or other compiler approaches to fixing the type-safety of use-after-frees. This means that we need one heap per type, and be 100% strict about it.

I guess I have to quote from it, then:

---

C lets you do most of what C++ can if you rely on always_inline. This didn't used to be the case, but modern C compilers will meat-grind the code with repeated application of the following things:

- Inlining any always_inline call except if it's recursive or the function uses some very weird features that libpas doesn't use (like goto pointer).

- Copy-propagating the values from the callsite into the function that uses the value.

Consequently, passing a function pointer (or struct of function pointers), where the pointer points to an always_inline function and the callee is always_inline results in specialization akin to template monomorphization.

This works to any depth; the compiler won't be satisfied until there are no more always_inline function calls. This fortuitous development in compilers allowed me to write very nice template code in C. Libpas achieves templates in C using config structs that contain function pointers -- sometimes to always_inline functions (when we want specialization and inlining) and sometimes to out-of-line functions (when we want specialization but not inlining). Additionally, the C template style allows us to have true polymorphic functions. Lots of libpas slow paths are huge and not at all hot. We don't want that code specialized for every config. Luckily, this works just fine in C templates -- those polymorphic functions just pass around a pointer to the config they are using, and dynamically load and call things in that config, almost exactly the same way that the specialized code would do. This saves a lot of code size versus C++ templates.

Re: The case against a C alternative

#287

Post by proto_lambda »

tialaramex wrote: post #273
Ygg2 wrote: post #192

Earlier quoted context omitted.

Interesting. Can you list an example of C++ type system allowing optimization Rust system doesn't?

Rust's assumption is that it's the compiler's job to reject all wrong programs (usually with a helpful diagnostic). In C++ the assumption is that it's the compiler's job to permit all correct programs. You obviously ideally want both, but that's not actually possible when you have a language this powerful. So, Rest's choice means sometimes (more rarely these days but it can happen) you will write a program that is co…

To expand on your float sorting example, sorting a slice[1] in Rust requires the element type to implement the Ord trait, i.e. be totally ordered. Trying to sort a slice of floats will result in a compiler error, even though it might be totally fine as long as all your floats are "ordinary".

Instead, to sort a slice of floats, you have to explicitly specify what would happen for the non-ordinary cases; e.g. by using `.sort_by(f32::total_cmp)`, where f32::total_cmp()[2] is one possible interpretation of a total ordering of floats. This requires writing more code even for cases where it would be completely unnecessary.

[1]: https://doc.rust-lang.org/std/primitive.slice.html#method.so... [2]: https://doc.rust-lang.org/std/primitive.f32.html#method.tota...

Re: The case against a C alternative

#288

Post by aerxes »

rowanG077 wrote: post #283
aerxes wrote: post #279

Earlier quoted context omitted.

If we were arguing about designing vehicle safety testing suites for the worst performers (a very real problem that we have right now) we wouldn’t even be having this conversation. Writing multithreaded applications increases the performance ceiling . If an application can’t take use of multiple threads, but is written in a multi-threaded way, there’s no harm done. It simply runs the multi threaded code in a single t…

I don't disagree with your specific point here, it's easy to dynamically allocate threads based on system cores. But I disagree that you should write your code for a medium speced system.

That’s what debate’s about. I do recognize that caring about single threaded workloads and performance do contribute to snappier UI (and backwards compatibility).

Re: The case against a C alternative

#290

Post by bitcharmer »

logicchains wrote: post #199
woodruffw wrote: post #40

> Any C alternative will be expected to be on par with C in performance. The problem is that C have practically no checks, so any safety checks put into the competing language will have a runtime cost, which often is unacceptable. This leads to a strategy of only having checks in "safe" mode. Where the "fast" mode is just as "unsafe" as C. I don't think this is true, in the general case: Rust has shown that languages…

Rust does runtime bounds checks on array access, which the compiler can't elide in non-trivial cases (e.g. binary search), so if you want to write such algorithms as fast as in C, you need to use a lot of unsafe array indexing.

You might be referring to slices. Arrays in rust have to have a known length at compile time.
Post reply on HN