C

>>56546416
Because it's a SSD.

Because it does not have 200+ abstractions

>>56546416
Optimized x86_64 ASM code.

>>56546416
Because it's a middle level language.
and this >>56546437

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

>>56546584
But these things are true for Rust as well.

>>56546644
C wasn't written by Marxist faggots.

>>56546416
https://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.

>>56546416
>pointers

>>56546644
see
>>56546744

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

>>56546664
nah just a little bit

>>56546864
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.

>>56546416
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.

>>56546416
A is faster by at least factor 2...

The first Hello World written in C was about 5MB

>>56546416
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.

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

C is definitely low-level

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

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

>>56547276
What would assembly be then?

>>56547401
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.

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

>>56547437
>what is pypy

>>56547437
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).

File: bench-pipelined[1].png (87KB, 1556x924px) Image search: [Google]

87KB, 1556x924px

>>56546917
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 /g/ 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: https://aturon.github.io/blog/2016/08/11/futures/

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

>>56547571
Fair enough. I probably should have known it was just plain old /pol/ faggotry.

>>56547549
>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.

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

>>56546976
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

>>56547571

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

>>56547480
Not fast in non-FizzBuzz scenarios.

>>56547534
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.

>>56547621
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.

>>56547623
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.

>>56546416
C isn't fast.

Your cpu is.

>>56547675
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.

>>56547428
>>56547465
>>56547276
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
>>56547549
>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

>>56547571
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.

>>56547812
But my CPU is slow as shit.

>>56547621
>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.

>>56547534
>>56546983
>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.

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

>>56547534
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.

>>56547460
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.

>>56546744
Ownership is only checked at compile time

consider assembly

>>56546744
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.

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

>>56548299
>the ability to microoptimize is "cheating"
memes

>>56547691
>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.

>>56547691
>>56548447
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.

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

>>56547896
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.

>>56548528
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

>>56548427
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.

>>56548556
>no, your argument is
See >>56547401

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:
http://benchmarksgame.alioth.debian.org/u64q/program.php?test=spectralnorm&lang=rust&id=1
http://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.

>>56548600
That's what I've meant with >>56548299
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.

>>56548600
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”?

>>56546664
Yes it was.

>>56548628
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.

>>56548628
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.

>>56548623
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?

>>56548649
>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)

>>56546416

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?

>>56546416
>C gcc
Where is C clang?

>>56548710
Not tested

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

>>56548710
>>56548731
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.

>>56548649
>>56548676
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.

>>56548906
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.

>>56547465
>>56547276
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

>>56546911
>>56548641
Explain

>>56548583
oh i agree with you then

>>56548676
>no framework is going to beat hand-optimized code
i never compared GPUs to CPUs anon, 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.

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

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

>>56550094
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

>>56546416
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.

>>56548514
>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.

>>56548447
>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 >>56547896 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.

>>56551040
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.

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

>>56550555
>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.

>>56550010
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.

>>56550076
Safe and correct primarily, and fast only secondarily

>>56551040
>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.

>>56551238
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?

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

>>56549054
>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.

>>56551820
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.

File: enhanced-buzz-26895-1445458041-7.jpg (31KB, 540x360px) Image search: [Google]

31KB, 540x360px

>>56552071
>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?

>>56552508
Rust.

APL is faster

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

>>56552578
And that's it?

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

>Post yfw PHP is the fastest

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

>>56553157
not even the best at its own game

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

>>56552508
>Are speed, performance and memory efficiency really not important anymore?
no. computing power is cheaper than competent developers

>>56552071
>Where is the difference between creating an AI and reproducing
You know exactly what that means

>>56553346
You forgot regular refactoring and rewriting of badly made systems

>>56552508

There are many langauges, for example Go.

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

You have to put it into perspectice.

Modern langauges ARE fast, i.e. for most reasponable tasks Java takes about 2 times as long as C.

(Those numbers are complicated, because benchmarking is not a trivial thing, you can create benchmarks that make a langauge look good or bad, but you get the rough idea..)

Now while Java takes twice as long to run, the time you need to write a Java programm of a average complexity is dramatically shorter. Also you have better maintainability, reusability, more robustness, better frameworks and so on..

Bascially it boils down to this:
You pay the performance gain with a hefty price in devellopment time. So unless you are really willing to put much more time into the development, C just doesn't pay off.

In the end develloper time is expensive and computers are not. Unless you explicitly need every power you can get (visual libraries, operating system tier stuff) it just doesn't make sense to write code in C.

Of course I'm not talking about a small programm for scientific calculating. But even here most scientists rather write a python programm in one day that needs three days to finish than writing a programm in three days that needs one day to finish..

>>56552845
Or you can learn to program in APL like I did and save money

>>56553495
All I'm trying to point out is that it seems silly to dismiss brain-scale processing as impossible when we're literally capable of mass-producing human brains.

The technology is already there, and there's no physical limitation. Our brains are proof. We just have to gain the ability to develop and harness similar technology. (Think wetware)

File: Rust_BTFO.png (52KB, 575x615px) Image search: [Google]

52KB, 575x615px

>>56546416

Why is Rust so fucking slow?

File: Screen Shot 2016-09-11 at 23.12.57.png (238KB, 1904x3038px) Image search: [Google]

238KB, 1904x3038px

>>56554533
Because you are cheery-picking?

>>56547859
You don't get to call it "slow as shit" unless it can't outperform a Pentium III.

>>56554594
>losing to java
>ever
Fucking rustfags

>>56554594

>maximum_damage_control.jpg

>>56554821
>>56554861
>samefag

File: nope.png (27KB, 431x330px) Image search: [Google]

27KB, 431x330px

>>56554940

File: ddf91ebd16.png (103KB, 625x864px) Image search: [Google]

103KB, 625x864px

>>56555061

>>56555220

Wow, you got me..
There's only one guy who thinks Rust is shit.

Also I'd totally put a few minutes into fucking arround with GIMP to prove some random internet dude wrong.

Rustafarian faggot.

>>56555307
>Adding (You)s
>GIMP
Only Javafag would come up with such a stupid and inefficient way.

>>56551411
What? You really think you can escape memory management with C? I programmed and C# and even there you can't escape the stack even if you are not directly interacting with it.

>>56555623
Not him, but you don't really need to understand how stack works, except that it can overflow.
You just makes variables and they disappear after the end of block.

why is Go so fast?
https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=rust

>>56555699
but then, your code will probably the shittiest, most insecure code out there.

>>56557259
(the regex-dna code uses an external library which calls C code, because the standard Go lib doesn't support PCRE, apparently)

>>56548381
If you're going to use unsafe blocks you should just be using C.

>>56546416
Jesus christ Rust meme get btfo

>>56546416

Because years of compiler optmization senpai. Maturity is where it's at.

Oh, and because GC sucks ass for speed.

>>56547465
It's not. In C you can write to and read from any memory location that you can in assembly.

>>56546416
if C is so fast, why does nobody use it to serve webpages and then buy smaller servers to handle web load?

>>56558801
but everyone uses C to serve webpages. guess what apache is written in.

>>56548572
>Rust and C get really close without micro-optimizing, with Rust often beating C
[Citation needed]

>>56548676
> GPU is two orders of magnitufe more powerful than CPU.

The branch prediction in my i7 says otherwise...

>>56558849
php

>>56559360
wrong

>>56559360
you should stop doing crack

>>56557663
Not really. When you are writing a driver or map GPU memory to your virtual memory or just write library with algorithms that would run faster in unsafe Rust, you'll need to use unsafe blocks but it doesn't mean Rust is not suitable for it. You should wrap all the unsafe code and provide safe interface for the rest of the code that can be written in safe code. That's what standard library and FFI libraries do all the time.

>>56558632
>Rust
>GC
What.

>>56558801
Because faster servers are cheaper than competent C web programmer.

>>56558887
MISS

Flush your pipeline, anon.

>rust's comparison options has Java and go in the list
Pretty embarrassing tbqh

Because the people developing GCC care more about "make it fast" than following standards or ensuring portability. Fuck GCC and fuck the GCC devs. Even Clang isn't good enough, but GCC is worse.

>>56562577
It doesn't mean much.
C++ has java as well.
And Go is faster than C in mandelbrot.

>>56562599
In what way does gcc not follow standards? Which compiler is more portable than gcc?

>>56562748

Not him but.. gcc has a heap of GNU only extensions.

Try your code in CompCert. You'd be surprised how often throws up a big warning about GNUisms, even if it also works in clang.

>>56546416
Because it's the speed of light.

>>56562804
But then your code is not following standards, not the compiler. Gcc doesn't prevent you from writing compliant code, does it? It even shows you warnings if your code doesn't comply with whatever standard you're using.

>>56547428
assembly is pretty much bare metal.

you can do it in other languages, but you'll likely have a runtime layer between the hardware and you.

>>56546416
>what is SIMD
C fags confirmed for retarded

>>56562804
You can disable all GNU extensions you stupid fucking retard, fucking hell.
I use GCC and Clang and my code is 100% GNU free and will compile in any compiler adhering to the C11 or C++14 standard.
Please kill yourself, people like you who have no idea what they're talking about have no right to live.

>>56550094
>fuck no, you need to know nothing about the stack
biggest ? of the day

>>56563070
Just echoing, this is true, use the -std flag, eg -std=c11

>>56547276
C is high level because it's machine independent, end of story.

These terms have meanings you know, it's not "oh but from my perspective as a RoR/node.jds/angular.js dev it's so close to the metal X D"...

>>56555355
Yet java faster than rust?

>>56565522
Not in general.

>>56548514
>A human brain is technically nothing other than a sufficiently advanced computer.
How do you explain creativity and intuition?

>>56566255
>creativity
past experiences mixed with RNG
>intuition
acting on memories which have been corrupted or mis-retreived

>>56557663
>get a funky memory/stack corruption error with Rust unsafe blocks
>know exactly where the funky part is
>get a funky memory/stack corruption error with C
>lol it can be caused by anything anywhere

>>56549133
Freetard anything is Marxist by definition.

>>56565490
you literally just made up your own meaning for it on the spot you fucking idiot

>>56546416
- It's simple.
- It's one layer of abstraction above assembly language.
- C compilers have been optimized to death.

>>56547549
Kek even my toy compiler has an "intermediate representation" and I didn't take inspiration from anyone.

>>56546416
Because C is where your Windows is and that gets loaded into RAM so it's much faster to load than your Rust drive.

File: Screenshot_20160912-114958.png (92KB, 1080x1920px) Image search: [Google]

92KB, 1080x1920px

>>56546429
Ada is doing fine

>>56553157
Actually I'm pretty sure D has the fastest regex by a pretty big margin.

>>56567095
>If I ignore historical origin of terms people will think I' smart.

http://programmers.stackexchange.com/questions/267583/why-is-c-still-in-the-category-of-high-level-language

File: 1471970496705.png (466KB, 611x557px) Image search: [Google]

466KB, 611x557px

>>56546416
Because C doesn't try to pretend that it doesn't run on a piece of silicon with impurities added so that it approximates a finite state machine. x86 assembly is procedural, imperative, and damn near as far from my safespace programming as you can get. The further you get away from the architecture's language, the harder it is for the programmer and compiler to work together to make something that runs fast.

>>56569537
>historical origin
no, retard, it's called 'outdated terminology'

those fancy books of your were written decades ago, back when C truly was high-level compared to much of everything else on the market

times change, definitions change
stop being an idiot

>>56569867
It's not outdated if that's the day to day use that's appropriately used by everyone involved in the field.

File: webdev.jpg (60KB, 680x680px) Image search: [Google]

60KB, 680x680px

>>56569867

>back when C truly was high-level
So C has fewer abstractions today than decades ago?

>stop being an idiot

You tell him Karlie. Girls are coders too!!!

>>56570062
>>56570358
It's outdated because newer and even higher level languages are in use now you idiots. It's all relative. Maybe you should think once in a while insread of regurgitating the shit you read in a book 20 years ago..

>>56570621
>new cars are less like horse and carts than old cars
>therefor old cars are hore and carts
>because it's a relative quality

No you moron. C is lower level than most languages. It is still by definition a high level language. The cutoff point for high level never changed, just the upper limit

File: tweetfail.jpg (29KB, 640x555px) Image search: [Google]

29KB, 640x555px

>>56570621
>even higher level languages are in use now
So it's the that's not a knoife this is a knoife argument. Crikey, mate.

>you idiots
Oooh gurl u sho told him.

>>56570062
ah yes i'm sure a famous fizzbuzz professor like yourself is acquainted with everyone in the field and knows exactly what's up

>>56570358
fewer abstractions compared to modern higher level languages yeah

maybe it's time to move on, grandpa?

File: 1463723319065.png (230KB, 600x630px) Image search: [Google]

230KB, 600x630px

>>56571189
>modern higher level
It's funny how you've tried to subtly move to using higher. It's like your subconscious is trying to tell you that you're wrong but your coder girl I do it for the recognition ego won't let you admit it.

>>56571300
>semantics
>I have completely run out of arguments and rebuttals
nice
epic
I like it

>>56571348
>>semantics
The entire argument is literally semantics. Lol the mental gymnastics are intense

>>56571348
There's no need for an argument. You've already conceded the term you want is higher level when comparing two high level languages. It's nice to find someone that admits their mistake. Thanks for the ray of sunshine.

no, fortran is faster

File: matcheat_julia_benchmark.png (47KB, 704x435px) Image search: [Google]

47KB, 704x435px

>>56552508
Not really low-level but tries to have C-like speeds:

https://en.wikipedia.org/wiki/Julia_(programming_language)

I've contributed one file to this great shitpost material website. AMA.

>>56546416
Compilers

>>56569560
Well, most of the time this is true, but with a very high level language and a clever compiler, it can potentially compile your code to something very different to what your wrote which results in the same language.

Muh haskell meme