A “Better C” Benchmark • Hacker News Board

Re: A “Better C” Benchmark

#121

Post by tralarpa » Sat, Mar 27, 2021, 4:33 PM UTC

stiray wrote: post #100

varjag wrote: post #98

Earlier quoted context omitted.

Formula 1 is on the bleeding edge of technology, which C is resolutely not. If you're really into car analogies a better one would be racing a Ford T, which is indeed just as unsafe. (No offense, doing a fair bit of C work myself)

You are doing an unfair comparing of c/c++ with the availability of 3rd party libraries. There is just nothing wrong with c/c++. But you cant press alt+enter to get a third party library. And this is the only disadvantage for someone that is able to do c or c++. C, CAN be a bleading edge. Depends on who is using it., based on a simple fact that there is nothing you cant do. Except for the amount of money the companie…

Wait, we can also do that kind of discussion in the opposite direction:

I think that most C programmers are just programming monkeys. People who enjoy solving sudokus^H^H^H^H^H^H^H pointer arithmetics and format string riddles and think that incrementing a variable in the middle of a statement is the best thing since sliced bread. Programmers, who do not have the necessary skills to become engineers - the latters needed to build modern systems. I think it's good that languages like C exist, so we can keep those people busy and let the more capable people work on what makes the real difference when it comes to robustness, performance, and integrity: algorithms, data structures, and software architecture. Things that require abstract thinking beyond "Where do I store my pointer so I don't forget to free that struct later?".

Re: A “Better C” Benchmark

#122

Post by ovis » Sat, Mar 27, 2021, 4:36 PM UTC

kidfrommars wrote: post #114

The Rust code is very non-idiomatic, which is probably part of the reason why it seemed difficult to put together and why reading it is a bit of a chore. Compared to Zig or Go, naively translating C code into Rust isn't going to work nearly as well. This isn't necessarily because Rust is more complicated (although it definitely is) but has a lot to do with the fact that it's semantics are inspired almost as much by O…

How would you structure it (in broad strokes)?

Re: A “Better C” Benchmark

#123

Post by seoaeu » Sat, Mar 27, 2021, 4:37 PM UTC

logicchains wrote: post #111

yakubin wrote: post #59

Earlier quoted context omitted.

> His dismissal of C++ as "not having a build system" seems like considering the language without the ecosystem. Using cmake and llvm solves all of his gripes on C++. Last week I debugged an issue in a big C++ codebase, where we were getting memory corruption. Source of the issue? Compiler, linker and build system being separate things and only compiler understanding types (also, lack of modules, which is another sym…

>Namely, conditional compilation was involved, someone made a struct which had a field in it based on whether a preprocessor constant was defined or not No offense but this just sounds like bad design. Haskell has the C preprocessor so technically that particular criticism would apply to it too, but nobody would say it's Haskell's problem just because in theory people could use this feature to write terrible code. (I…

I've seen this sort of thing all the time. Not the part about different preprocessor defines in different files, but about having a struct's contents depend on some compile time conditions. It comes up when you want to track extra debug information but only for debug builds. It comes up if you need to store platform specific information in a common struct. It can come up if you have a major feature that you want to toggle on/off at compile time. Etc.

Re: A “Better C” Benchmark

#124

Post by simpleguitar » Sat, Mar 27, 2021, 4:44 PM UTC

drran wrote: post #33

renox wrote: post #3

What I find funny is his choice of languages: 'hipe driven' I'd say. If you can use a GCd language like Go why would you go with Rust(which add a lot of complexity) or Zig(which is unsafe(1)) instead of the numerous existing GCd languages D,Nim, Crystal, Java,... which provides memory safety without complexity If you can't why evaluate Go instead of Ada or DasBetterC? 1: At work a frequent issue in C++ is UAF a point…

I have here program in Go and in Rust. They are very similar (Rust program is shorter), but Rust version is 5x faster than Go version.

I bet you are allocating/deallocating something in a loop. Give the Go profiler a whirl. I bet it will be pretty easy to remove, too.

I have not run into a case where go can't be within 2x speed of C.

And I love how zig is even closer to C, but has the ergonomics of go.

What an amazing time to be alive.

Re: A “Better C” Benchmark

#125

Post by stiray » Sat, Mar 27, 2021, 4:51 PM UTC

tralarpa wrote: post #121

stiray wrote: post #100

Earlier quoted context omitted.

You are doing an unfair comparing of c/c++ with the availability of 3rd party libraries. There is just nothing wrong with c/c++. But you cant press alt+enter to get a third party library. And this is the only disadvantage for someone that is able to do c or c++. C, CAN be a bleading edge. Depends on who is using it., based on a simple fact that there is nothing you cant do. Except for the amount of money the companie…

Wait, we can also do that kind of discussion in the opposite direction: I think that most C programmers are just programming monkeys. People who enjoy solving sudokus^H^H^H^H^H^H^H pointer arithmetics and format string riddles and think that incrementing a variable in the middle of a statement is the best thing since sliced bread. Programmers, who do not have the necessary skills to become engineers - the latters nee…

/* I have noticed people are downvoting. Face the reality, it is not my fault the world is as it is (but it is our fault if it stays like that). Dont shoot the messenger, this is something that all developers, regardless of language should be aware of. */

Sure and I agree. The companies have tried to use the monkeys for C development, but it didn't work. There is just too much to be aware of. All the next goals were to find a technology that would still keep "low" paid monkeys but prevent them doing stupid mistakes and train them as fast as possible to produce some results, whatever the results were.

And we got the winners that we today call java, js, c#, ruby, php, python,... and the devices that are using extremely capable cpus with vast amounts of memory and "diskspace" to produce inferior results.

It is not the point that any of those languages is faster (I love those benchmarks comparing speed of language that is written in c/c++ with c/c++), that any of those is better.

The point is that they allow companies to pay less to the developers for the same effect with a loss on speed, memory and all the other handy dandy things that can be bought on (and dumped to) consumer side.

It was never about speed, memory footprint, syntax. It was always about paying software developer the least amount possible.

And we actually helped, open source(tm) anyone? Or in other words, working for free for no benefit but dubious recognition that no one but ourselves care about?

I wonder what is any other branch of industry that relies so heavily on recognition instead of payment.

As I have mentioned, I want to build a house, please recommend to me anyone prepared to build it for free for "recognition" instead of payment...

... No?... So we are the only ones THAT stupid?

Re: A “Better C” Benchmark

#126

Post by mlyle » Sat, Mar 27, 2021, 4:57 PM UTC

scatters wrote: post #71

WalterBright wrote: post #37

Earlier quoted context omitted.

Doing what D does to detect references to expired stack frames would require some restructuring of C++'s semantics, which seems unlikely. For example, D can detect this error: @safe: int* f(int* p) { return p; } int* g() { int i; return f(&i); } Compile with: dmd test -dip1000 and the result: Error: reference to local variable i assigned to non-scope parameter p calling test.f

At -O2 or above, gcc emits Wreturn-local-addr.

Within a single compilation unit, and only in this most trivial case.

Re: A “Better C” Benchmark

#127

Post by e12e » Sat, Mar 27, 2021, 4:59 PM UTC

lew89 wrote: post #58

david_for_you wrote: post #45

Earlier quoted context omitted.

This seems to be missing a return in the NULL check for handle in the match_file function. This leads to fgets being called with a NULL pointer, which I don't know what it does, it may be OK. I would argue that this is why a "better C" can be useful, it's the kind of error that would be much harder to make in rust.

There is missing NULL check, but it doesn't crash, because the function would get nonexistent filename only if filesystem driver would do something strange (or file would be deleted just between readdir and fopen). xD I also noticed, that I don't close files and directories. Not a big deal, because fully functional and 100% correct program wasn't the goal here. :) EDIT: Actually fopen would return NULL when file is n…

> Not a big deal, because fully functional and 100% correct program wasn't the goal here

Wasn't it? It reminds me about the old article by Strostrup on c/c++ for beginners (I seem to link to this quite often, apologies if it gets repetitive):

https://www.drdobbs.com/learning-standard-c-as-a-new-languag...

One point of using c++ over c is that it should be easier to get a program that is in fact correct - regarding things like closing files etc. (that said conciously leaking some recources ("do and die") could be considered idiomatic c i suppose).

Re: A “Better C” Benchmark

#128

Post by megous » Sat, Mar 27, 2021, 5:04 PM UTC

yakubin wrote: post #59

maccard wrote: post #38

I think there is definitely merit in these kinds of posts. This developers measure of productivity is "how low level can I go" clearly; they declared zig was clear despite saying this: > The lack of string handling routines in the stdlib was unexpected, to concatenate strings one has to do everything manually - allocate the buffer, put strings there. Or use formatter and an allocator to print both strings side by sid…

> His dismissal of C++ as "not having a build system" seems like considering the language without the ecosystem. Using cmake and llvm solves all of his gripes on C++. Last week I debugged an issue in a big C++ codebase, where we were getting memory corruption. Source of the issue? Compiler, linker and build system being separate things and only compiler understanding types (also, lack of modules, which is another sym…

Linux kernel has a lot of these compile time optional struct members.

I think they avoid this issue by using a config header file that contains the defines, so the compilation unit either compiles with the config header, or if it's not included and config macro is used, compilation fails altogether.

It's still possible to include different config header than you're expecting, though. But that's easier to defend against. (you can just include a config header directly via cmd line without using #include in each compilation unit)

It's also better to use #if MACRO = 1 instead of #ifdef MACRO, because the first one will fail if MACRO is not defined.

Re: A “Better C” Benchmark

#129

Post by megous » Sat, Mar 27, 2021, 5:11 PM UTC

linkdd wrote: post #44

maccard wrote: post #38

I think there is definitely merit in these kinds of posts. This developers measure of productivity is "how low level can I go" clearly; they declared zig was clear despite saying this: > The lack of string handling routines in the stdlib was unexpected, to concatenate strings one has to do everything manually - allocate the buffer, put strings there. Or use formatter and an allocator to print both strings side by sid…

CMake, SCons, Autotools, Meson, Premake, to quote only them. They are build systems alright, but they miss the most crucial point: dependency managment. On the other side we have: - cargo for Rust - buck and buckaroo for C++ which seems nowhere near complete Am I missing something?

meson has subprojects. Try building gtk4. If you don't have some deps on the system, meson will download and build them as necessary.

Re: A “Better C” Benchmark

#130

Post by silisili » Sat, Mar 27, 2021, 5:20 PM UTC

simpleguitar wrote: post #124

drran wrote: post #33

Earlier quoted context omitted.

I have here program in Go and in Rust. They are very similar (Rust program is shorter), but Rust version is 5x faster than Go version.

I bet you are allocating/deallocating something in a loop. Give the Go profiler a whirl. I bet it will be pretty easy to remove, too. I have not run into a case where go can't be within 2x speed of C. And I love how zig is even closer to C, but has the ergonomics of go. What an amazing time to be alive.

That's what I was thinking.

When I was learning Go years ago, I decided to go through and speed up some of the Benchmark Game's Go code. Some were on the order of 20x speedup if I remember right.

Of course, the maintainer of the site rejected it because of what I perceive as a clear bias against the language, but the point is...it's easy to fix hotspots in Go.