C

Why is C so fucking fast?

Other urls found in this thread:

news.ycombinator.com/item?id=11878881
aturon.github.io/blog/2016/08/11/futures/
benchmarksgame.alioth.debian.org/u64q/program.php?test=spectralnorm&lang=rust&id=1
benchmarksgame.alioth.debian.org/u64q/program.php?test=spectralnorm&lang=gcc&id=4
benchmarksgame.alioth.debian.org/u64q/performance.php?test=regexdna
techempower.com/benchmarks/#section=data-r12&hw=peak&test=fortune
twitter.com/NSFWRedditGif

Because it's a SSD.

Because it does not have 200+ abstractions

Optimized x86_64 ASM code.

Because it's a middle level language.
and this The ASM code is even mostly readable, back in school the teacher used to show us how C code could be turned into ASM and flashed into mips

>compiles to native code
>no GC of any kind

this is basically it

But these things are true for Rust as well.

C wasn't written by Marxist faggots.

news.ycombinator.com/item?id=11878881

Not only GCC is much more mature than the rust compiler, but C is a langage that tries to abstract as little as possible how the machine works. No weird shit with variable ownership, no forced bound checks, and I don't know what else this cuck lang is used for.

>pointers

see
rustc has a harder job, there is no reason why it cant be as fast as c once it gets more mature

nah just a little bit

My point was that as long as the runtime requires it to do more things than C would have done, relying instead on the programmer to not fuck up, then Rust can't possibly be faster than C.

The only way Rust can be faster than C would be having features that can't be easily reproduced in C. Static polymorphism, for example.

C is as close to machine code as you can get, while still being portable.

There's a reason it's been alive for 40 years.

C has had billions upon billions of dollars spent on it. If you look at the tools and compilers, they are fantastically well optimised. The same is true for FORTRAN, it's had so long to mature.

A is faster by at least factor 2...

The first Hello World written in C was about 5MB

Because the program was optimized better?

Languages aren't faster or slower, that's a property of your implementation and your program.

In the case of low-level languages like C and rust, mostly your program.

>Because it's a middle level language.
nah, that's Java and C#

C is definitely low-level

Not really true.
Python, Ruby or JS will never be acceptable fast.

The language makes it hard to write an efficient implementation, but that doesn't mean it's impossible in principle.

What would assembly be then?

It's impossible, though.
You can not get the semantics of Python fast.

C has been around for almost 50 years. Over that time, its minimalist design has not changed very much, but it's been used in so many large projects from operating systems to libraries for everything from crypto to graphics to compression, and even interpreters for most other languages, that for the longest time, it's pretty much been the single most important language to optimize. So with the right motivation, there's been a lot of work put into optimizing C compilers. It somewhat helps that most of the world revolves around one particular C compiler, which is GCC. Outside of the Windows environment, it's pretty much been a de-facto standard (and it still get some use in Windows because MSVC can't into newer standards), and it is only recently that it is being challenged by Clang, which is right now playing catch up. In fact the only viable contender to GCC is the Intel C Compiler, but only on Intel systems, because Intel has access to undocumented information that could be used for performance tuning to a specific Intel processor.

By the way, it's worth noting that the Rust compiler uses the same backend as Clang (LLVM), so when Clang finally catches up to GCC, you might see a little performance improvement in Rust as well.

>C is definitely low-level
But that's wrong.

>what is pypy

Python is an abstract language. It has nothing to do with hardware. If you write a compiler that translates the meaning of your program from python into assembly, you can make it as fast as you want. The only barrier is the ability for the compiler to understand your code (rather than just treating it literally, line-by-line)

I didn't say it was easy, I said it was possible. Like supercompilation/superoptimization for C. It's just not feasible/tractable (yet).

All of Rust's features (Borrow-checker, GC, type inference, etc) happen at compile time, not run time.

The reason Rust is slower than C, is because rust code is first compiled to intermediate code which is then compiled down to machine code. Both of these compilation steps are not optimized very well (yet) as such the resulting machine code is not perfectly optimized as well.

What's more, Rust's standard library is included fully in every rust program, even if only a little of it is used. This adds a fair bit of bloat and overhead.

I don't really understand why Sup Forums hates Rust so much, it's built on some really cool concepts and some of the stuff they come out with looks really promising, such as: aturon.github.io/blog/2016/08/11/futures/

>I don't really understand why Sup Forums hates Rust so much
It doesn't, you're just witnessing a vocal Sup Forums minority that hates SJWS enough to bash an entire language just because some SJWs use it.

Fair enough. I probably should have known it was just plain old Sup Forums faggotry.

>compile time GC

Sure.

>the resulting machine code is not perfectly optimized as well

Don't take my word for it, but I'm pretty sure C code compiled by clang/llvm is still faster than Rust code compiled by LLVM.

>wahh wahhh muh pol boogeyman
How many decades have we been through these hype cycles for faggy toy languages again?

I wonder how many computers had 5MB of storage when the first Hello World program was written. Wonder if there was a single computer with 5MB of RAM total even

You're literally the first one in this thread to mention SJWs.
Calling someone a Sup Forums user is the new reductio ad hitlerum.

Not fast in non-FizzBuzz scenarios.

Wrong. The semantics of Python dictate that you have to move around stuff in memory quite a lot.
Some can be optimized by JIT compilation, but even that book keeping and background work has its price.

That can't be made fast on a normal computer.
And computers won't get fast enough that it makes the cost of JIT optimization for a language that needs it that much completely irrelevant. Not in a long shot.

>barrier is the ability for the compiler to understand your code (rather than just treating it literally, line-by-line)
The semantics of Python don't leave enough clues for heuristics like this. PyPy adds hints, though that isn't Python anymore.

You're right, Rust doesn't have a real GC. Instead, it uses lifetimes and scopes to identify when used memory can be freed up.

>Don't take my word for it, but I'm pretty sure C code compiled by clang/llvm is still faster than Rust code compiled by LLVM.

Well, I'm certainly no expert either, but I believe if you strip out the std library and some additional features, I think you can get really close to C performance. However, when you get to that point you're basically writing C with a different syntax.

I'm curious, have you spent any significant amount of time learning/working with rust? Once you get over the learning curve, it's really quite awesome.

C isn't fast.

Your cpu is.

You don't need to explicitly mention it for your post to be motivated by it.
>You're literally the first one
is a disingenuous argument that tries to shift the problem to whoever mentioned it.

low and high-level is certainly a matter of perspective, Python/Perl/Matlab/APL programmers might call java a low-level language, while assembly programmers might call C a high-level language
>rust code is first compiled to intermediate code which is then compiled down to machine code. Both of these compilation...
every relevant compiler does this, youcould have just said that the rust compiler isn't that great yet

no, people just hype it up too much and claim it's the next big thing. people said that java would be #1 for desktop applications as well, now look where it is. It's certainly successful(widely used in big server clusters), but it's not the uncontested #1 language that revolutionized programming that it was hyped up to be. And no, Rust won't replace C.

But my CPU is slow as shit.

>Don't take my word for it, but I'm pretty sure C code compiled by clang/llvm is still faster than Rust code compiled by LLVM.

That's because you can't feed LLVM arbitrary IR and expect the result to be fast.

>The only barrier is the ability for the compiler to understand your code
yes, and some languages make this very hard, which in turn means programs written in it will be slower. So yes, in practice Languages are fast or slow. Arguments that only work in theory are worthless.

>So yes, in practice Languages are fast or slow. Arguments that only work in theory are worthless.
/thread

If you argue on that level, you might just as well say that it doesn't matter which language you use as long as they are turing complete or some shit like that.

This.

GCC is much more mature than LLVM. That's also the reason why Clang isn't as fast as GCC yet, because Clang uses LLVM. Clang is catching up though, and so is Rust.

Ownership is only checked at compile time

consider assembly

The goal with Rust is to try and abstract as much as you can, to give the compiler as much space as possible for optimizations. And it works pretty well. The problem is that LLVM isn't very mature yet, so it often misses possible optimizations, like vectorization. Bound checks are a good thing by the way, and for most things where you know for sure that the input will be valid there are often better ways of doing it, like iterators.
Benchmarks are kind of cheating with C by the way. When you usually write code, you don't try to optimize every single line. With benchmarks there are dozens of people micro-optimizing things for the smallest performance increases. With Rust you get a lot of performance without a lot of effort, but it's harder to micro-optimize because of the abstractions that LLVM usually does really well.

Rust has references, which are like safe pointers. You can also use raw pointers in `unsafe` blocks

>the ability to microoptimize is "cheating"
memes

>Wrong. The semantics of Python dictate that you have to move around stuff in memory quite a lot.
No it does not. No language imposes implementation details. They might have operational semantics, but those merely semantics on a conceptual machine model. There's no reason you couldn't implement it entirely differently, as long as the calculated result is the same.

For example, if the standard requires that adding two integers requires checking for overflow, but the compiler can infer based on the context that these integers can't possibly overflow, then the compiler is free to omit any code for performing the actual check.

The main reason why efficient C compilers are much easier to write than efficient compilers for any other language is because C has so much undefined behavior, which allows the compiler to skip hard problems like that and just assume it's the programmer's responsibility to avoid e.g. integer overflow.

Anyway, integer overflow is just a trivial example. You can apply a semantically equivalent code transformation to any part of a python program.

Let me drive home the point some more:

A human brain is technically nothing other than a sufficiently advanced computer. If you give a sufficiently advanced programmer an arbitrary python program + enough time and money, they will be able to produce efficient C source code that computes the exact same result as the python program you presented.

In other words, the program running on this programmer's brain has cross-compiled python to optimized C, thus demonstrating that efficient python compilation by a machine is possible.

Now, in principle you could imagine a futuristic supercomputer simulating an entire fleet of human programmer brains, each trained to do nothing other than translate python to C, and apply it to any given python program to produce an optimized C equivalent.

It's possible in principle, even though it may not be tractable/feasible at the current point in time. But of course, this is an extreme example. Normally you'd expect us to develop more traditional supercomputation first, i.e. algorithms to recognize entire code patterns (like: “this is a loop that goes through an array and does XYZ”) and translating that business logic into optimized assembly.

There's nothing in the python specification that requires a python interpreter to be slow.

That's an excellent point, and it's completely true.

So we agree? Languages are not slower or faster, they just make it harder or easier to be fast, which is exactly the point I was trying to make.

no, your argument is "if the compilers were perfect then every language would be the same speed" which is obviously not the case. Languages, in practice, ARE fast or slow

Not exactly. It's just that 99% of the time you won't, and that Rust and C get really close without micro-optimizing, with Rust often beating C. Sometimes there's no difference between C and Rust's running times, though, because the LLVM is able to optimize very well in some cases.

>no, your argument is
See We clearly agree on the first part (“the language makes it hard to write an efficient implementation”), so if we disagree then it must be about the second part (“that doesn't mean it's impossible in princple”).

In other words, you are trying to suggest that it's impossible even in principle/theory, which I am trying to disprove here.

Also, looking at the source code:
benchmarksgame.alioth.debian.org/u64q/program.php?test=spectralnorm&lang=rust&id=1
benchmarksgame.alioth.debian.org/u64q/program.php?test=spectralnorm&lang=gcc&id=4

Apart from what was said already, the most import difference in the benchmark between Rust and C is that the C implementation explicitly uses SIMD instructions while the Rust version relies on LLVM to do that.

>// As std::simd::f64x2 etc. are unstable, we provide a similar interface,
>// expecting llvm to autovectorize its usage.

That's what I've meant with You can get very fast code by using Rust and not thinking about optimizations, while it's very hard to micro-optimize with Rust because of Rust's abstractions. In most real-world scenarios, people wouldn't spend that much time micro-optimizing C and then Rust would probably be faster.

More importantly, if you need this degree of SIMD why not just use OpenCL, CUDA or Compute Shaders and get even more performance than you ever will out of these shitty “benchmarks”?

Yes it was.

no framework is going to beat hand-optimized code. However assembly language GPU programming isn't really a field so you're more or less required to use a higher-level language for those.

You wouldn't do this in the real world, this is just done by NEET's to convince themselves that C is better than Rust.

In the real world, people will write code that needs to be this heavily micro-optimized in assembly, and then link to it from C or whatever high level language they want to use.

Even using C with SIMD intrinsics gives you no guarantee about what the compiler will be doing - writing it in raw assembly gives you full control over register allocation, tight inner loops, etc.

Also, in the real world, people, especially C programmers, will generally deliberately choose slower but easier-to-understand code over faster but obscure code unless it's _absolutely_ required.

The only libraries I can think of that actually have optimized tight inner loops for performance is stuff like FFmpeg or FFTW that presents serious bottlenecks in major applications (like video transcoding). Most code will be written to be safe and correct primarily, and correct only secondarily.

So the question should not be: How fast can I write code in this language? But: How fast can I write *safe and correct* code in this language?

>no framework is going to beat hand-optimized code
That's bullshit and you know it. Throw your heavy SIMD app on the GPU and you'll get two orders of magnitude out of it compared to even the best hand-optimized assembly.

Arguing that you shouldn't use OpenCL/CUDA/whatever because you can't hand-optimize the code for it on an assembly level is completely nonsensical, because you're forgetting the fact that the GPU is two orders of magnitude more powerful than the CPU.

(Also, you could use SPIR-V if you want lower-level access to the GPU)

Why do you want to persist in causing billions of dollars worth of damages a year to save a couple of cents in silicon and watt-hours?

>C gcc
Where is C clang?

Not tested

Not tested, but I'm guessing it would be more or less the same as Rust, because they both use the LLVM.

As if gcc vs clang matters when the “benchmark” program is entirely hand-written assembly anyway.

These benchmarks are so stupid. It's a measure of who can spend the most time micro-optimizing, and which languages allow you to embed assembly or not. Utterly pointless.

It doesn't really matter if you use (inline) assembly or just spend a while to try to trick the compiler in to generating the instructions you want.

What matters is that you look at how the hardware is utilized and try to optimize for that, and that's very much possible on the GPU to a great extend.

What matters much more than that is that you use the right tool for the right job, which for SIMD is definitely the GPU.

The GPU is essentially almost entirely a giant SIMD coprocessor.

C is basically assembler with another syntax, so it is very much low level

stop pretending to be smart or retarded, don't know which one you are after

Explain

oh i agree with you then

>no framework is going to beat hand-optimized code
i never compared GPUs to CPUs user, all i said was that hand-optimized assembly is faster than generated code. For CPUs writing assembly isn't too uncommon, but for GPUs this is rare, Nvidia has some librarys parts of which might be implemented in (GPU) assembly.
I didn't suggest that this makes GPUs somehow worse either, All i'm saying ist that given some hardware, hand-optimized assembly will be faster than generated code on said piece of hardware.

>safe and correct primarily, and correct only secondarily.
...safe and fast?

>C is basically assembler with another syntax
fuck no, you need to know nothing about the stack, calling conventions, registers etc. for C

if you have literally no idea about what the stack is have fun programming C

calling a function is nothing different than jumping to a subroutine

C, C++ and Rust are the same when it comes to performance. Small differences are just results of compilators optimalizing code differently.
However this much of a gap as in your picture have to be caused by rust program using worse algorithm or being compiled with with debug target.
I'll check the code when I get access to my PC.

>A human brain is technically nothing other than a sufficiently advanced computer.
Human-like hard AI fag spotted. It's a technically advanced FPGA at best.

>In other words, the program running on this programmer's brain has cross-compiled python to optimized C, thus demonstrating that efficient python compilation by a machine is possible.

No, it's not. Because unlike the programmer the compiler will never know the full intention behind a software.

>the compiler can infer all kinds of shit
No, it can't. In reality, that would require hard AI which will never happen.

Therefore it's not possible and applies, because such thinking is harmful because it leads plebs to write their crap in Python thinking noteworthy speedups are possible.

Let me just take this as another occasion to mock hard, human AI fags. You'll never claim some AI waifu.

Not him but the simplest example is JavaScript. The compiler/interpreter will always use slower, float operations on your variables because there is no way it can know the `count ` variable is always an integer. This fundamentally limits performance.

so? you can program C without any of those
why would you need to know about the stack?

>calling a function is nothing different than jumping to a subroutine
it certainly is, you need to handle parameter passing etc. yourself rather than have the compiler automatically do it for you. You can program C without touching calling conventions or learning about them.

Then why the fuck did you quote me if my only point was that the GPU was faster than the CPU?

Thanks for wasting my time I guess.

Safe and correct primarily, and fast only secondarily

>No, it can't. In reality, that would require hard AI which will never happen.
We've built billions of computers with human-like intelligence. Ergo, you're wrong.

You know that there are compilers which can track a variable's possible value ranges (as sets) throughout its lifetime, right? What says you can't apply the same sort of static analysis to JavaShit variables to find out that it's always only ever used with integer operations, and therefore optimize it down to an integer instead of a float?

>We've built billions of computers with human-like intelligence.
we haven't though
we haven't even build one yet

>C is basically assembler with another syntax, so it is very much low level
This is not true at all, this myth is a holdover from the 80s and early 90s when personal computer operating systems did not do mult-tasking and pretty much gave programs full control of the computer and direct hardware access. This is the reason that C took over is that programmers had direct hardware access and needed a language with weak typing and that could do bit twiddling. C is not a lower level language, its just easier to port because its type system allows you to do anything. The fact that LLVM uses a virtual machine to optimize is proof that C benefits from high level optimizations like any other language.

So what about the billions of human brains we've quite literally manufactured over the past few decades?

Is it less of a computer because the manufacturing process is biological instead of technological? Where is the difference between creating an AI and reproducing, apart from the fact that the latter is less flexible due to the designs being hardwired?

If you want to create AI, you already have all of the hardware necessary. You just need to know how to use it properly. The first step in succesful AI engineering will be modifying the human DNA to produce more purpose-fit machines; or perhaps finding ways to interface more directly with the brain so we can give birth to brains in a jar and feed them whatever stimulus you want.

You have all the manufacturing equipment for human-scale neural networks already.

>billions of human brains
>literally manufactured

>AI engineering
>modifying the human DNA

Do modern lower-level languages like C even exist?

It seems everyone's jumped onto the bytecode/interpreted train without looking back

Are speed, performance and memory efficiency really not important anymore?

Rust.

APL is faster

if you can afford an APL keyboard and a programmer fluent in an esotheric programming language then you can afford a faster server too.

And that's it?

C++ too, but that's pretty much it.

>Post yfw PHP is the fastest

benchmarksgame.alioth.debian.org/u64q/performance.php?test=regexdna

not even the best at its own game

techempower.com/benchmarks/#section=data-r12&hw=peak&test=fortune