Heater
Posts: 15509
Joined: Tue Jul 17, 2012 3:02 pm

Re: The Rust debate.

Tue Oct 01, 2019 4:21 am

Hmm... let me try that...
Memory in C++ is a leaky abstraction .

Heater
Posts: 15509
Joined: Tue Jul 17, 2012 3:02 pm

Re: The Rust debate.

Tue Oct 01, 2019 5:29 am

jcyr,

This is the same problem I was fighting with another program on Raspbian today. The LLVM backend used in the latest Rust has a problem with Rapbian. No idea what exatly but there is a work around which I have now added to the Cargo.toml file. Pull the fft_bench repo an try again.

I also added a loop around the timig to get a better look at what goes on. On my Pi 3B+ the results might surprise you:

Code: Select all

$ gcc -Wall -O3 -o fftbench fftbench.c
[email protected]:~/fftbench $ ./fftbench
fft_bench v1.2
OpenMP not available on this system
Freq.    Magnitude
00000000 000001fe
000000c0 000001ff
00000140 000001ff
00000200 000001ff
1024 point bit-reversal and butterfly run time = 484us
1024 point bit-reversal and butterfly run time = 362us
1024 point bit-reversal and butterfly run time = 360us
1024 point bit-reversal and butterfly run time = 359us
1024 point bit-reversal and butterfly run time = 515us
1024 point bit-reversal and butterfly run time = 360us
1024 point bit-reversal and butterfly run time = 360us
1024 point bit-reversal and butterfly run time = 359us
1024 point bit-reversal and butterfly run time = 490us
1024 point bit-reversal and butterfly run time = 360us

$ cargo run --release
    Finished release [optimized] target(s) in 0.09s
     Running `target/release/fftbench-rust`
fft_bench v1.2
Freq.    Magnitude
0x000000 0x0001fe
0x0000c0 0x0001ff
0x000140 0x0001ff
0x000200 0x0001ff
1024 point bit-reversal and butterfly run time = 190us
1024 point bit-reversal and butterfly run time = 187us
1024 point bit-reversal and butterfly run time = 186us
1024 point bit-reversal and butterfly run time = 186us
1024 point bit-reversal and butterfly run time = 186us
1024 point bit-reversal and butterfly run time = 188us
1024 point bit-reversal and butterfly run time = 188us
1024 point bit-reversal and butterfly run time = 186us
1024 point bit-reversal and butterfly run time = 188us
1024 point bit-reversal and butterfly run time = 186us
On my PC they both come in at about the same 30us.

If you feel the need for speed, use Rust !
Memory in C++ is a leaky abstraction .

jahboater
Posts: 5492
Joined: Wed Feb 04, 2015 6:38 pm
Location: West Dorset

Re: The Rust debate.

Tue Oct 01, 2019 6:57 am

Different compilers ....
Could Clang/LLVM be used for the C/C++ version?
Otherwise its all meaningless.

Heater
Posts: 15509
Joined: Tue Jul 17, 2012 3:02 pm

Re: The Rust debate.

Tue Oct 01, 2019 8:06 am

The Rust executable is huge when not stripped of symbols. It gets much smaller after strip:

Code: Select all

$ cargo build --release
   Compiling fftbench-rust v0.1.0 (/home/pi/fftbench/fftbench-rust)
    Finished release [optimized] target(s) in 3.63s
[email protected]:~/fftbench/fftbench-rust $ ls -lh target/release/fftbench-rust
-rwxr-xr-x 2 pi pi 2.4M Oct  1 09:00 target/release/fftbench-rust
[email protected]:~/fftbench/fftbench-rust $ strip target/release/fftbench-rust
[email protected]:~/fftbench/fftbench-rust $ ls -lh target/release/fftbench-rust
-rwxr-xr-x 2 pi pi 166K Oct  1 09:01 target/release/fftbench-rust
Still big. It is possible to build tiny binaries if one forgoes uses of Rust's standard library, as in embedded systems for example.

I would not expect excessive loop unrolling, after all Rust and C/C++ are using the same optimizer/code generator when using clang and you see the same situation there.
Memory in C++ is a leaky abstraction .

jahboater
Posts: 5492
Joined: Wed Feb 04, 2015 6:38 pm
Location: West Dorset

Re: The Rust debate.

Tue Oct 01, 2019 8:31 am

jcyr wrote:
Tue Oct 01, 2019 7:23 am
jahboater wrote:
Tue Oct 01, 2019 6:57 am
Different compilers ....
Could Clang/LLVM be used for the C/C++ version?
Otherwise its all meaningless.
Not really. Clang does better on this benchmark, but that's not always the case.
It doesn't matter which compiler does better. The fact is they are different and therefore you are not just comparing the speeds of the two languages, you are also comparing the performance of the two compilers.

Comparing languages is hard!

Heater
Posts: 15509
Joined: Tue Jul 17, 2012 3:02 pm

Re: The Rust debate.

Tue Oct 01, 2019 12:24 pm

jahboater,

Yes, comparing programming languages is hard. Mostly for reasons that are nothing to do with performance.

But I don't understand you. Can you explain what you mean by "comparing the speeds of the two languages" ?

A programming language definition is a really abstract thing. It describes some means of transforming an input to an output. Generally by describing the steps of some algorithm that does that. It has no concept of time. A programming language does not care if what is written can be done is a nanosecond or takes a billion years.

I think of it like mathematics. Given:

x = 2
y = 3

then we might have:

z = x + y

That says nothing about how to actually make a z out of an x and y. It says nothing nothing about how long it might take to solve the equation and find z. It just is.

Now, Turing tells us about what is a "Universal Turing Machine" and about what it can and cannot compute. Most of the programming languages we like to use are equivalent to that Turing Machine. That is to say, anything you can write in one language has a functional equivalent in another.

But note, there is nothing about time in the Turing machine definition. Given that and the above I don't understand what it would mean to "compare the speed of a language". They are all the same! In theory at least all programs in all languages can be compiled to the same instruction sequence for some real machine and hence run at the same speed.

In that light questions about the speed of a programming language make as much sense to me as asking about the speed of algebra or calculus.
Memory in C++ is a leaky abstraction .

emma1997
Posts: 718
Joined: Sun Nov 08, 2015 7:00 pm
Location: New England (not that old one)

Re: The Rust debate.

Tue Oct 01, 2019 1:04 pm

Heater wrote:
Tue Oct 01, 2019 12:24 pm
A programming language does not care if what is written can be done is a nanosecond or takes a billion years.
Well I do. Every enthusiast will insist his fav is bester. In reality there is only one that is actually 'fastest': ASM. I love HLL guys showing how fast they can do something by comparison. The rub is anything more than a few hundred bytes is masochistic. Or for that matter any size program at all with ARM.

User avatar
PeterO
Posts: 5745
Joined: Sun Jul 22, 2012 4:14 pm

Re: The Rust debate.

Tue Oct 01, 2019 1:10 pm

Heater wrote:
Tue Oct 01, 2019 12:24 pm
jahboater,
Yes, comparing programming languages is hard. Mostly for reasons that are nothing to do with performance.
But I don't understand you. Can you explain what you mean by "comparing the speeds of the two languages" ?
Sometimes you are a real pedantic fool !

PeterO
Discoverer of the PI2 XENON DEATH FLASH!
Interests: C,Python,PIC,Electronics,Ham Radio (G0DZB),1960s British Computers.
"The primary requirement (as we've always seen in your examples) is that the code is readable. " Dougie Lawson

emma1997
Posts: 718
Joined: Sun Nov 08, 2015 7:00 pm
Location: New England (not that old one)

Re: The Rust debate.

Tue Oct 01, 2019 1:27 pm

PeterO wrote:
Tue Oct 01, 2019 1:10 pm
Sometimes you are a real pedantic fool !
Yikes! If I didn't know that you guys in reality are BFF... lol

Heater
Posts: 15509
Joined: Tue Jul 17, 2012 3:02 pm

Re: The Rust debate.

Tue Oct 01, 2019 1:31 pm

PeterO,
Sometimes you are a real pedantic fool !
Thank you, I do appreciate you quaint terms of endearment.

In this case however it's not me being pedantic. If someone wants quibble over the methodology used in measuring the speed of something we need to know exactly what they have in mind.

Personally I don't often much care if programming system A is half or twice the speed of B. That is lost in the noise and there are many other factors involved in choosing between them.
Memory in C++ is a leaky abstraction .

Heater
Posts: 15509
Joined: Tue Jul 17, 2012 3:02 pm

Re: The Rust debate.

Tue Oct 01, 2019 1:35 pm

emma1997,
Yikes! If I didn't know that you guys in reality are BFF... lol
It's a love hate relationship.

I'd love to take PerterO down the pub for a chat over a beer. He'd probably hate it.

:)
Memory in C++ is a leaky abstraction .

jahboater
Posts: 5492
Joined: Wed Feb 04, 2015 6:38 pm
Location: West Dorset

Re: The Rust debate.

Tue Oct 01, 2019 3:14 pm

Heater,

My answer above deliberately avoided the thin ice! Even the same language translated by two different compilers may run at different speeds.

Interesting discussion.

There is just the simplistic comparison we can do with a basic example like your z = x + y

A fast language like Fortran or C, would execute this directly with a single instruction. Say in ARM assembler, something like:

ADD R1,R2,R3

A safe language like Ada, or Rust in checking mode, would add some extra code to check for overflow - still pretty fast in practice, especially on CISC hardware.

A slow language like Python might take thousands of instructions. But even that may not matter for many small programs.

As you say z = x + y just is, but there are clear differences in execution speed.

For me, the hard question comes with more complex examples.

Clearly for a realistic comparison, the algorithm must be identical. To calculate primes, you cannot compare a sieve solution in language A with a naive remainder loop solution in language B. Its just meaningless.

But a more expressive language like C++ with its STL may be able to take much of the load off the programmer, allowing a simpler and possibly faster solution. You cannot just insist on writing the C++ version in basic terms to allow easy comparison with simpler languages, because that's not how its done in C++ and its not being fair to it. That's where it gets hard.
Heater wrote:
Tue Oct 01, 2019 1:31 pm
That is lost in the noise and there are many other factors involved in choosing between them.
Agreed. And its different for each project.

emma1997
Posts: 718
Joined: Sun Nov 08, 2015 7:00 pm
Location: New England (not that old one)

Re: The Rust debate.

Tue Oct 01, 2019 3:32 pm

jcyr wrote:
Tue Oct 01, 2019 2:09 pm
ARM assembler is not really that hard.
Maybe said by someone who has not spent much time with it. I've worked with code in the other two also and IMO six of one half dozen of the other. Or maybe never worked with STM8, similar to AVR, which is similar to 6502, which is from PDP11, which is from... etc etc. Anyway from my experience day and night. What I mean is order or two magnitude difference in tool size and complexity. Then there's learning curve too. I find most of these so called RISC architectures far more difficult than some CISC like z80 or x86.

So not only OT but opposite end of spectrum from Rust and similar HLL. Personally not a fan of object oriented anything. Just a structural brain person I guess.

emma1997
Posts: 718
Joined: Sun Nov 08, 2015 7:00 pm
Location: New England (not that old one)

Re: The Rust debate.

Tue Oct 01, 2019 4:02 pm

jcyr wrote:
Tue Oct 01, 2019 3:47 pm
Methinks you don't know who you're talking to. I've coded entire on-chip bootroms in assembler for Broadcom SOCs, for both ARM and MIPS cores.
So it's probably the other thing: not working with ISA that actually are easier. Again I'm talking about tool size/complexity too. For example AVRASM or SDCC. ARM tools literally thousands of times bigger. Megabytes or gigabytes instead of kbytes. Also learning curve. Having set up labs for both types notice disparity in disk space and student time getting up to speed.

So very surprised anybody with experience thinks ARM is not hard. Probably a matter of IQ. I'm above average but definitely not genius level. Maybe a case of what I call Reverse Kruger-Dunning. lol

sal55
Posts: 63
Joined: Sat Sep 21, 2019 7:15 pm

Re: The Rust debate.

Tue Oct 01, 2019 10:15 pm

Heater wrote:
Sun Sep 29, 2019 11:25 am
jahboater,
It difficult to compare two languages for speed. Only if both languages are supported by the same compiler is it reasonable.
Quite so, from a purely language definition point of view. As it happens Rust uses the LLVM back end so a direct comparison with C/C++ and others is possible. There is very likely to be a front end for GCC soon enough.
I tried Rust under Windows, but it appeared to have severe problems compiling large functions, for example, 1000 lines of:

Code: Select all

    a = a+c*d;         # should be a=b+c*d but rustc generates too many warnings that a is unused
were taking 20 seconds on a Windows PC, and the time grew exponentially. (It was considerably better when there are no variables involved.)

I've just tried under Raspbian, and it was much better, if not exactly brisk. Compiling those 1000 lines took 3 seconds, but 10,000 lines took 110 seconds (nearly 40 times as long). Further, using the -O option even with 1000 lines gave a seg-fault.

By comparison, the same program in C, using Tiny C, took 0.06 seconds, while 100,000 lines took 0.3 seconds. While tcc is exceptionately fast, Rust was 1600 times slower (and probably over 6000 times slower on 100K lines).

(This is a comparison of various C and other compilers on the same simpe tests:

https://github.com/sal55/qx/blob/master ... ertest.txt

This is only for Windows as they must all be tested on the same machine, but you can see that some fare very well while others are poor. Rust (the slower Windows version) was one of the worst .)

I don't know how well Rust generated code; I didn't get that far! But a practical tool should not have these severe bottlenecks. Maybe normal programs compile in a more reasonable time, but the test raises some questions.

User avatar
paddyg
Posts: 2524
Joined: Sat Jan 28, 2012 11:57 am
Location: UK

Re: The Rust debate.

Tue Oct 01, 2019 10:53 pm

On my ubuntu i7 laptop, if I tell the compiler to ignore unused stuff (#[allow(dead_code)], #[allow(unused_variables)], #[allow(unused_assignments)], or simply call a _a) it takes 3.0s for 20k and 15.2s for 100k, also using cargo build --release interesting in a rather academic way but probably not relevant to normal use of compilers with normal projects (i.e. where code is broken into a meaningful structure)
also https://groups.google.com/forum/?hl=en-GB&fromgroups=#!forum/pi3d

sal55
Posts: 63
Joined: Sat Sep 21, 2019 7:15 pm

Re: The Rust debate.

Tue Oct 01, 2019 11:28 pm

paddyg wrote:
Tue Oct 01, 2019 10:53 pm
On my ubuntu i7 laptop, if I tell the compiler to ignore unused stuff (#[allow(dead_code)], #[allow(unused_variables)], #[allow(unused_assignments)], or simply call a _a) it takes 3.0s for 20k and 15.2s for 100k, also using cargo build --release interesting in a rather academic way but probably not relevant to normal use of compilers with normal projects (i.e. where code is broken into a meaningful structure)
At least you're getting a linear increase in compile time. Lines-per-second rates of 7Klps seem quite gcc-like (a somewhat sluggish compiler but popular and will do a competent job). But then I notice you're using an i7 (I assume Intel i7), which I understand is a quite fast chip (my PC was the cheapest in the shop when I bought it).

On the RPi4/Raspbian/32-bit, gcc-O0 gave me 5.5Klps for the 100Kloc test, and tcc abut 0.33Mlps. Nice.

rustc meanwhile managed 0.3Klps for 10Kloc, but the process was 'Killed' somehow after 50 seconds attempting 100Kloc. So I still have reservations about what's happening inside it.

User avatar
John_Spikowski
Posts: 1614
Joined: Wed Apr 03, 2019 5:53 pm
Location: Anacortes, WA USA
Contact: Website Twitter

Re: The Rust debate.

Wed Oct 02, 2019 1:36 am

Deleting dead code, unused variables and assignments, goes a long way towards improving clarity.
Dead code removal is a compiler function. It will not make your source more readable or reliable.

Heater
Posts: 15509
Joined: Tue Jul 17, 2012 3:02 pm

Re: The Rust debate.

Wed Oct 02, 2019 2:28 am

sal55,
I tried Rust under Windows, but it appeared to have severe problems compiling large functions, for example, 1000 lines of:...
No it does not. On my 7 year old Windows 10 PC I get the following when compiling 1024 lines of "a=a+c*d;":

Code: Select all

$ touch src/main.rs
[email protected]:/mnt/c/Users/heater/conveqs/junk$ cargo run
   Compiling junk v0.1.0 (/mnt/c/Users/heater/conveqs/junk)
    Finished dev [unoptimized + debuginfo] target(s) in 0.80s
     Running `target/debug/junk`
35841
[email protected]:/mnt/c/Users/heater/conveqs/junk$ touch src/main.rs
[email protected]:/mnt/c/Users/heater/conveqs/junk$ cargo run  --release
   Compiling junk v0.1.0 (/mnt/c/Users/heater/conveqs/junk)
    Finished release [optimized] target(s) in 0.83s
     Running `target/release/junk`
35841
[email protected]:/mnt/c/Users/heater/conveqs/junk$ touch src/main.rs
[email protected]:/mnt/c/Users/heater/conveqs/junk$ cargo check
    Checking junk v0.1.0 (/mnt/c/Users/heater/conveqs/junk)
    Finished dev [unoptimized + debuginfo] target(s) in 0.29s
The Rust source looks like this:

Code: Select all

fn junk(c: i32, d: i32) -> i32 {
    let mut a = 1;
    a=a+c*d;
    // ''' repeat 1023 more times
    a
}

fn main () {
    println!("{}", junk (5, 7));
}
...a practical tool should not have these severe bottlenecks
I do sometimes worry about the slow build times of Rust and the amount of memory it takes. So far that is nowhere near being a show stopper for me. The Cargo build system only recompiles modules that have been modified, turn around time is quite comfortable for normally sized modules. The "cargo check" is nice and quick during the initial drafting of a new module.
...but the test raises some questions.
Yes it does. Like "Can we have such a test that is not completely absurd?"
Memory in C++ is a leaky abstraction .

Heater
Posts: 15509
Joined: Tue Jul 17, 2012 3:02 pm

Re: The Rust debate.

Wed Oct 02, 2019 2:46 am

jcyr,
Compilers issue warnings when ignoring unused code, variables, and assignments. These allow you to delete them from the actual source code, thus making it more readable.
You have it backwards. When you add:

#[allow(dead_code)]
#[allow(unused_variables)]
#[allow(unused_assignments)]

you are only turning off the warnings about dead code, and unused variables and assignments. You are telling the compiler to allow it without warning.

Better to not use those, then the warning tell you where the unused stuff is and you can remove it for clarity. Which is what you are wanting if I understand correctly.

For code clarity I suggest also using "cargo fmt" to format the sorce. And don't go changing the format options, better we all use the same style if we want to share code.
Memory in C++ is a leaky abstraction .

Heater
Posts: 15509
Joined: Tue Jul 17, 2012 3:02 pm

Re: The Rust debate.

Wed Oct 02, 2019 3:10 am

Ah sorry yes, I did not untangle the ambiguity there.

So it's paddyg who is confused. Using those options only turn off the warnings, they make no difference to build times. At least I see no appreciable difference in build times for 1000 lines of junk.

Turning off or ignoring those warnings is of course a bad idea.
Memory in C++ is a leaky abstraction .

Heater
Posts: 15509
Joined: Tue Jul 17, 2012 3:02 pm

Re: The Rust debate.

Wed Oct 02, 2019 5:05 am

Cool :)
Memory in C++ is a leaky abstraction .

jahboater
Posts: 5492
Joined: Wed Feb 04, 2015 6:38 pm
Location: West Dorset

Re: The Rust debate.

Wed Oct 02, 2019 7:33 am

jcyr wrote:
Wed Oct 02, 2019 1:08 am
paddyg wrote:
Tue Oct 01, 2019 10:53 pm
On my ubuntu i7 laptop, if I tell the compiler to ignore unused stuff (#[allow(dead_code)], #[allow(unused_variables)], #[allow(unused_assignments)]
Those features are one of things I actually like about Rust. I wouldn't turn those off. Deleting dead code, unused variables and assignments, goes a long way towards improving clarity.
+1

It often indicates a bug too, especially after code changes.

jahboater
Posts: 5492
Joined: Wed Feb 04, 2015 6:38 pm
Location: West Dorset

Re: The Rust debate.

Wed Oct 02, 2019 7:39 am

Heater wrote:
Wed Oct 02, 2019 2:28 am
I do sometimes worry about the slow build times of Rust and the amount of memory it takes. So far that is nowhere near being a show stopper for me. The Cargo build system only recompiles modules that have been modified, turn around time is quite comfortable for normally sized modules.
I wonder if it can do the parallel builds with something similar "-j N" that I use with C?
Heater wrote:
Wed Oct 02, 2019 2:28 am
..but the test raises some questions.

Yes it does. Like "Can we have such a test that is not completely absurd?"
It is absurd, but I think compilers should be able to cope.
The code is after all very simple.
And sometimes you do get machine generated code that looks horrible.

User avatar
paddyg
Posts: 2524
Joined: Sat Jan 28, 2012 11:57 am
Location: UK

Re: The Rust debate.

Wed Oct 02, 2019 7:44 am

So it's paddyg who is confused
usually the case, if not confusing!

I never turn those warnings off myself as they are indeed very helpful. I wanted to show the flexibility of the compiler. (It's probably better and quicker to global replace a with _a anyway)

However, what the OP was comparing (for some unfathomable reason) was a function that did nothing. i.e how long does it take the compiler to spot that the whole function (a = b+c*d; a hundred thousand times) simplifies to no operation. By changing the rust version of the function to something that actually did something they have made the comparison less meaningful (moot, if you think it has zero relevance to start with!)
also https://groups.google.com/forum/?hl=en-GB&fromgroups=#!forum/pi3d

Return to “Other programming languages”