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

Rust is now overall faster than C in benchmarks

benchmarksgame-team.pages.debian.net

Post reply on HN
Print view View original

331–340 of 445 posts

Re: Rust is now overall faster than C in benchmarks

#331

Post by josephg »

jstrong wrote: post #328
josephg wrote: post #211

Earlier quoted context omitted.

One of my long standing complaints about modern programming is how rarely people read code. We don't encourage it in school, and in the workplace most people only read code written by their coworkers. It would be the equivalent of teaching people to write books without encouraging them to read anything. To break myself of the habit I started reading some well regarded programs for fun. And oh boy, have I learned a lo…

do you have any recommended entry points for reading dovecot's code? I opened it up on github and it's a very large library! thanks for any help you can provide.

Nope not really! It is large, but you don't need to understand the big picture. Explore!

I'd either start at a query entry point, or find the email delivery path or something. Or skim through the files and see if anything catches your eye. Or invent a question for yourself - how does X work (for some X), and see if you can find that part of the code.

Wherever you start, explore around a bit then go deep. See if you can understand for yourself how some small, interesting part works (by tracing out the various structs and function calls). Understanding how the whole program fits together is a separate skill - but don't worry too much about it.

Personally I fell in love with the code in src/lib/memarea and mempool. The way dovecot handles memory pools is super clever. There's also lots of src/lib-X directories, and they're reasonably self contained if you want to skim that list and find something more focussed.

If you haven't read much code before and dovecot feels too big and scary, start with something smaller. I can also recommend reading the sourcecode for git or the code for redis. Oh, and if you do, do yourself a favour and checkout one of the earlier versions of those projects. The lines added early in a project's life are usually more succinct and important compared to lines added later on. So earlier versions are usually better reads. When I read redis, I think I read the code for redis 2.0 or something.

Re: Rust is now overall faster than C in benchmarks

#332

Post by pjmlp »

clappski wrote: post #330
pjmlp wrote: post #176

Earlier quoted context omitted.

Just a small, correction, you mean 90's style C++ GUI frameworks inheritance are no longer idiomatic in modern C++. Naturally we have to ignore that wxWidgets, Gtkmm, MFC, ATL, Qt, COM, DirectX, IO Kit, DriverKit, Skia are still around.

Probably fairer to say that the virtual inheritance architecture is idiomatic to GUI libraries rather than any particular language? You even mention GTKmm, a C++ wrapper around a C library that leverages inheritance.

I can also pull iostreams, CORBA, COM/DCOM and more recently UWP cards if you like.

Being around long enough, the meme writing Java in C++ just rubs me the wrong way for something that was already common several years before Gosling even thought of Oak.

As if C++, alongside Smalltalk, and all those enterprise object modelling methodologies and books, weren't to blame for the widespread of that way of programming.

When Java came into the scene, those C++ and Smalltalk developers (and enterprise architects) migrated to it, and kept doing what were already considered "best practices" by then.

Re: Rust is now overall faster than C in benchmarks

#333

Post by stabbles »

savant_penguin wrote: post #235

Wondering around the site I found this particular benchmark interesting https://benchmarksgame-team.pages.debian.net/benchmarksgame/... Why is julia using 250x the memory? (and it`s still fast)

It's including compilation time and memory too, which I would consider a major flaw in the benchmarks game.

If I wrap things in a function and run it a second time in the repl, this is what I get:

    $ JULIA_LLVM_ARGS="-unroll-threshold=500" ~/julia-b00e9f0bac/bin/julia -O3 --check-bounds=no

    julia> include("nbody.jl")
    run (generic function with 1 method)

    julia> @time run(50000000)
    -0.169075164
    -0.169059907
    2.044478 seconds (294.25 k allocations: 12.599 MiB, 8.89% compilation time)

    julia> @time run(50000000)
    -0.169075164
    -0.169059907
    1.867936 seconds (12 allocations: 1.750 KiB)
So, the second time there's no compilation overhead, just like in Rust, C, C++.

Re: Rust is now overall faster than C in benchmarks

#334

Post by fsloth »

FartyMcFarter wrote: post #147
fsloth wrote: post #126

Earlier quoted context omitted.

What does "idiomatic" C even mean? It's a high level assembler and as such should not limit the creativity of programmers using it. C code that pretends it does not need to care about it's platform is not idiomatic, it's just suboptimal.

By "idiomatic C" I meant any of the following: - Code that most C books/courses would teach you how to write - Portable C code (arguably portability is one of C's biggest successes!) - Code that you'd expect to find in the K&R book

"Portable" - yes. But will likely require the effort of porting due to platform specific sections.

Practically all non-trivial C codebases have platform specific segments. They can be either isolated to their own libraries or wrapped around tons of preprocessor switches.

C code is portable in the sense that it's not too much work to get a C compiler to work on a new hardware platform. On the other hand, compiling a large real-world C codebase on the said platform will probably require porting, and the effort may or may not be trivial.

Re: Rust is now overall faster than C in benchmarks

#335

Post by pjmlp »

typedef_union wrote: post #320
dan-robertson wrote: post #197

Earlier quoted context omitted.

The reason that C programs often perform well is that it’s so incredibly hard to do anything at all in C (especially something reliable) that one can usually only do the simplest thing possible and this typically means simple data structures, simple algorithms and arrays. In many ways, modern CPUs are particularly designed to run the machine code generated by C compilers on typical C code like this. Pointers and memo…

>The reason that C programs often don’t perform as well as an equivalent rust program[1] is that it’s so incredibly hard to do anything at all in C (especially something reliable) that one can usually only do the simplest thing possible and this typically means simple data structures, simple algorithms and arrays Reliability is very often the name of the game with C, and part of the reason you might see it written in…

The irony is that most C developers rebelled against Pascal and similar languages for being programming with a straitjacket, and in the end need to comply with MISRA-C and similar security enforcement regulations to ship anything worth using when human lives are at risk.

Re: Rust is now overall faster than C in benchmarks

#336

Post by [deleted] »

ryanianian wrote: post #116
mh7 wrote: post #104

Earlier quoted context omitted.

It's more to do with the fact that std::sort's definition is visible to the compiler and qsort() is not. Put qsort() code in stdlib.h, make it static and write a static intcmp() and you'll see the compiler inline that no problem.

Sure you can hard-code intcmp into qsort but then it would only work for arrays of ints. You could do some macro magic instead of templates e.g. `DEFINE_QSORT(int, intcmp)` which could stamp out `qsort_int` but that's not a part of the stdlib. C++ arguably gets this right since sort and sort will be separate functions, although templates are of course a footgun. And of course duping the logic for std::sort for a bunc…

[deleted]

Re: Rust is now overall faster than C in benchmarks

#337

Post by pjmlp »

throwaway894345 wrote: post #254
zucker42 wrote: post #247

Earlier quoted context omitted.

I don't think the value proposition of Rust over C#, Java, and Go is that it eliminates more errors. I think the advantage is it eliminates the same number of errors and performs better/has less overhead. I agree with your post generally though.

Lots of people argue that Rust improves correctness by way of sum types (including no implicit nil/null), affine types (addressing data races and so on), and (compared to Go) generics. I completely buy this argument.

Those data races are only addressed for in-memory accesses across threads.

If you are accessing data via some mechanism of IPC across processes, e.g. database access to same data rows without proper transactions, accessing shared files without locks, GPU memory data,.., affine types won't save you.

Re: Rust is now overall faster than C in benchmarks

#338

Post by steerablesafe »

mh7 wrote: post #104
martincmartin wrote: post #96

Earlier quoted context omitted.

Also lack of generics can make it slow, e.g. qsort() requires a function call for each comparison. So C++'s std::sort() can be significantly faster on an array of integers.

It's more to do with the fact that std::sort's definition is visible to the compiler and qsort() is not. Put qsort() code in stdlib.h, make it static and write a static intcmp() and you'll see the compiler inline that no problem.

I'm skeptical. I doubt that the whole of qsort gets inlined (it's big), and the best the compiler can do is to clone qsort to const-propagate the function pointer for it to get inlined.

In my similar experiments with std::sort with a function pointer only gcc does this with -O3.

Re: Rust is now overall faster than C in benchmarks

#339

Post by pjmlp »

steveklabnik wrote: post #73
arcticbull wrote: post #69

Earlier quoted context omitted.

I think you'd be hard pressed to find more than a handful of usual C programmers, even in embedded, who know what the __restrict keyword does, let alone are rigorous in its application.

I've always wondered if the reason why Rust keeps running into llvm bugs around restrict is that it is used so sparingly, and the semantics being unclear enough, that these codepaths just aren't exercised as often.

Besides the previous answer, it isn't supported by ISO C++ (although it does exist as extension), because the majority of the WG thinks it will go the same way as register and inline in the long run.

Re: Rust is now overall faster than C in benchmarks

#340

Post by ClumsyPilot »

fermienrico wrote: post #236
Matthias247 wrote: post #93

Apart from those benchmark games a lot of real world C is a lot less performant than people think it might be. I spent a fair amount of time reviewing C code in the last 5 years - and things that pop up in nearly every review are costly string operations. Linear counts due to the use of null terminated strings and extra allocations for substrings to attach null terminators, or just deep copies because ownership can’t…

Forgive me for asking a stupid question: what does it mean when something is “idiomatic” in a programming language context? Is it just the best or recommended way to do something? Or is it something that’s supported by the language? Or something else?

I was struggling with that too initially - replace the word with 'standard' or 'natural' and it retains the same meaning.
Post reply on HN