Rust bandwagon
Rust bandwagon
Posted Jan 3, 2023 4:49 UTC (Tue) by himi (subscriber, #340)In reply to: Rust bandwagon by summentier
Parent article: Welcome to 2023
It's not that Rust /can't/ do that kind of thing, but much of what you do when writing computational code is fiddling around and experimenting with ideas, and the things that make Rust valuable for systems coding can get in the way of that kind of fiddling and experimentation. I've had some success in my (small, pretty simple) projects doing the experimental phase in straight Python and then once I had a successful model replacing the kernel (and potentially other hot paths) with Rust, but when I've tried to start out from scratch with Rust it's not been much fun . . . Julia is trying to find a middle ground that lets you have a lot of the flexibility of Python, but the performance characteristics of a fully compiled language - I haven't done more than dabble with it yet, so I can't say how successful it is with that.
Of course, if you take that multi-language approach it ends up not mattering that much what your components are written in, as long as they can interoperate - that's one thing where Rust is both good /and/ bad (as the recent discussions about ownership of buffers across the Python/Rust boundary shows). In that case, Rust instead of C++ is definitely a win (for your sanity, if nothing else) . . .
Posted Jan 3, 2023 5:17 UTC (Tue)
by rsidd (subscriber, #2582)
[Link]
C++ is just too clumsy for scientific programming, in my opinion.
Posted Jan 3, 2023 15:08 UTC (Tue)
by summentier (guest, #100638)
[Link] (13 responses)
I have recently switched from Python to Julia, and minor language warts aside, I really like it: it gets the performance–productivity tradeoff exactly right. I have used Julia for two medium-site projects now, both of which would have been nigh-impossible for me to do in a two-language, Python+X, setup (despite 10+ yrs of eyperience).
So I agree with you insofar: if I were teaching students who will soon become computational physicists, Julia, no questions asked. The problem is, I am not. In the ballpark of 9/10 of students will leave for industry before or at graduation and 8/9 of the remainding scientists will do so as they fail to secure a permanent position in academia. Physicists are in a bit weird spot when it comes to industry since there are few dedicated positions – the most consisistent career I could make out was sort of a "specialized computational problem solver". So it feels prudent to at least keep this in mind.
The upshot is that I am faced with a trilemma performance–productivity–popularity. We agonized over the weight of each pole in multiple faculty meetings. If we neglect performance, Python is the clear winner. Eventually, you will need to make your program fast, which is where vectorization and native/JIT extension come into play. Only after starting to teach Python, I came to realize that for vectorization to make sense, you first have to rewire your brain in a weird way, which leads often to convoluted code and confused students. The two-language setup is too tall an order, particularly because of how difficult is to teach the "compiled" side. Neglegt the productivity side, and you arrive at C(++) and, perhaps surprisingly, Fortran, all three of which make me unhappy.
That brings us back to Julia and Rust. I become more and more confident that both languages will survive, but with both I still have feeling that they're not quite out of the woods yet. That's why I am monitoring the Rust progress in the kernel quite closely.
Hope this clarifies things. (Thanks for sharing your Rust expericence BTW.)
Posted Jan 3, 2023 15:37 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (8 responses)
Out of curiosity, why Fortran? Okay, I've used nothing newer that Fortran-77, but I thought newer versions had a lot of maths operators that made life easy(er).
Cheers,
Posted Jan 3, 2023 16:34 UTC (Tue)
by summentier (guest, #100638)
[Link] (7 responses)
Posted Jan 3, 2023 17:30 UTC (Tue)
by fenncruz (subscriber, #81417)
[Link] (6 responses)
Perhaps its biggest strength (and weakness) is its backwards compatibility. Fortran versions are more of a guideline than a rule. So in your projects, you can combine different versions of Fortran, even in the same file. After living through the python 2 to 3 transition, Fortran's ability to still run code from the '60s unmodified is a miracle. Of course, we get stuck with language constructs that we would rather leave in the 60s, but I guess that is the price to pay.
Posted Jan 3, 2023 18:49 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (5 responses)
Just watch out for that FOR LOOP. (I think I've got the right construct.)
The semantics between FORTRAN and Fortran is subtly different which can do serious damage if you don't realise the FORTRAN guy relied on it.
Namely
FOR I = 10 TO 1
will execute the code in the loop if compiled with FORTRAN, but will skip it if compiled with Fortran.
So be careful, boys and girls :-)
Cheers,
Posted Jan 3, 2023 19:15 UTC (Tue)
by fenncruz (subscriber, #81417)
[Link] (4 responses)
Fortran does not have have for loops is has do loops, there is no NEXT statement, nor do you use TO, to sepcify a range. All versions of fortran would use: do I=10,1 which would not execute. The difference with between versions is modern fortran would recommend an end do statement to terminate a loop while older fortran would use a numbered label to specify the end of the loop.
Perhaps you have some very non standard vendor extensions but that is not standard fortran in any version.
Posted Jan 3, 2023 20:26 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (3 responses)
FORTRAN *would* execute the body of the loop. Once.
Fortran, as you say, wouldn't.
(Unless you use compiler specific extensions - the F77 compiler I used had a switch to enable the old FTN behaviour.)
I'm old enough to remember the difference between FORTRAN and Fortran :-) I've never heard of fortran.
Cheers,
Posted Jan 3, 2023 20:46 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (2 responses)
DO I=10,1 would probably do an implicit STEP -1
J=10
Cheers,
Posted Jan 7, 2023 9:31 UTC (Sat)
by joib (subscriber, #8541)
[Link] (1 responses)
DO I=m1, m2
then m1 must be <= m2. So the loop in your example is invalid. You're most likely describing some compiler-specific extension (or accidental behavior later documented by the compiler developers as expected behavior. :) ).
Posted Jan 7, 2023 17:25 UTC (Sat)
by Wol (subscriber, #4433)
[Link]
Fortran allows a lot of (specified) behaviour in the name of optimisation, that can lead to unexpected results. Like storing the index of a do loop in a register, such that it can only safely be read, and not relied on when the loop exits. It seems highly likely that most FORTRAN compilers (and certainly the one I was using in 1983, iirc) did not bother to check the loop limits. Given that I understood that FORTRAN explicitly said the index,limit check was done at the *end* of the loop, I would be surprised if there was a special check on entering the loop.
When Fortran moved the check to the start of the loop, then it makes sense that loops can execute zero times.
Cheers,
Posted Jan 3, 2023 19:17 UTC (Tue)
by ma4ris5 (guest, #151140)
[Link] (1 responses)
In Rust language side Google develops libraries and scientists verify that those libraries (to be used in Android phones)
Azure CEO Mark Russinovich wrote last year, that C/C++ should be deprecated over Rust with new projects.
Container images in Cloud are being developed (hopefully) to contain less components with memory safety issues,
RedHat recommends that the container images should contain only the necessary components:
I found "This week in Rust"
Posted Jan 4, 2023 8:24 UTC (Wed)
by jem (subscriber, #24231)
[Link]
The original is at: https://doc.rust-lang.org/book/
Posted Jan 4, 2023 2:16 UTC (Wed)
by ianmcc (subscriber, #88379)
[Link]
In the case of the high performance computing course, it is actually run by the computer science faculty, so they are "real" computer science students, and I find it astonishing that they have been taught a really ancient style of C code, basically K&R. Introducing scoped variables in OpenMP already runs counter to what they've been taught. Although we expect that in practice most of the students will end up using TensorFlow or some other toolkit in the real world, we're trying to teach them some computer architecture, so we cover AVX intrinsics, OpenMP, MPI, and CUDA from a relatively low level, so they learn a bit about how the CPU actually executes instructions, and how memory hierarchies work etc, the difference between the various different CUDA memory allocation functions, etc. Given the aims of the course, I think C++ works fairly well, and they write some simple CUDA kernels, which are C++ code anyway.
Using C++ for computational physics is more controversial, and I expect that will switch to Julia eventually. A blocker is that it should be coordinated with the prerequisite course also shifting to Julia. Now I quite like C++, and my career has been doing numerical simulations using code I've written in C++. But it is a really huge language, and few (if any) computational physics students have the time and inclination to properly learn it, even if they go on to a professional career. 20 years ago the decision to use C++ was very clear; for serious scientific computing (back then) you need to use a systems programming language, or something with comparable facilities (Fortran might qualify, but barely), because you need to do your own memory management, and compared with most other options, C++ would let you do that but also use a high level of abstraction in the actual numerical algorithms. This became a very powerful approach with the advent of generic programming. A big disadvantage of C++ is that you need to find (or write your own) libraries for linear algebra etc. The early foray into high performance computing in C++ with valarray was not a success, but there are now some HPC people from Sandia National Lab and other places on the C++ standards committee, so that will hopefully lead to some interesting developments.
In the past I've taught the computational physics course using Matlab, Python, and for a couple of years own-choice of language. For a while students all learned a bit of Matlab in some earlier courses, and these days they should all have done a bit of Python. But those languages are OK for some things, they are terrible for things like Monte Carlo, where you want to have a tight loop that runs as fast as possible. Own choice of language was a bit of a mess; one year a student used Haskell, which I was initially OK with, expecting some elegant one-line (or a few-line) solutions, but his code ended up way longer than anyone else's, and was totally unreadable.
I think in the longer term, if C++ is going to survive then it needs to become a smaller language, eg by compiler enforcement of the C++ core guidelines, and perhaps a language dialect that removes as much unsafe stuff as possible, eg get rid of char* (or maybe get rid of all bare pointers) and just make string literals an std::string. The barrier to entry to learn how to write safe C++ is just too big.
Rust is certainly an interesting alternative, and it may well end up as match up between Julia and Rust, for scientific computing in cases where Python won't cut it.
Posted Jan 4, 2023 5:51 UTC (Wed)
by himi (subscriber, #340)
[Link]
In that kind of context it probably makes sense to be moderately aggressive about moving away from C++ towards something like Rust, given the trends that seem to be developing. There's also maybe a case to be made for the Rust community working to help find ways to make the language more practical for the kind of exploratory development that Python is so good at - I don't know whether that's really viable, though, given the nature of Rust. Alternatively, pushing for Julia to give more consideration to systems development might be an option, though again I'm not sure how realistic that might be.
Good luck with your probably thankless educational challenge!
Rust bandwagon
Rust bandwagon
Rust bandwagon
Wol
Rust bandwagon
Rust bandwagon
Rust bandwagon
...
...
NEXT
Wol
Rust bandwagon
Rust bandwagon
Wol
Rust bandwagon
K=1
DO I=K,J would not execute in Fortran, but would execute once with I set to 10 in FORTRAN.
Wol
Rust bandwagon
Rust bandwagon
Wol
Rust bandwagon
either using Julia's runtime for Rust, or using for example Tokio for Rust: https://github.com/Taaitaaiger/jlrs.
Currently Rust can't guarantee memory safety in some cases with Julia runtime there.
are memory and data race safe: Compilation will fail, if safety rules are not met.
I don't like with Julia's current status "you have to be careful to avoid data races with mutexes and threads":
Should I validate each Julia library for possible thread safety issues?
Stroustrup defended C++ at https://www.theregister.com/2022/09/20/rust_microsoft_c/.
because every memory safety issue is a security issue (may or may not have a CVE).
https://www.csoonline.com/article/3599454/half-of-all-doc...
So C/C++ has higher post deployment security maintenance cost, compared to Rust.
https://cloud.redhat.com/blog/container-image-security-be...
http://this-week-in-rust.org useful to see that what's new there.
Also MIT book could be useful for learning Rust:
http://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/...
Rust bandwagon
>http://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/...
Rust bandwagon
Rust bandwagon