lurk101
Posts: 685
Joined: Mon Jan 27, 2020 2:35 pm
Location: Cumming, GA (US)

Re: Schrödinger's Code - Undefined behavior in theory and practice

Sun Jun 13, 2021 8:29 pm

Heater wrote:
Sun Jun 13, 2021 7:29 pm
If you find a discussion about the creation of correct, robust software a waste of time then perhaps you should not be wasting your time reading this or even be working on creating software at all.
It's not the discussion that's a waste, it's trying to implement aspirational goals in reality. The tools and support are simply not there.
How to make your arguments stronger? Longer is not the answer.

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

Re: Schrödinger's Code - Undefined behavior in theory and practice

Sun Jun 13, 2021 9:05 pm

lurk101 wrote:
Sun Jun 13, 2021 8:29 pm
It's not the discussion that's a waste, it's trying to implement aspirational goals in reality.
I think you have a good point.

No matter what I aspire to I'm very sure I do not have the skills or the time to even begin to make it a reality.
lurk101 wrote:
Sun Jun 13, 2021 8:29 pm
The tools and support are simply not there.
That has indeed been the case for decades now.

Except things like the memory and thread sanitisers that have appeared in recent years go someway to that end.

Today we have the Rust language as an example of what can be done and Bjarne Stroustrup claiming that similar thing can be done in C++, and even better.

As an aside, I would like to remind that "Undefined behaviour", the topic of this thread, was not possible (mostly) back in the day when we used the Ada language. Which is why Ada was mandated for safety critical systems as is still used in many. Things only went backwards in that respect with the adoption of C an C++ by the majority.

I might suggest that the tools have been there for a long time. Mostly ignored.
Memory in C++ is a leaky abstraction .

User avatar
jahboater
Posts: 7191
Joined: Wed Feb 04, 2015 6:38 pm
Location: Wonderful West Dorset

Re: Schrödinger's Code - Undefined behavior in theory and practice

Sun Jun 13, 2021 10:11 pm

Heater wrote:
Sun Jun 13, 2021 7:40 pm
However in the world of C and C++ there is a lot of chaos.
I see a lot of complexity and a lot of choices about how compilers for numerically capable languages such as Fortran or C/C++ deal with floating-point. No chaos, unless lack of understanding causes it to be perceived as such.
Compilers for simpler languages probably don't have such myriad of FP options. But they might be a poor choice for serious FP work.
Heater wrote:
Sun Jun 13, 2021 7:40 pm
However in the world of C and C++ there is a lot of chaos.
Why single out C and C++?
Any language offering precise control of the floating point environment and execution model will be the same.
Heater wrote:
Sun Jun 13, 2021 7:40 pm
So much so that NASA has a page dedicated to it:
"Consistency of Floating Point Results or Why doesn’t my application always give the same answer?" https://www.nccs.nasa.gov/images/Floati ... stency.pdf
A good and interesting document.
But nothing new, and absolutely nothing at all about IEEE 754 compliant hardware producing inconsistent results.
In each case, the document suggests a solution.
I did read that ICC appears to set FTZ for -O3, I hope GCC doesn't do that! I can see the confusion it would cause.

I agree its all rather complicated with a steep learning curve, but its about compilers and libraries only, not the hardware.

lurk101
Posts: 685
Joined: Mon Jan 27, 2020 2:35 pm
Location: Cumming, GA (US)

Re: Schrödinger's Code - Undefined behavior in theory and practice

Mon Jun 14, 2021 2:22 am

Heater wrote:
Sun Jun 13, 2021 9:05 pm
Except things like the memory and thread sanitisers that have appeared in recent years go someway to that end.
Those are fairly intrusive and can modify behavior. A hardware based solution would be more effective, as you previously suggested.
Today we have the Rust language as an example of what can be done and Bjarne Stroustrup claiming that similar thing can be done in C++, and even better.
Rust has a chance. It's not interpreted, it generates decent standalone binaries, and once you get past your initial battles with the memory system the language is attractive. I'm still bewildered by it's 'wild west' crate system. Which crates would constitute a standard vetted set?

I wonder if the Rust LLVM front end is actually written in Rust?
How to make your arguments stronger? Longer is not the answer.

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

Re: Schrödinger's Code - Undefined behavior in theory and practice

Mon Jun 14, 2021 4:20 am

jahboater wrote:
Sun Jun 13, 2021 10:11 pm
I see a lot of complexity and a lot of choices...No chaos...
...
Why single out C and C++?
...
I agree its all rather complicated with a steep learning curve, but its about compilers and libraries only, not the hardware.
There is the thing. We are often talking past each other because what I have in mind is the programming language specification. It's syntax and semantics as laid down in the C and C++ standards documents. Or whatever equivalent specification for other languages. I start from Tony Hoare's statement that "The behaviour of every syntactically correct program should be completely predictable from its source code." Clearly this is not the case for C and C++. In those languages there is so much that is defined by the compiler implementors, library writers, processor architecture.

Perhaps "chaos" is putting it too strongly but looked at from the point of view of Hoare's philosophy the program behaviour is not predictable from the source code. Not being predictable is what "chaos" is all about.

Perhaps I should not single out C and C++, likely others suffer from such unpredictability as well.
Memory in C++ is a leaky abstraction .

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

Re: Schrödinger's Code - Undefined behavior in theory and practice

Mon Jun 14, 2021 4:47 am

lurk101 wrote:
Mon Jun 14, 2021 2:22 am
Those are fairly intrusive and can modify behavior. A hardware based solution would be more effective, as you previously suggested.
Yes, the sanitisers are very intrusive. They are doing very well under the circumstances. Highly recommended for anyone writing serious software.
lurk101 wrote:
Mon Jun 14, 2021 2:22 am
Rust has a chance. It's not interpreted, it generates decent standalone binaries, and once you get past your initial battles with the memory system the language is attractive.
Rust's memory system is pretty much the same as it is in C, C++, Pascal, etc. There is stuff created on the stack and there is stuff allocated space on the heap. The difference being that by default Rust has rules in place to ensure that programs use both correctly. Those being the same rules one has to enforce oneself when writing in other languages to ensure ones programs don't crash or produce random results. Rules like these: https://isocpp.org/wiki/faq/coding-standards
lurk101 wrote:
Mon Jun 14, 2021 2:22 am
I'm still bewildered by it's 'wild west' crate system. Which crates would constitute a standard vetted set?
There is no "standard vetted" set of crates. In the same way there isn't a standard vetted set of Javascript modules for node.js, or libraries for Python's PIP or Perl's CPAN etc.

The true "wild west" is in C/C++ land where the is no such module/package system.

Still, Rust has it's standard library and as time goes by various crates become well known, used and respected. For example Rocket and Actix web frameworks, Tokio for helping with asynchronous code.
lurk101 wrote:
Mon Jun 14, 2021 2:22 am
I wonder if the Rust LLVM front end is actually written in Rust?
Rust's front end is indeed written in Rust. I believe it was originally written in Ocaml.
Memory in C++ is a leaky abstraction .

User avatar
jahboater
Posts: 7191
Joined: Wed Feb 04, 2015 6:38 pm
Location: Wonderful West Dorset

Re: Schrödinger's Code - Undefined behavior in theory and practice

Mon Jun 14, 2021 7:57 am

Heater wrote:
Mon Jun 14, 2021 4:20 am
Perhaps I should not single out C and C++, likely others suffer from such unpredictability as well.
Exactly.
A google search for "rust floating point arithmetic" came up with the same sort of stuff:
The first two search results were:
https://www.reddit.com/r/rust/comments/ ... ing_point/

https://stackoverflow.com/questions/503 ... ts-in-rust
(can Rust deal with the "inexact result" hardware trap?)

Rust explicitly uses IEEE 754 floating point arithmetic, just like C and C++ and Fortran.
I don't know if it has all the precise control over the floating-point environment and execution that the older languages have, and that's likely where languages differ in this respect. In the older languages you can specify all sorts of strange but important things.

Here is another example: floating-point contraction.
Here (for example) FMA (fused multiply-add) instructions hold the intermediate result with infinite precision and so may produce a different result from a separate multiply and add (also one rounding instead of two). FMA is very fast and more accurate, so the C compiler uses it by default, its a win win.
However you can choose not to ("#pragma STDC FP_CONTRACT ..." or "-ffp-contract=...").

Does Rust have this sort of control? I don't know.
If not what does it choose? Strict IEEE compliance or performance?

pidd
Posts: 2324
Joined: Fri May 29, 2020 8:29 pm
Location: Wirral, UK
Contact: Website

Re: Schrödinger's Code - Undefined behavior in theory and practice

Mon Jun 14, 2021 1:00 pm

Is there a general programming language that retains or can retain numbers as general fractions as opposed to fractions of the base? It wouldn't be that difficult to implement, simplification (factorisation) of the fractions would not be needed internally so speedwise it would not be a great impact as all arithmetic would be integer. I guess there maybe libraries in association with GMP/Bignum?

I think Wolfram/Mathmatica could work that way when I used it many years ago.

Most natural constants will still have a problem when they don't have fractional equivalents. There again if natural constants are part of the language then they could be retained as such (again similar to Mathmatica).

What do you call a hexadecimal decimal or a binary decimal? eg 3ABC.3DEFFF or 101.100111

ejolson
Posts: 7574
Joined: Tue Mar 18, 2014 11:47 am

Re: Schrödinger's Code - Undefined behavior in theory and practice

Mon Jun 14, 2021 1:40 pm

Heater wrote:
Sun Jun 13, 2021 7:29 pm
VLA's are an interesting case.

VLA's turned out be a really bad idea that the standards guys have done there best to expunge.

I don't know so it would be interesting to know the history of VLA's. Who's idea was it? Where did it come from? Why did anyone think it was a good idea?
Though I'm not certain, my observation is that the addition of variable length arrays happened at the same time as complex numbers and is there to support high performance computing. One obvious use case is any divide and conquer method where each recursive step requires successively half the temporary workspace as before.

The advantages are
  • No per-processor locks are needed when allocating memory.
    • Stack allocation is automatically cache friendly and NUMA aware.
      • Parallel memory usage will be linear in problem size rather than n^2.
        • Modern 64-bit architectures allow the stack to grow dynamically up to available memory and or fault when a set limit is reached.
        It's also worth noting that very few HPC codes are outward facing, users have agreed not to break things and depending on the site often undergone security checks that include lie detector tests.

        Obviously usefulness in one application domain doesn't make VLAs safe for embedded processors that provide no hardware for virtual memory.

        According to the lead developer of Fido Basic, the latest C standards committee envisioned C to be a fun-filled grab bag of undefined and implementation defined behaviour suitable for all purposes and all processors. Therefore, VLAs are now an optional feature unlikely to be useful for some application domains. It's also worth noting the three-tier segmented memory architecture of the BARK™ is particularly well suited for securely implementing variable length arrays on top of the cactus stacks needed to efficiently support the fork-join model of parallel computing using thousands of concurrent tasks.
        Last edited by ejolson on Tue Jun 15, 2021 12:15 am, edited 2 times in total.

        User avatar
        Paeryn
        Posts: 3305
        Joined: Wed Nov 23, 2011 1:10 am
        Location: Sheffield, England

        Re: Schrödinger's Code - Undefined behavior in theory and practice

        Mon Jun 14, 2021 4:40 pm

        pidd wrote:
        Mon Jun 14, 2021 1:00 pm
        Is there a general programming language that retains or can retain numbers as general fractions as opposed to fractions of the base? It wouldn't be that difficult to implement, simplification (factorisation) of the fractions would not be needed internally so speedwise it would not be a great impact as all arithmetic would be integer. I guess there maybe libraries in association with GMP/Bignum?
        Haskell has a Ratio type that works as a fraction, it's not a native type but it is provided by one of the usual libraries. Ratios can be created using % as an infix operator, I've printed them inside brackets to make it more obvious.

        Code: Select all

        import Data.Ratio
        
        main :: IO ()
        main =
          putStrLn $ "(" ++ (show x) ++ ") + (" ++ (show y) ++ ") = (" ++ (show z) ++ ")"
          where x = 1 % 2
                y = 1 % 3
                z = x + y
        

        Code: Select all

        $ ghc haskell_fractions.hs
        $ ./haskell_fractions
        (1 % 2) + (1 % 3) = (5 % 6)
        
        Python has its fractions module too

        Code: Select all

        from fractions import Fraction
        x = Fraction(1, 2)
        y = Fraction(1, 3)
        z = x + y
        print( f'{x} + {y} = {z}' )
        

        Code: Select all

        $ python3 python_fractions
        1/2 + 1/3 = 5/6
        
        And as both Haskell and Python use arbitrarily large integers there's no worry of either the numerator or denominator overflowing (though you might run out of memory if they are big enough).
        She who travels light — forgot something.
        Please note that my name doesn't start with the @ character so can people please stop writing it as if it does!

        pidd
        Posts: 2324
        Joined: Fri May 29, 2020 8:29 pm
        Location: Wirral, UK
        Contact: Website

        Re: Schrödinger's Code - Undefined behavior in theory and practice

        Mon Jun 14, 2021 7:59 pm

        Thanks @Paeryn, I've never looked at Haskell at all, I will have a peek out of curiosity.

        Return to “C/C++”