Wondering why D was not considered. D is probably the better C I've come across.
A “Better C” Benchmark
161–170 of 192 posts
Re: A “Better C” Benchmark
#162Earlier quoted context omitted.
There is conan or vcpkg. I do wish crates.io and julia would make it easier to develop on non internet machines. The ease of dependency management has bred staggeringly deep dependency trees for rust and julia. If I could run a cargo command to get a human readable dependency list that I could then go to an internet facing machine and run a cargo command to put into a tgz to drag back over that would be helpful. Is t…
A list of dependencies: https://doc.rust-lang.org/cargo/commands/cargo-tree.html Download all dependencies locally: https://doc.rust-lang.org/cargo/commands/cargo-vendor.html
I think maybe I don't understand vendor. I thought you had to have your project on the internet facing machine to vendor its dependencies. Which I cannot do.
Re: A “Better C” Benchmark
#163Earlier 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.
Can you link to the bitbucket pull requests?
Re: A “Better C” Benchmark
#164Earlier quoted context omitted.
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.
Can you link to the bitbucket pull requests?
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 reason.
I didn't even bother submitting any others.
Re: A “Better C” Benchmark
#165Earlier quoted context omitted.
>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…
>I'm not sure what you mean by that. Are you saying you can use #ifdef, #include etc. in Haskell code?
Yep: https://guide.aelve.com/haskell/cpp-vww0qd72.
>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.
I agree, I don't think C++ is especially bad in this regard. If people are going to write bad code, they can write it just as well in Java, C#, Python etc., they'll just use different language features to bring about the horrors. No language (apart from maybe Go, in its extreme simplicity) can save us from having to debug bad code.
Re: A “Better C” Benchmark
#166Earlier 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.
Yep, ‘-O2 or above’ we used to compile our UTs without optimizations because otherwise it takes too long, but now we have an additional(less frequent) CI job for UT with optimizations to benefit from these improved error detection.
Re: A “Better C” Benchmark
#167Earlier quoted context omitted.
> 1: At work a frequent issue in C++ is UAF a pointer to a stack variable which outlives the function, Zig don't help you here.. Sorry but if this sort of UAF is actually frequent, I would hazard a guess that your coworkers would struggle in pretty much any language? RAII-based lifetime management really isn't that difficult, and the type of bug you are referring to isn't even subtle.
I agree and don't understand why this would be controversial. There are plenty of aspects of programming that need systematic solutions instead of just telling people to get better, but returning pointers to the stack should not be high on that list. If people are doing that, it means they don't understand what they are doing or aren't thinking about what they are writing, probably both. It is much easier to return r…
It doesn’t happen very often but each time there was a new developer on the team they made such mistake, that’s a way to teach them about valgrind (what a wonderful software!) I guess.
We work in a ‘low latency’ domain where heap allocation is avoided, this may explain that it happens more often to us.
Re: A “Better C” Benchmark
#168Earlier quoted context omitted.
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.…
>In other languages you have exceptions, polymorphism, implicit constructors, destructors (and their order in case of inheritance, templates, etc.
Of these, Rust has only destructors :)
Re: A “Better C” Benchmark
#169Earlier quoted context omitted.
I agree with you. I am doing a lot of coding in Go for my multiplatform home projects and C/C++ at work 8 hours per day. Go brings faster results due to the really great and easy to integrate 3rd party libraries. There is literally no way that I would go for such a large number of third party dependencies with any C++ software - it is just too much work to prepare the libraries for use. The amount of thinking to make…
Are you actually using new and delete outside your own data structures? I have barely used new or delete for years, I don't even use them when building data structures - the vast majority of the time I make compound data structures out of what is in the standard library. It is only when memory layout needs to be very specific that I use new and even then it is placement new.
You don't need to use delete explicitly to control the lifetime of objects in C++. A properly placed "}" or a call to something like .release() can be just as effective. The problem is, there is simply no way to do it in a GC language.
Re: A “Better C” Benchmark
#170Earlier quoted context omitted.
How about 50 years old whiskey in a cask?
Difficult to keep it from just being super oaky at that age, but a great distiller willing to throw away a lot of bad casks can make something amazing. Macallan sold some 72 year old scotch in 2018: https://www.foodandwine.com/news/macallan-scotch-72-year-old...
Or just use very tired casks for most of that 50 years.