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

A “Better C” Benchmark

zserge.com

Post reply on HN
Print view View original

141–150 of 192 posts

Re: A “Better C” Benchmark

#141

Post by yakubin »

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…

> Haskell has the C preprocessor

I'm not sure what you mean by that. Are you saying you can use #ifdef, #include etc. in Haskell code?

> No offense but this just sounds like bad design.

I agree. However that's just one way you get multiple definitions for the same struct. I think a language should detect such an error. It will detect it for functions. If linkers did not detect multiple function definitions, would you shrug it off by saying "having multiple function definitions is bad design"? (I'm asking in a non-accusatory way. I'm not sure how to word the question more gently.)

Many of us don't have the luxury of choosing the quality of code we're employed to debug. It would be nice if languages had some rudimentary sanity-checks to, well, preserve our sanity.

Re: A “Better C” Benchmark

#142

Post by audunw »

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…

It's a bit early to say what Zig does and doesn't do. Memory safety aspects is still under development, and there seems to be a lot of focus on making it safer. But it might be a model where you focus on detecting errors in debug/safe-builds during development, but release fast builds using less safe code generation and allocators.

Zig will probably never be as safe as a GCed language or Rust in this regard. But that's because it would go against other core design goals.

I feel like the future of non-GC languages is Zig as better C (dead simple and explicit language), and Rust as better C++ (complex language with more memory management facilities, etc).

The choice of languages was a bit odd. But I think Go is still in C's territory when it comes to being simple and explicit. Memory management (GC/not-GC) isn't necessarily the most important distinction in programming languages.

Re: A “Better C” Benchmark

#143

Post by WalterBright »

mlyle wrote: post #126
scatters wrote: post #71

Earlier quoted context omitted.

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

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

Here's an example of a much more complex case that is detected:

https://issues.dlang.org/show_bug.cgi?id=21745

Re: A “Better C” Benchmark

#144

Post by lew89 »

Ar-Curunir wrote: post #81
lew89 wrote: post #73

Earlier quoted context omitted.

Everything is matter of price. Such an error is nobrainer actually, because just before I get an error message. If I don't know that yet, I run on gdb and everything's clear. Couple of seconds. How manyof them I have to do to ballance learning a new language(and I'm not sure if I like it eventually)? If I was a system software developer, that would probably be a good choice. I program mostly in high level languages,…

Maybe it doesn’t matter for small programs, but probably in large programs tracing the control flow would be non trivial, so, as the parent said, over the lifetime of the program it would add up

Is there any language that can save you from control tracing problem? I think that well made architecture is only solution. In fact I would say that C is easier in that respect (if you don't use goto), because all control flow is explicit. In other languages you have exceptions, polymorphism, implicit constructors, destructors (and their order in case of inheritance, templates, etc.

C is dead simple in that respect. If you can't write right concise code no language can help you. However of course, as C is more verbose it is more challanging to structure code well. And to some extend other language can help you move the point where control flow becomes a problem.

The biggest problem in C programming for me is memory management, but maybe it's just a lack of experience. Certainly C++ is convenient with smart pointers and automaticall called destructors.

Anyway, i didn't consider big project a scope here. I wouldn't write realy big programs in wine. I would try to create as small independent parts as possible.

Re: A “Better C” Benchmark

#145

Post by antirez »

ginko wrote: post #136
antirez wrote: post #18

50 years is not a good age for a bottle of wine. There are wines that are still enjoyable after such long time, but will hardly express the same potential they had at the peak of their maturity. Many other bottles will be already totally gone after 50 years.

A sauternes or tokaji is just about in its prime at that age.

Both are special wines, indeed.

Re: A “Better C” Benchmark

#146

Post by lew89 »

e12e wrote: post #127
lew89 wrote: post #58

Earlier quoted context omitted.

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 th…

Yes, I consider that memory management is the biggest problem with C. Always the question is what is more valueable to you: simplicity or memory management.

Re: A “Better C” Benchmark

#147

Post by lew89 »

Matumio wrote: post #138
lew89 wrote: post #73

Earlier quoted context omitted.

Everything is matter of price. Such an error is nobrainer actually, because just before I get an error message. If I don't know that yet, I run on gdb and everything's clear. Couple of seconds. How manyof them I have to do to ballance learning a new language(and I'm not sure if I like it eventually)? If I was a system software developer, that would probably be a good choice. I program mostly in high level languages,…

It's trivial to fix if you catch it early, and perfectly fine for a tool you run yourself. However if the problem is discovered two years later in production, there will be a forth-and-back until you get at the correct error message, possibly downtime, and if there isn't one you'll be instructing them how to install debug symbols for libX.

This is a very good point. Good testing, good programming practices, good logs are necessary. And it's not only about C. It's not so hard to do better than in Java. xD

Re: A “Better C” Benchmark

#148

Post by drran »

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.

Yep, Go program does allocating/deallocating in the loop, while the equivalent Rust program does not. Moreover, Rust program compiled with O3, LTO, and PGO. Go version: 75 us, Rust: 15 us.

Re: A “Better C” Benchmark

#149

Post by drran »

silisili wrote: post #130
simpleguitar wrote: post #124

Earlier quoted context omitted.

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.

My contributions to Benchmark Game for Rust are accepted. ;-)

Re: A “Better C” Benchmark

#150

Post by tialaramex »

audunw wrote: post #142
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…

It's a bit early to say what Zig does and doesn't do. Memory safety aspects is still under development, and there seems to be a lot of focus on making it safer. But it might be a model where you focus on detecting errors in debug/safe-builds during development, but release fast builds using less safe code generation and allocators. Zig will probably never be as safe as a GCed language or Rust in this regard. But that…

What would "simple and explicit" even mean if somehow it includes "Oh, sometimes, maybe, I'll incur the expense of garbage collection in the middle of this other algorithm running and it'll take much longer than usual" ?

I don't care about that in a Python program, but I can't see why I would accept it from something that's supposed to replace C.

I also think you're imagining a lot of hard work during execution in Rust that just isn't there, most of the tricky stuff happens at compile time. If you can prove you really don't need the safety that does have runtime implications, you can choose not to have it, but of course you probably don't have proof, just the same gut instinct that usually gets us into trouble in other languages.

Post reply on HN