Decide to try Rust

>decide to try Rust
>compare some ASM output
>notice this
>tfw rust claims zero-cost abstractions and near C performance

Attached: dilate.png (2553x1367, 139K)

Other urls found in this thread:

doc.rust-lang.org/std/primitive.unit.html
linux.die.net/man/2/exit
twitter.com/NSFWRedditVideo

How many times are you gonna copy this thread, faggot?

you cant deny the fact, that you write shitty code. deal with it and stop posting.

How many times are you gonna copy this thread, nigger?

Not Rust's fault you write shit code, nigger. Fuck off and have sex

Attached: 1564845371558.png (3834x868, 135K)

If the Rust compiler lets it compile, it's by definition not shit code sweetie :^)

DEALLOCATE THIS

Attached: 1544729016111.png (1098x1126, 492K)

>rust is better because it prevents bad code
>stop writing bad code!
these fucking trannies

What motivates people to false-flag this hard?

DILAT THIS

Attached: segfaulting cnile.png (627x722, 114K)

Holy shit this fag again and the same posts just let it die

this type of posting is the only way to get rid of paid SJWZilla Rust shilling threads, since it programs your mind to ignore all Rust threads subconciously.

Attached: 1474094857410.png (1076x1056, 170K)

>zero cost abstractions
The absolute state of Rustrannies

Attached: str contains.png (1920x908, 94K)

You say that, but I still actively seek out these threads for a good laugh.
Seethe harder Cniles, I love it.

Attached: compile time.jpg (1143x1500, 154K)

faggy it's literally the same code, zoomers these days
go back to r/fortnite

It doesn't prevent bad code, no more than any other programming language does.
What it does prevent very well is dangerous code.

Attached: yZYvAQ6_X5U.jpg (480x750, 57K)

that's the joke retard

Yes totally. Keep making more braindead Rust threads proving how retarded Cniles are. It will totally kill all Rust discussion.

Toilet Designer
Toilet Mechanic
Toilet Janitor
Toilet Engineer
Toilet User

Memes aside, there is no reason why Rust shouldn't be able to optimise these to the same code. The slight differences in semantics between the match/or operators don't have any effect here, and compile-time strings can easily be converted to a match expression.
What I wanna know is, why is Rust currently unable to?

I've never seen a falseflag so obvious in my life.

It doesn't, I just realise how Jow Forums really cannot program, even in a handholding language like Rust.

You can't optimise that because it is an explicit O(N) algorithm. You ought to use 'match', the equivalent of switch case for O(1).

Linear or not, the code yields the same result in any case. The compiler should be able to generate the same optimal assembly for a piece of code that is functionally equivalent to another piece of code.

Functionally equivalent is not something you can prove in the general case. There is no algorithm that proves two code blocks have the same output. It's simply an undecided problem in CS. Judging a language by a completely arbitrary compiler's completely arbitrary set of optimisations is of no use.

Yeat another orphan language

>Functionally equivalent is not something you can prove in the general case
Then why is the C++ compiler able to emit O(1) assembly code?

>Judging a language by a completely arbitrary compiler's completely arbitrary set of optimisations is of no use
True, but you can judge the compiler.

>why
Pattern matching. Both compilers have a set of patterns they look for and it's up to the engineers to make your compilations take ages for 2% performance. Personally, I prefer predictable behaviour than random optimisations - what if these disjunctions contained functions that influence the global state? No, if I wanted fast code, I'd have used switch-case.
>judge the compiler
It does its job and produces machine code. If you want to really stretch a compiler, try undefined behaviour handling or challenge the lexer with obscure yet standard grammar.

Computer programs cannot be used to universally compute functional equivalents between two computer programs, as this would reduce to the halting problem. It is unreasonable to expect that a compiler would consider every possible equivalent to OP's code and optimize them all the same.

>I prefer predictable behaviour than random optimisations
Of course, but the two are not exclusive. Nobody wants the compiler to make optimizations that will cause the program to break.

>it produces machine code
That's not a meaningful metric to judge a compiler by. If it didn't produce any machine code it wouldn't be a compiler. I can judge how well a compiler optimizes by giving it different code snippets and checking the machine code it produces. That's not something absurd or useless to do, especially if the compiler has a flag that explicitly tells it to generate optimized code.

>it wouldn't be a compiler.
Glad we agree. Rustc turns standard-conforming Rust code into Machine code. So it's flawless.
>how well
Here's the problem: you're not testing the same C code on two C compilers, you're just assuming the two programs are semantically the same, which is hard to prove because Rust and C are different languages with different standards. I cannot take any cross-language metric as valuable.

This is the third time I've seen this thread and it feels like I'm taking crazy pills.

Attached: 1536041069695.jpg (900x1200, 129K)

Cniles BTFO

when will the rust meme stop ?

Attached: boomer_girl_shoop.png (768x768, 430K)

i post both the question and solution just to trigger all the rust trannies defending their language, its hilarious, these threads stay up for 3 days and when i check catalog in the morning i still wonder what the fuck is wrong with these trannies

unironically based

>its hilarous, I waste my life trolling modern, inventive languages that actually solve problems

Getting rid of bait threads like this would be a good start.

You are all 3 of them.

Attached: 174.jpg (1022x1024, 150K)

HAHAHAHA wtf C IS SO BAD

Literally doing 100% more work than rust here.

Attached: rust_c.png (1366x768, 70K)

Try -O0 for a meaningful result.

why? :^)

Not even the same code, you dumb nigger.
In the C version the function returns a value (implicitly 0, hence the xor eax,eax). The rust function doesn't return anything.

Because -O0 is pure machine code. -O3 comprises what some people somewhere assume is faster code.

I am, and always will be, chess Grandmaster Pepe. It's my job to puppet these trannies and take care of my C/ASM brothers so they mutate their genders

Attached: wisdom.gif (660x780, 270K)

So ruddy bloody mad. The two programs do exactly the same thing lol.

No, -O3 is the highest optimisation level. O0 is the lowest, hence the lowest number.

>what is -Ofast

>int main()
>fn main()
The C function returns an int the rust one doesn't.

That is why I want -O0. -O3 is a matter of pumping in enough patterns, so who cares about it. -O0 shows what the language is capable of.

>-O3 is a matter of pumping in enough patterns, so who cares about it

Erm, people who actually write production software, you numnuts. It's how to actually get fast code.

Rust implicitly returns an integer.

No, writing fast code is how to get fast code. Compiler optimisations are arbitrary and only give you hidden-constant speedups.

>Rust implicitly returns an integer.
You don't even know the language properly.
doc.rust-lang.org/std/primitive.unit.html

Well?

Attached: internetexplorer.gif (591x400, 40K)

Run a rust program and then run: "echo $?"

What appears in your terminal? :^)

The operating system assigns '0' as a hack, to keep up compatibility.

Please consider suicide

>what is runtime init code
Nigger, the main function in Rust or C is not the entry point to you program. Just readelf your executable and you will see. Some startup code sets up the environment and call your main.
This code then calls the exit syscall with the appropriate status code, when main returns. If your rust code did not call panic!, it will return zero.

And, what does it assign when you return Err(i)?
:^)

Rust can still return non-zero values if it didn't panic. Are you a retard? Have you even read the tiny little first smidgen of manual that will tell you this?
Return an Err(i) from your main and you'll see what I mean.

Fucking retarded undergrads on this board baka.

Do you have any clue how Linux actually creates a process and handles its lifetime? Have you read the rust standard?

Yes to both. It seems like you don't though.

If you return Err from main you will have to change the main definition to reflect this. And it's still the rust runtime that will invoke the exit syscall.

Rust doesn't have a runtime. What are you on about?

You clearly don't. You seem to think that the returning from the main function stops the process.

When I said runtime I meant the init code. The one that contains the entry point symbol (_start) and calls your main.

It does you spastic.
Show me a process that doesn't stop when you return from the main function.

Ok, maybe learn a bit more about the language before you start spouting nonsense then sweetie ;)

You terminate a process by calling exit(2)
linux.die.net/man/2/exit

This is where the status code your shell puts in $0 comes from.
In C or Rust, you are not the one calling exit. The startup code (crt0) calls it after your main function returns. The main function is not the entry point to your program.

If we're going this anal, technically the entry point to your program is you turning on your computer.

What are you on about again? Please have sex, kid.
You don't know rust properly and you know nothing about startup support code and process creation/termination.

>using add instead of adc for a signed number
>using a whole 32 bit register for a signed number that will never get larger then 28
>doing mov ecx, edi instead of movzx ecx, dil
>unecessary jump that can get repaced with a movcc instruction instead
>even if you don't want to use movcc you're still unecessarily using ret twice for no reason
>whole function isn't aligned on 16 bye boundry
Yeah bro, your code is TOTALLY optimized.

nice larp retard did u finally reverse minesweeper?

mov ecx, edi is faster bc its just register aliasing instead of executing like w movzx dil. now back to tuts4you or that book on ur desk

I want to be humiliated tell me what the CRT does during setup and termination, oh learned one.

Attached: dilate.png (500x774, 186K)

>it's faster
Not necessarily, out of order execution and whatever previous instructions that went through the pipeline first can change latency. And using a whole 32 bit register for a one byte signed value is INCREDIBLY wasteful you dumb retard shill.

You don't need to know about creation/termination to write fast code, megapaedo.

Once the program has started up then it's all about the code you've written.

Wow I didn't realise this board was full of larpers.

Chars in rust are 4 bytes long.

You're a retard.

movzx takes slightly longer for the cpu to process, but using it you cut out all the unnecessary jumps and the extra unecessary ret instruction, so ultimately you're making the function faster.
If a value is only ever going to be +/- 36, then there's no need to waste a full 32 bits on it when the value can sit nice and comfortably in a single byte.
>b-but muh programmatic bureaucracy!
The absolute state of codelets.

You do it with a u8 (c char) then, and your autism will be satisfied.

Again, the data type here is char, not byte. A char doesn't just store 7-bit ascii values, but every possible unicode value. Rust does not have a "character" type for 7-bit ascii. If we wanted to do that, we could use u8 instead.

apply yourself to agner fogs manual. mov reg reg is never executed. cpu is just renaming aka aliasing 2nd reg as first. no actual mov is done.

32 bit or 64 bit operations are faster than single byte operations. u have zero clue about optimization.
take his advice

Honestly, why is "hurr durr you're using a whole register" an argument here? The C++ version using 8-bit chars is also using an entire register. Just because it's operating on dil instead of edi doesn't mean that any part of the rdi register is free to use by any other part of the application. The register is caller-save, so anything that was in the register before it was used to hold the function input is now clobbered, and within the function, no operations are performed that could make use of storing multiple values in one register (e.g. vector operations).

In this particular instance, the use of 32-bit and 8-bit values makes no difference in terms of performance.

Why the fuck would I care about assembly and machine code, I'm a C++ programmer. It's the compilers job to optimise that shit.

Rust lets you offload even more work to the compiler, though.

Great

Agner's manual was written for Pentium era processors, and at most in this day and age a curiosity.
Because there's only around 16 registers you can use in modern 8086 compatible processors, and if you're genuinely optimizing your code to access memory as little as possible you need to conserve register usage as much as possible i.e. you can use the low 8 bytes for one thing, and the higher bytes for something else (instead of using the whole register for one value and then needing to use memory to store the other, if you're using all the other registers for other values already). This is especially a concern with modern OS's that will completely trash some registers after returning from a call.
Because the vast majority of compilers are utter crap.

Attached: optimization.png (1366x768, 212K)

Agner updates every cpu release. also read what it says below on your page. idk if cmov helps in this func since we only care about one part of the branch that has specific likelyhood depending on input

>Because the vast majority of compilers are utter crap.
I don't care, I'm not a compiler engineer.

>Cnile goes to try rust
>can't stop writing C because their brain buffer overflowed back in 1989
>wahhh Rust is shit

Movzx has a latency of 5 versus 1 for a regular mov. In the shitty code user posted, he is doing the equivalent of moving a singly byte into a 32 bit register, so he should be using movzx anyway. Sure, you can do whatever you want and bitch about how you totally know how to optimize code, just don't be surprised when people point out to you ways you can make your code more readable or optimized.
P.S. Rust optimizes like shit.

None of the loops are aligned and neither is the start of the function, so I personally would be worried about the branch prediction.

BTFO

>rust version: works with Unicode
>C versioSEGMENTATION FAULT

well rust is using llvm

yeah LSD is rip in that func

>unicode
lmao get some standards
like the american standard code for information interchange

the 60s, those were the days

Attached: boomer.png (376x349, 56K)

Kek

never

we are in a holy mission to dethrone a corrupt king

i hope it doesnt