This makes the Rust tranny seethe

does it also make them cope and dilate? kek

That's because it checks unicode, dumb cnile nigger

No it wasn't. Cope more.

What the fuck. Is this thread astroturfing or something? We literally had this exact thread a few weeks ago. It's like automated spam bot or something.

Why is Jow Forums full of people who are rabidly upset about Rust? I can understand not liking Rust, or not wanting to use it, but there seems to be a bunch of people here who are incredibly mad that ANYONE would want to use Rust. Even "widely agreed to be bad" languages like JS or VB.NET don't get the same bizarre anger that Rust does.

That's because there's a code of conduct that doesn't allow them to just go to the Rust forums and call people niggerfaggots.

DEALLOCATE THIS

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

Because the point of Rust is not only technical, it's also political, and people would die for such subjects. Would you die to defend the technical prowesses of a programming language? Unless you're utterly autistic (probable), hell no. Would you give your life to prevent the domination over this field of a certain group of people who are using Rust as a vessel for their depraved ideology? That's more likely.

>Would you give your life to prevent the domination over this field of a certain group of people who are using Rust as a vessel for their depraved ideology? That's more likely.
What the fuck are you on about?

Dial 8

Can someone explain how C++ version in OP works? I may have a vague idea but I would like an input.

Yeah it's the same user samefagging. Even admitted to it. He's a very lonely autistic person, this is the only way to get his kicks.

return (value);
where (value) is the boolean value of all the disjunctions after that until ;

>its this thread again.
This will probably get 200-300 replies again since apparently no one here has pattern recognition. My question is, how long will this autist continue to spam these threads before moving on to a different piece of code?

bloated language, what did you expect from webdevs?

Attached: 1567686471398.png (1230x4082, 1.49M)

user... I... Didn't mean it like that. I wanted the explanation of the Assembly code line by line, specifically the part that actually decides whether the symbol is one of the reserved ones.

Attached: 1.jpg (1024x675, 64K)

>gcc -O3
>rustc -C opt-level=2
>rust is slower.
Gee, I wonder why.

Could be it was the best setting for it, anyway more current results show Nim in the lead.
forum.nim-lang.org/t/4253

Attached: 1553644608249.jpg (1200x773, 336K)

>anyway more current results show Nim in the lead.
>forum.nim-lang.org/t/4253
>I think this was posted a while ago and the answer was that G++ found a way to constant fold Nim's C++ output. This means it probably evaluated fib(46) before the program ever ran.
At least read your own links before posting them.

It's pretty simple to understand (the more impressive part was that the compiler was able to come up with it in the first place).
If you crack open an ascii table, you'll see that every one of those characters fall between 36 and 64 (36 + 28). The argument is passed in rdi, and dil gives you the lowest byte, so by subtracting 36 initially, if your character is one of the special ones, it'll be in the range of 0 to 28. The cmp and ja means jump if the dil was above 28 using an unsigned comparison (so not one of our characters). Then we return false. Otherwise, if you look at that constant, it contains 1s in bit positions for the corresponding ascii values of the special chars - 36. For example, that number has a 1bit in position 28, 28 + 36 = 64 = '@'. And so on. It has 0s everywhere else.
If the char is a char we're searching for, it'll shift right by (dil - 36) (so some number between 0 and 28) and keeps only the least significant bit (the and with 1). So if it is a character we're searching for, shifting right by (dil - 36), the least significant bit of the shifted number will be 1 by construction, or 0 otherwise.
You'll see the code stay relatively the same in the case of closely packed together chars but the code will probably change significantly with more spread out chars.

>G++ found a way to constant fold Nim's C++ output.
How is that bad though? Why waste the cycles? Anyway human written c and c++ still beat rust.

Attached: 1561688068302.jpg (594x768, 94K)

>How is that bad though?
It's not bad for the compiler, but it means that benchmark is completely meaningless.

>Anyway human written c and c++ still beat rust.
By a small and shrinking margin, and with plenty of example of Rust programs which are faster than their C or C++ equivalents.

>call
inefficient shitcode

Ooh I get it, it does make sense. Thanks user! When characters are more spaced out, masking becomes inefficient or even impossible?

>It's not bad for the compiler, but it means that benchmark is completely meaningless.
True but these kind of optimizations are pretty important in bigger projects, the rust compiler should do more of it.
>By a small and shrinking margin
Mostly when you write unsafe rust, what is the point then?

>True but these kind of optimizations are pretty important in bigger projects, the rust compiler should do more of it.
I'm not disagreeing, but a pre-calculated result is still meaningless as a benchmark.

>Mostly when you write unsafe rust, what is the point then?
Using "unsafe" doesn't necessarily make Rust any faster. And the point is that in a well-written program, you can keep your unsafe blocks small and easily checked, rather than having the whole program as a source of memory errors.

Learn Rust before talking about it, low IQ retards.

OP already knows the answer, he's made this thread many times