Use rust they said. It's fast they said

I've checked the disassembly and rust does bound checking on outer loop and inner loops (opt-level=3).
This is just plain retardation that it does both loop condition and bound checks since size of vector is known before loops as well as upper bounds for both loops and optimal would be to check those loops. None of it is eliminated even if you use is_prime.len() instead of max.

Now without vla

Attached: crust_novla.png (1590x918, 128K)

colorscheme?

Tomorrow-Night

I'm not following the logic of this program. It's called isprime but seems to be testing if the numbers are squares?

Google sieve of Eratosthenes.

Your code is retarded.

Why didn't you loop over the is_prime vec directly? That way there is no bounds check. No one would write shit like this.

This is the first Rust program I've ever written not counting hello world. The purpose of this thread is not to show that rust is inherently slow, but to get input on what would be the most idiomatic way of writing something like this. Let's say I do something like for &mut e in is_prime.iter().take((max as f64).sqrt() as usize).skip(2) .
How would I check the index of e to use in the second loop?

Make that for e in is_prime.iter_mut().take((max as f64).sqrt() as usize).skip(2)

>That way there is no bounds check.
doesn't for_each skip that also? I just know for_each is slightly faster while following the same logic, but I forgot why

use std::env;

fn print_primes(max: usize) {
let mut is_prime = vec![true; max];
(2..=(max as f64).sqrt() as usize).for_each(|i| {
if is_prime[i] {
((i.pow(2)..max).step_by(i)).for_each(|j| {
is_prime[j] = false;
})
}
});

(2..max).for_each(|i| {
if is_prime[i] {
print!("{} ", i);
}
})
}

fn main() {
print_primes(
env::args()
.nth(1)
.unwrap()
.parse()
.unwrap()
)
}

remove print calls in both, rebenchmark

Better

Attached: crust_foreach.png (1590x918, 128K)

Here you go

Attached: crust_noprint.png (1590x918, 146K)

it doesn't remove the bound checks on vector access, there is still a duplicated check for iter termination and bound check in both loops

How is rust better than C++ again? A bunch of ways of achieving the same thing with some being "better" in some way, while being more unreadable.

>A bunch of ways of achieving the same thing with some being "better" in some way, while being more unreadable.
how doesn't this describe C++ as well?

try compiling C with musl and -static

With C++ you're shooting yourself in the foot.
With Rust you'll want to shoot the compiler.

Can anyone explain how the fuck this is a half a second faster?

If you're retarded and try doing things in the same way as in eg. C/C++, of course it will suck.
use rust's pros instead of cons

This is a very small and simple program. Could you please rewrite it in a more idiomatic way? I'd love to see how fast rust can really be.

>sjwzilla
Okay go use botnet Google then faggot

Attached: yikes.png (464x618, 257K)

Attached: 1506336550632.jpg (219x200, 8K)

All Rust code is non standard conforming

>bitching about less than a second
Fucking faggots.

your computer is shit is what the problem is

>he believed the cucks

Now what?

I'm using rustc 1.34.1

Bump for this. Shouldn't it be semantically equivalent?

it probably compiles down to something that the optimizer can deal with easier or their optimization passes aren't set up right or something

rust uses LLVM, right?

It doesn't make any sense. Shouldn't for loops be (basically) syntactic sugar for_each?
If anything, for_each should be a more complex beast since it needs a closure.

does the rust compiler have the option to dump the IR like clang does?

--emit=llvm-ir

Yes, check out the --emit option

>How would I check the index of e to use in the second loop?
.iter().enumerate()

for_each returns the references directly, skipping the bound check that would be likely required on [] on an indeterminate size container. you could of course also do "for element in collection.iter()" for the same effect

Oh okay, that makes sense.

rust is garbage, and we've been here a thousand times before.
I even posted one of these over a year ago highlighting the unfortunate difference between switch and match. the rust trannies come out and complain about your test no matter what. This is computational bolshevism and it must be exterminated at any cost.

Attached: 1539575391053.png (424x266, 127K)

post code on compilerexplorer for both or post it here so people can godbolt it

You can probably speed up the C code by moving sqrt(up_to) outside the loop.

>.iter().enumerate()
Cool, thanks.

C:
#include
#include
#include
#include

void print_primes(size_t up_to){
bool* is_prime = malloc(up_to);
for(size_t i = 0; i < up_to; ++i)
is_prime[i] = true;

for(size_t i = 2; i < sqrt(up_to); ++i){
if(is_prime[i]){
for(size_t j = pow(i, 2); j < up_to; j += i)
is_prime[j] = false;
}
}

for(size_t i = 2; i < up_to; ++i){
if(is_prime[i]){
printf("%d ", i);
}
}
free(is_prime);
}

int main(int argc, char** argv){
print_primes(atoi(argv[1]));
}

Rust (original):
use std::env;

fn print_primes(max: usize) {
let mut is_prime = vec![true; max];
for i in 2..=(max as f64).sqrt() as usize {
if is_prime[i] {
for j in (i.pow(2)..max).step_by(i) {
is_prime[j] = false;
}
}
}

for i in 2..max {
if is_prime[i] {
print!("{} ", i);
}
}
}

fn main() {
if let Some(up_to) = env::args().nth(1) {
print_primes(up_to.parse().unwrap());
}
}

Rust (for_each):

>literally nothing to back up claim
yeah fuck off cnile noone cares.

I wish people would benchmark something more substantial.

>implying I will ever contaminate my disk with rustc again
dumb tranny

you still don't have an argument and you sound like an angry pol retard. noone cares.

Rust is probably evaluating the sqrt every time. Use a temporary variable

Yeah that's why you don't port C to Rust line by line, it just doesn't work. Array indexing is always bound checked unless it's a collection with known size at compile time. Learn how to use iterators, user.

>don't port C to Rust
agreed

See and . It is still slower.

>see (program that uses bound checked access). it is still slower.
did you read my post?

Pow 2 in C maybe for low values transform in I * I on rust change power 2 to i*i

it seems for statements are POZZED in rust.

Attached: Screenshot from 2019-04-28 23-06-14.png (3840x1080, 302K)

There's nothing about the for statement, it's that you're using get_unchecked and that [] IS checked.

Wasn't [] supposed to be unchecked when building in release?

Can linux print to console really fast ? This takes 13 seconds on windows via command prompt.

Windows console is very slow for show character OP send data(never print in console application) to dev/null using pipelines

It's redirected to /dev/null. It's not being printed at all.

This is the worst Rust code I've ever seen, it wouldn't be hard to believe this is a Cnile trying to reinforce the garbage rumors about Rust.

> -> ()
Literally noone writes this, nothing IS the return if you don't return anything.
> Vec::new, resize_with
vec![1; n]; or just use booleans like a normal person (see OP)
> Entire program in unsafe block.
What the fuck are you doing. Holy shit.
> if (emulated boolean) bigger than 0
???
> using a while loop to emulate a for loop because you're fucking retarded and think that's why it's slow
???
> get_unchecked
Fuck you.
> """""meme iterators"""""
... and that's how you know you don't actually use the language. In case you do, please learn how to use it, or just stop. Permanently.

Also, your spacebar might be broken. You should look into that.

You're thinking of C++, it is checked in release. It would be quite silly to allow segfaults in a safety-oriented language, user. That's why iterators exist.

Write it fast

thanks.

class Primes
{

static void PrintPrimes(uint upTo)
{
bool[] isPrime = new bool[upTo];
for(uint i = 0; i < upTo; ++i)
isPrime[i] = true;

for(uint i = 2; i < (uint)System.Math.Sqrt(upTo); ++i)
{
if(isPrime[i])
{
for(uint j = (uint)System.Math.Pow(i, 2); j < upTo; j += i)
isPrime[j] = false;
}
}

for(uint i = 2; i < upTo; ++i)
{
if(isPrime[i])
{
System.Console.WriteLine(i);
}
}
}

static void Main(string[] args)
{
int t1 = System.Environment.TickCount;
PrintPrimes(uint.Parse(args[0]));
int t2 = System.Environment.TickCount;
double delta = (t2 - t1) / 1000.0;
System.Console.WriteLine("Time is " + delta);
}
}

Program.exe > 6543210 > Output.txt
takes 1.75 seconds on Windows.
compiled using the old C# ver 5 compiler.

>timing programs with I/O
Nice one you complete and utter retard

Rust I/O should be faster anyway since format strings are parsed at compile time (yay, macros) but the issue lies elsewhere if you actually read the thread.

Try redirecting to NUL instead of an Output.txt.

you do realize there are other browsers besides chrome and firefox

Go drink some bleach, shit for brains.

It is, however you're using [] everywhere which all bound check (since it's a vector).
If you want an actual (accurate) translation of the C program then pic related, however please don't actually write anything like that pointer-cast. Look up better implementations of Sieve of Eratosthenes. The reason I needed to use unsafe there was because you're mutating the list *while* iterating it, which is obviously not a very safe thing to do, also don't time IO programs, but the way to print the primes (equivalent to your method, that is) would be:
for (n, &prime) in is_prime.iter().enumerate().skip(2) {
if prime {
print!("{} ", n);
}
}

Note that this would be considerably faster with one print.

Attached: 2019-04-28-220626_1920x1015_scrot.png (1920x1015, 157K)

OP here. I use qutebrowser.

I don't see any easy way to redirect to NUL and measure the time on windows. The output of the time measurement utility ends up getting sent to NUL as well.

I forgot to mention, I'm not saying don't use it because it has unsafe, the point of unsafe is to mark unsafe code as such, so as long as it's probably safe unsafe code then that's not an issue, just bad practice if avoidable which it is.

Maybe a bit slower than C, but massively more safe.
C is an active security threat.

I haven't read all the code in this stupid thread but
>declaring shit as immutable and using unsafe to cast pointers to it as mutable in a release build
What the fuck are you doing? This is undefined behavior and the optimizer can easily fuck up everything

Yeah, if you declare it as mutable it'll go "hey what the fuck? nothing is mutating this" because you can't safely mutate it while iterating it. Like I said it's not good, it's just the equivalent, in the C version everything is done with raw pointers.

Security doesn't matter as long as it goes fast

Would his code work if he simply declared is_prime as mutable?

yes you just get a warning, see: fuck yourself

I think I misunderstood your question, actually. If you're saying "would he not need to do the pointer garbage if it was simply mutable"? No. The issue like I said in my post would be that you're trying to mutably borrow the data *while* iterating it (and the iterator borrows it immutably). In other words, the iterator expects the data not to be mutated while the data is trying to be mutated.

>vscode
Didn't even read your post. Sorry, I can't take you seriously.

>[] everywhere which all bound check (since it's a vector).
People have mentioned this already. Like I said above, this was my first attempt at rust.
>you're mutating the list *while* iterating it, which is obviously not a very safe thing to do
The alternative sounds painful.
>don't time IO programs
I assumed redirecting it to /dev/null would mitigate that while still measuring string formatting performance. Why was I wrong?

I didn't mean to be condescending with the [] thing, I mainly made this post to highlight that it is the source of the performance difference.
Redirecting stdout to /dev/null barely mitigates anything, it just won't get printed to your terminal but entirely discarded. It'll still get formatted and outputted, but it'll be discarded instead of printed onto your screen.

also your C program segfaults if you run it with no arguments. lol

>C program segfaults
Nothing new here.

You can fix this by checking if the pointer is null, and if so, changing it to 5

or just checking argc...

Check disassembly, this is not happening.
Bound checks still happen because the iterator is not over the array.

Based

On what?

Yes, I am aware. I didn't actually go that far up the reply chain, I just saw "for_each faster than for", I guess LLVM is pulling some interesting optimizations there. Dunno.

good one user

Actual pozzed rust babbies browsing Jow Forums right now

Attached: 1551349929474.png (533x360, 215K)

>highlighting the unfortunate difference between switch and match
explain
I'm aware that switch is (not ensured) a jump table and patten matching/math is similar to what gperf generates, but what's unfortunate about it?