Will Rust allow speeds 10x times that of C?

>inb4 malloc() meme

Attached: 1523153988655.jpg (945x1279, 364K)

C reigns supreme

Rust has the potential to be just as fast as C.

SoA and vectorization can
lock-less concurrency can
cache misses optimizations can

those are more of a sw architecture/design

language can help your performance with good compile-time code generation and semantics that help to write naive code in a way that it follows the data-oriented design in flexible way without fighting the language and unnecessary boilerplate

As for C, it gets easily beaten by code generation. Ofc you can do anything in C, but you have to do it by yourself and it can be annoying to write and hard to rewrite to change in comparison to language feature. C culture has some processors to at least compete, but then you have bazillion files that need to be preprocessed by different tools in your project. Quality of life starts to drop down.

...behind every single overflo

That's not what's important because it applies to most languages. The fact that the language attempts to have features that don't obstruct performance is what's important.

Haskell is a better demonstration of the potential for high level language performance. It's not there yet but how little definition for execution it has (being pure mostly) it allows for some amazing things.

C isn't unpleasant to write in. Try modern alternatives like C++.
Rust is a competitor to C++ on the ease of use front. Not C. C is too simple to compete with like that.

Idk about 10x but rust doesn't have pointer aliasing problems so i think it can be better than C, restrict is a really dangerous hack

looked into rust for some astronomy projects, ultimately decided against it because it doesn't support oop that well

programming languages can't be 'faster' than one another if they're both just outputting assembly code

>Rust
>fast as fuck
>not pain in the ass

Attached: image1.png (512x320, 13K)

The issue is that computer hardware eventually evolved into being abstract machines to run C code.
Ancient C standards don't support processor caches or branch prediction, so a programmer or an optimizing compiler can't program these processor facilities. They're made transparent to the running code.
Most processors today have things implemented in microcode, but because C in't aware of it the microcode is not user-programmable. The only benefit the facility gives is the manufacturer being able to patch security vulnerabilities.
As such, C came to limit the efficiency and speed of every other language that runs on its platform.

>Ancient C standards don't support processor caches or branch prediction
no language 'supports' them you fucking retard they're handled by the CPU

>Haskell is a better demonstration of the potential for high level language performance.
It would be if its tooling wasn't horrible. Having to juggle shit around with stack is a huge pain in the ass.

This post makes no sense

RUST is still very young, you wait some years and it will be probably faster than C++

>OOP
Nice meme

Attached: 1524603892322.jpg (950x534, 141K)

>you can just let pajeet write in java and get the same performance as rust

Attached: 1366783208025.jpg (300x300, 69K)

Precisely because C doesn't so the CPU has to do it instead.
A compiler could handle predictions just fine. A compiler can look at your source and say that only once in a hundred times this branch goes this way, and now your processor can do the speculative execution according to the hints left in the executable.
But because of the languages modern processors target, there is no such interface.

Bump for interest

Can assembly do 10 times the speed of binary?

pgo

>A compiler can look at your source and say that only once in a hundred times this branch goes this way

Lol no. It would have to look at your input data too, brainlet.

>A compiler can look at your source and say that only once in a hundred times this branch goes this way

Attached: 1529189357229.png (571x618, 29K)

get on the rust bandwagon.

-energy efficient
-literally void of data access issues (that's 72% of the bugs in the software industry)
-fast as fuck
-memory safety with no GC
-zero cost abstraction

c/c++ are dangerous, segfaults in production every single fucking day.

golang is retarded, i mean like, really really retarded.

Attached: f7216fd4-dna-sequence-finding-test-results-screenshot-from-web-site.png (847x527, 62K)

Intel tried that with itanium - programmers and compiler writers said nope, fuck that shit.

haskell btfo

How the fuck can Rust be almost as fast as C when C is as barebones as it fucking gets

the power of zero cost abstraction.

rust produces lightning fast programs that are formally proven to be safe with no GC.

but it's not for everyone, only people who don't want to lose millions of dollars due to a data race bug, or the people who don't want their airplane controller to segfault on air.

As long as the operating system is written in unsafe languages no. They burden us with the shit they need like the MMU.

shut the fuck up babby

I can't wait until Mozilla goes under so the constant shilling finally stop

10x development time, maybe

yeah sure if CPU manufacturers optimize for it like they do C by emulating a fucking PDP-11 and if its compilers are written and vetted by ancient computer magicks wizards
rust cannot be as fast as C with all of its language features because reducing the instruction count from a high level language is hard, and rust is written by trannies and hipsters to compete with C++
what you're saying is that it's theoretically possible to write a program in language X or Y that's faster than a well-optimized piece of assembly
what you don't know (obviously because you're a fucking shilling bait retard who should have made a rust small-brained wojak) is that it is impossible to write a program that will run faster than your hardware
obviously it's less tedious to write than C and much less of a clusterfuck than C++, but that's exactly the point, and mouthbreathers like yourself who cannot write at a low level are the reason why we have these trendy high level languages everybody and their dog is shilling is exactly the reason modern software runs slower than old computers. C was here yesterday, it's here today, and it'll be here tomorrow and the day after because it's so simple. when you trannies can get your shit together and write a language that isn't so neutered, then call me
also, this post will get no replies because Jow Forums is full of fucking retards

Mozilla couldn't even pay steve klabnik enough money to make him stay, doubt that they can afford shilling budget like google.

>2013

benchmarksgame-team.pages.debian.net/benchmarksgame/faster/rust.html

rust is faster than C

It looks like 07 feb 2015, but that's still before the first stable release.

nobody is emulating PDP-11 you fucking retard learn your shit first and KYS

last update, from days ago.

imagine running this fast while being formally proven to be memory safe and void of data races

Attached: fast-programs-different-programming-languages.jpg (1600x900, 112K)

gotards BTFO

Attached: 1497619418381.png (300x441, 25K)

>the people who don't want their airplane controller to segfault on air
BRAINLET ALERT
Airplane controllers don't segfault on air because they're T E S T E D. Which is the only way to know that a piece of software works.

Rust doesn't help at all, here. Let's say you did not test because you're a brainlet who thinks using Rust will magically make you program bug free. There is an out of bounds access because you did not test your program properly. In C, this would cause undefined behavior, and probably a crash. In Rust this would panic. Now, explain to the passengers, as the plane is about to crash into the ocean, why a panic is better than a crash caused by undefined behavior.

Most importantly it‘s only for people who strive to be unemployed.

Except that you can reliably test for a panic, and not undefined behaviour.

yes, and also will pave the way for a much-needed more inclusive software community.

It does not matter. Once your program is in the air, if it can't compute the right outputs for a given set of inputs, whether it's written in C, Rust or PHP does not matter in the slightest.
Maybe in Rust you can detect a panic properly and flash a message in the cockpit to confirm to the pilot why they're about to die, but that's it.

tests and simulation are not exhaustive.

and 99% safe is better than 0% safety.

rust removes 72% of the bugs that exist in the software industry. which are data access related errors.

i know nobody is retarded enough to run airplane software in C using dynamic memory allocation or multi-threading. but that's the point.

rust gives you a formal proof that your multi-threaded program is void of data races and is 100% memory safe with no gc.

You can't test your C code in the air either, but on the ground, it's much easier to test your Rust code than your C code.

Though I agree that Rust's safety is fairly basic.

*steps in one of the 200 UBs C has*

>rust removes 72% of the bugs that exist in the software industry. which are data access related errors.
No it doesn't.
cvedetails.com/cve/CVE-2018-1000657/

Get out of here with your "proof" when the link above shows that the Rust implementation itself has had memory-related issues...

shouldn't C++ be as fast as C? Especially since you can just write C in C++.

>but on the ground, it's much easier to test your Rust code than your C code.
How, exactly? Testing code is making sure it gives the right outputs to some inputs, how is Rust doing better than C?

...

>72% of the bugs in the software industry are data access related

>basic safety is removing all those 72% of bugs.

that's not basic user

>vec_deque.rs
>ctrl+f "unsafe"
>60 matches
There are your possible culprits, all marked as such.

struct Parent { child: &Child }
struct Child { parent: &Parent }
let parent = Parent { &Child { parent } };

WHAT IS RECURISION IAM SUCHA BAD LANGUAGE

Rust is a bit better at doing something that 1) you can do in C/C++ with sanitizers or Valgrind and 2) is not difficult and does matter.
Detecting something bad happening is the easy part. Proving its absence or discovering the paths leading to it is the hard part, and Rust does not help there.

There is a reason why no one in the safety-critical software industry cares about Rust. It does not help with testing or proving anything.

oh yeah it does :
zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/

maybe not 72%, current data shows that 70% of bugs are memory access issues. whi rust formally eliminates.

the rust implementation is a single point of failure, people can concentrate their energy to make sure it approaches perfection.

with other languages, every program relies on its creator to make sure it is perfect. so basically you have millions points of failure.

what exactly do you want to happen when you delete a parent/child and access the child/parent in the future?

are you fucking retarded or just plain ignorant? at minimum, Intel chips have been emulating PDP-11 subprocesses for ages now as an optimization for C, because guess what kernels and a great part of userland is written in? oh yeah, the one designed around and for the PDP

Rust ins't formally proven, just some parts of it's stdlib through the RustBelt project plv.mpi-sws.org/rustbelt/

See that wide af margin for python?
thats if you have enough iq to do something as simple as using numpy. its optional, of course.

That can never happen. If Rust was a decent language you would be able to give the parent and the child the same lifetime but that's not allowed because it is """dangerous""". Meanwhile half of the Rust standard library uses "unsafe" to do exactly this (Just grep the source code of std::vec::Vec). Either admit that you can't even write basic programs in Rust without disabling it's safety features, or admit that it is a badly designed, incomplete language. Because it is both.

>imagine running this fast while being formally proven to be memory safe and void of data races
WPA2 was formally proven to be correct, yet it still got KRACKed.

Implementations didn't, I guess.

github.com/seL4/seL4
github.com/mitls/hacl-star/tree/master/code
yeah i surely can't imagine...

1) why should I care?
2) i have several clients with javascript/node-based projects: how to convince myself and themselves about switching to a Rust-based solution?
3) is it possible to build mobile apps with Rust as well?

Rust seems to be the one coming out of the Node/Rust/Haskell/Go ~2010 language race. It seems interesting now that it's getting mature.

Convince me, I want to be hyped about it but I'm tired of rewriting everything in new meme languages

Only Go is capable of being faster than C

Attached: images.png (225x225, 5K)

>1
nigger
>2
kys
>3
yes

bad bait

Attached: 15519909005690.png (1200x1200, 421K)

.Net finally beating Java.

Rust doesn't have a specification
Therefore all Rust code is undefined behavior
Therefore Rust has more undefined behavior than C

(stolen from cmpwn.com/@sir/100437209244243864)

>will Rust allow speeds 10x times that of C? or are rust evangelists delusional?
Its not about delusion, its knowingly lying with the intent to deceive. Nothing they say can be trusted.

WPA2 was proven secure according to a bad assumption, which the KRACK was able to violate.

Firefox replacing C++ with Rust was about safety, not speed.

>check their reddit
Checked, didn't see any such ridiculous claims on Jow Forumsrust or Jow Forumsrust/new. I guess you're the one who's delusional.

Its only as fast when you do everything in unsafe blocks which defeats the whole purpose of the language in the first place.

That only applies when parsing input data, Rust by default always does checks so the data is correct which is costly and it requires an unsafe block to get around. But other than that it's just as fast while safe.

given how cheap array bounds checks are with binary instrumentation in comparison to address sanitizers, I'm pretty angry for C to not have any fat pointer primitive (ptr+size)

If two languages are compiled to x86 asm, why is one of them faster than the other? Aren't they basically doing the same thing on machine code level after all?

I've read the code on the bench website.
The Rust code is not safe and calls unsafe() everywhere.

It was both really. About safely writing multi threaded code.
Multi threading being the part that provides the speedup.

You are confusing "register based machine" with "PDP-11 emulation" kiddo
Registers are objectively faster than stack machines. No go fuck off back to your Fortran/Forth world

Fortran wins

out of 10 programs, only 3 have any unsafe in it
two use intrinsic functions for Intel's vector instructions. C++ version does the very same thing, but that's ok because it doesn't have unsafe keyword
third uses GNU Multiprecision Arithmetic Library, since it's C code, it's necessary to wrap it with unsafe. kinda cheating since it's not pure Rust imho

Not really, Functional languages were never meant to be fast over functional.
Lisp/Pascal/Go have their uses, comparing them to C is stupid.

Rust OTOH is trying to edge in on C's turf. Comparing them is fine.

>Go
>Pascal
>Functional
What?

if a programming language has a type system, it's functional

Attached: 1541799843800.jpg (645x588, 57K)

Rust is slower than Lua, so no
julialang.org/benchmarks/

Attached: Screenshot_20181219-090159_Lightning.jpg (720x1280, 173K)