Re: The Case for Rust (in any system)

On 9/13/24 18:15, Alan Somers wrote:
> On Fri, Sep 13, 2024 at 1:43 PM Jason Bacon <bacon4000@gmail.com> wrote:
>>
>> On 9/13/24 08:21, Alan Somers wrote:
>>> On Fri, Sep 13, 2024 at 7:15 AM Jason Bacon <bacon4000@gmail.com> wrote:
>>>>
>>>> On 9/13/24 05:33, Paul Floyd wrote:
>>>>>
>>>>>
>>>>> On 13-09-24 06:17, David Chisnall wrote:
>>>>>> On 13 Sep 2024, at 02:34, Joe Schaefer <joesuf4@gmail.com> wrote:
>>>>>>>
>>>>>>> I just completed a month long project to port a C++ codebase that
>>>>>>> used vectors for array allocations back to using C‘s calloc. For a
>>>>>>> 15% increase in memory footprint, batch jobs that took three days to
>>>>>>> complete now finish in 10-12 hours.
>>>>>>
>>>>>> This sounds highly dubious given that std::vector is a very thin
>>>>>> wrapper around malloc. From your description, I would expect the same
>>>>>> speedup with some judicial use of .reserve().
>>>>>
>>>>> I was going to say exactly the same thing.
>>>>>
>>>>> Considering the reply to this, another one to be plonked so that I waste
>>>>> less time.
>>>>>
>>>>> A+
>>>>> Paul
>>>>>
>>>>>
>>>>>
>>>>
>>>> Some years ago, I wrote a script to time a simple selection sort coded
>>>> in various languages.  Here's an example of the results:
>>>>
>>>> https://github.com/outpaddling/Lang-speed/blob/master/Results/coral-amd64-100000
>>>>
>>>> Note: The clang array/pointer performance is currently regressed due to
>>>> changes in the optimization parameters since clang 8.  That's why it's
>>>> noticeably slower than GCC in these results.
>>>>
>>>> https://github.com/llvm/llvm-project/issues/53205#issuecomment-2318697322
>>>>
>>>> In general, I have not seen a significant difference between arrays and
>>>> vectors in all my years running this benchmark.
>>>>
>>>> This benchmark is anecdotal, as it only measures performance for one
>>>> algorithm.  But in my experience, C++ shows marginally slower
>>>> performance and noticeably more memory use than C.
>>>>
>>>> Coming back to Rust: The results above, showing about double the runtime
>>>> of C and C++, is the best I've seen from it.  It was taking 4x as long
>>>> as C/C++ a few years ago.  That's one reason I don't use it.  I do
>>>> mostly scientific computing, where runtime can be costly.  This is not
>>>> *always* an issue in systems code, but it should be examined before
>>>> choosing a language for a particular implementation.  The other reason
>>>> is the impact of a Rust dependency on FreeBSD ports and pkgsrc packages:
>>>> Frequent changes to the Rust port/package lead to long build times and
>>>> frequent breakage of dependents.
>>>
>>> Right away, I can see that while your C program mallocs the array to
>>> the list's full size, your Rust program doesn't.  It grows the list
>>> one element at a time, with Vec::push .  I bet that if you change the
>>> Rust program to use Vec::reserve or Vec::with_capacity, so that it
>>> only has to allocate once, you'll find the results are different.
>>> -Alan
>>
>> Thanks for the tip.  I assume this is what you meant:
>>
>> --- a/selsort.rs
>> +++ b/selsort.rs
>> @@ -19,7 +19,8 @@ fn read_list(list: &mut Vec<i32>)
>>        io::stdin().read_line(&mut str).expect("failed to read input.");
>>        let list_size: usize = str.trim().parse().expect("invalid input");
>>        println!("list_size = {:?}", list_size);
>> +    list.reserve(list_size);
>>        for _c in 0..list_size
>>        {
>>           let mut str = String::new();
>>
>> It had no noticeable effect on runtime.  Not too surprising, as the vast
>> majority of the runtime is in the O(N^2) selection_sort() function
>> rather than the O(N) read_list().  I'd also be shocked if Vec::push()
>> actually allocated 1 integer at a time.
> 
> Weird.  I checked out your repo, and for 100000 elements I get almost
> the same results for Rust as for all of the C/C++ trials (but clang++
> and vectors is a little bit slower).

Software performance is astronomically complex, given all the variables 
in CPU type, memory structure, etc.  It will vary a lot with different 
hardware and compilers and is basically impossible to predict reliably. 
There are always quirks in the system that get tripped up from time to time.

Try and explain this for example:

Sorting int array with clang++18 and subscripts...
User time = 4.74 seconds (.07900 minutes) (.00131 hours).
RSS = 4204 KB

Sorting long array with clang++18 and subscripts...
User time = 2.22 seconds (.03700 minutes) (.00061 hours).
RSS = 4608 KB

Sorting ints should be at least as fast as longs, maybe faster on 
certain hardware.

I'm guessing you don't see this on your hardware either.

But in all of my runs so far, Rust has been significantly slower than C, 
though has moved up in rank.  It was running slower than Free Pascal and 
D until recently.

-- 
Life is a game.  Play hard.  Play fair.  Have fun.