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

181–190 of 192 posts

Re: A “Better C” Benchmark

#181

Post by renox »

Too wrote: post #175
renox wrote: post #66

Earlier quoted context omitted.

Yep been there done that two months ago, took me two days (at least) to find the issue as a corruption which happen in -O3 but not in debug build which neither valgrind nor ASAN can find is pretty mysterious..

Unless you left out some details, this sounds more like plain UB and buggy c++ code manifesting itself with different symptoms depending on the O level. This has not as much to do with the loosely coupled build system complexity you have to scaffold in a c++ project, more issues in the core language itself.

I won't go into detail but this was related to macros and separated compilations: if you're not careful with macros, the 'same' object can have different size in different .cpp..

Re: A “Better C” Benchmark

#182

Post by tails4e »

himujjal wrote: post #69
tails4e wrote: post #42

Earlier quoted context omitted.

I'm curious about this. It seemed to be alot of 'work' just to get arguments. While I could read the code with no prior experience, there were enough unexpectedly verbos things in there that suggested it could take a considerable time to learn

No task is too easy. For easy, we need to jump down to Python. Even C is too easy to learn but difficult to write. Zig is kind of in between Go and Rust in terms of the learning curve. In terms of programming, it is in between C and Rust. But it is simple enough. The documentation as I said for the stdlib isnt that great right now as I said.

I found the cxx example very easy to read, which surprised me, it was not thst verbose. The D example another poster has in this thread was the easiest and cleanest IMHO.

Re: A “Better C” Benchmark

#183

Post by axaxs »

igouy wrote: post #179
silisili wrote: post #164

Earlier quoted context omitted.

Which repo? If it has a full history, perhaps I could find it? I have a link, but it's dead now... http://benchmarksgame.alioth.debian.org/u32/program.php?test... This was in 2013. My first submission was using memory pools for binary trees. It was rejected for using memory pools, even though the C version quite literally used mempool. I even redid it to use a 'third party' mempool library, rejected for the same reas…

https://salsa.debian.org/benchmarksgame-team/archive-alioth-... https://blog.golang.org/ismmkeynote

Thanks for the links, though I'm unsure what the second link is for.

I hope my assessment is 'fair.' I used to feel more strongly than I do now, I guess.

It's a weird situation. The rules say 'dont write your own memory pools', but new languages wouldn't have a popular library available. Seems it should be 'dont use them at all', or allow them for all. This puts any new language at an immediate disadvantage.

Anyhow, thanks for keeping it going so long. Fun little site.

Re: A “Better C” Benchmark

#184

Post by igouy »

axaxs wrote: post #183
igouy wrote: post #179

Earlier quoted context omitted.

https://salsa.debian.org/benchmarksgame-team/archive-alioth-... https://blog.golang.org/ismmkeynote

Thanks for the links, though I'm unsure what the second link is for. I hope my assessment is 'fair.' I used to feel more strongly than I do now, I guess. It's a weird situation. The rules say 'dont write your own memory pools', but new languages wouldn't have a popular library available. Seems it should be 'dont use them at all', or allow them for all. This puts any new language at an immediate disadvantage. Anyhow,…

In this case, the new language Go had GC available.

Re: A “Better C” Benchmark

#185

Post by axaxs »

igouy wrote: post #184
axaxs wrote: post #183

Earlier quoted context omitted.

Thanks for the links, though I'm unsure what the second link is for. I hope my assessment is 'fair.' I used to feel more strongly than I do now, I guess. It's a weird situation. The rules say 'dont write your own memory pools', but new languages wouldn't have a popular library available. Seems it should be 'dont use them at all', or allow them for all. This puts any new language at an immediate disadvantage. Anyhow,…

In this case, the new language Go had GC available.

C has malloc and free available, even when it was new.

Re: A “Better C” Benchmark

#186

Post by scoutt »

chousuke wrote: post #12
marvel_boy wrote: post #4

Simplicity wins. Always.

I dunno. One could say that C string handling is "simple" (it's just byte buffers!) or that manual loops are "simpler" than proper iterator abstractions, but those are both constructs that are hideously error-prone in practice. Perhaps it's the other way around and manual buffer management is actually the complex thing, since your application logic will have to involve a lot of code doing toil that isn't directly rel…

> it's just byte buffers!

At the end of the day, all things are.

Re: A “Better C” Benchmark

#187

Post by igouy »

axaxs wrote: post #185
igouy wrote: post #184

Earlier quoted context omitted.

In this case, the new language Go had GC available.

C has malloc and free available, even when it was new.

Non sequitur?

"Go was born out of frustration with existing languages … To meet these goals required addressing a number of linguistic issues: an expressive but lightweight type system; concurrency and garbage collection …"

https://golang.org/doc/faq#creating_a_new_language

https://golang.org/doc/faq#garbage_collection

Seems like you wished not to show one of Go's big features?

Re: A “Better C” Benchmark

#188

Post by bsdooby »

acka wrote: post #49
qart wrote: post #36

Earlier quoted context omitted.

In German, it would have been besser, not better.

It wasn't aiming for correct spelling, nor correct grammar for that matter. Rather, I think one can compare it to something like "Das Keyboard"[0]. [0] https://en.wikipedia.org/wiki/Das_Keyboard

Uber C ;)

Re: A “Better C” Benchmark

#189

Post by simpleguitar »

igouy wrote: post #187
axaxs wrote: post #185

Earlier quoted context omitted.

C has malloc and free available, even when it was new.

Non sequitur? "Go was born out of frustration with existing languages … To meet these goals required addressing a number of linguistic issues: an expressive but lightweight type system; concurrency and garbage collection …" https://golang.org/doc/faq#creating_a_new_language https://golang.org/doc/faq#garbage_collection Seems like you wished not to show one of Go's big features?

Why can't GC coexist with memory pools? They both have good uses.

It's pretty clear that Go designers wanted a GC, but also wanted control over memory. In go, it is trivial to create a slice of structs that's contiguous in memory, and built-ins like 'copy' means the language designers wanted users to use this feature.

When I write go, GC is used almost always. Except when it becomes a bottleneck, at which point I trivially switch to memory pools. I just add a comment like "preallocate to avoid allocating in a loop", and move on. The next person that comes by my code would have no trouble understanding what happened there--unlike Java where using memory pools stops looking like Java.

I think when the Go FAQ mentions existing pain points, it means both GC'ed and Non-GC'ed languages.

Zig is cool because it went the manual layout route, but with a pluggable allocator. I think it's a brilliant choice, especially for embedded.

Re: A “Better C” Benchmark

#190

Post by dang »

justAnIdea wrote: post #32

> With no previous experience I opened vim and started coding. That is where i stopped reading. If you're not using an IDE in 2021, you're not working on serious software/big codebases/commercial projects and what you have to say is not something I'm interested in, ESPECIALLY when talking about UX of programming! VIM, oh please... time to have a nap, grandpa.

We've banned this account for repeatedly violating the site guidelines. Please don't create accounts to do that with. It's not what this site is for.

If you want to read https://news.ycombinator.com/newsguidelines.html and commit to using HN as intended, you're welcome to email hn@ycombinator.com and we'll be happy to unban you. Otherwise not.

Post reply on HN