An amusing rant about C

topspin

@Benjamin-Hall the number crunching people swear by it. Not sure why¹, but they do.
It's used for serious computing, not animations on a web page.

¹ Ostensibly: It has 1) matrix types, which is nice compared to raw C but nothing special for any high-level language, 2) all the foundational stuff (BLAS/LAPACK) is built on it, and 3) the one thing where it's better at optimizing code compared to C or C++ is that the compiler assumes no aliasing (C has restrict to opt-in, C++ has nothing)

In practice: they probably don't know what a better language looks like.

Benjamin Hall

@topspin said in An amusing rant about C:

@Benjamin-Hall the number crunching people swear by it. Not sure why¹, but they do.
It's used for serious computing, not animations on a web page.

¹ Ostensibly: It has 1) matrix types, which is nice compared to raw C but nothing special for any high-level language, 2) all the foundational stuff (BLAS/LAPACK) is built on it, and 3) the one thing where it's better at optimizing code compared to C or C++ is that the compiler assumes no aliasing (C has restrict to opt-in, C++ has nothing)

Yeah. That's the context I used it for. And my understanding was "we have epic boatloads of battle-tested numeric code and libraries for it".

Gąska

@Benjamin-Hall said in An amusing rant about C:

battle-tested

Financial or scientific number-crunching? I want to know whether is appropriate here.

Benjamin Hall

@Gąska said in An amusing rant about C:

@Benjamin-Hall said in An amusing rant about C:

battle-tested

Financial or scientific number-crunching? I want to know whether is appropriate here.

Scientific. Quantum Chemistry in this case. Which is all about matrix inversions and solving differential equations

Gąska

@Benjamin-Hall oh, then definately

Benjamin Hall

@Gąska said in An amusing rant about C:

@Benjamin-Hall oh, then definately

Actually scientific number crunching code is fairly hardened in the purely numerical sense. There are lots of computations that we can check against the real world, and it performs nicely. The models that we build on it...not so much. But the direct "integrate this (well-behaved) function over this (nice) range" code? That's solid.

And mostly not written by scientists. Because scientist-written code is uniformly . Sorry to those of the forum dwellers who are scientists. That's a universal constant

djls45

@Benjamin-Hall said in An amusing rant about C:

Because scientist-written code is uniformly . Sorry to those of the forum dwellers who are scientists. That's a universal constant

*cries in Computer Science degree*

aitap

@Benjamin-Hall said in An amusing rant about C:

It was more about why would you do Fortran anyway (and yes, I've done a little bit of it).

Was it fixed-form "exactly like on a punch card", "GOD is REAL unless declared INTEGER" FORTRAN-77, or a more modern variety, with free-form source code, OOP, built-in MPI-like parallelism, operations on whole arrays and other goodies?

Probably the former, if my colleague's experience of fixing some quantum chemistry program that was older than him is any indication. With no comments. And a homebrew "dynamic" memory allocator that works from statically pre-allocated memory.

I would agree that most of the time, one doesn't need the power of Fortran-like languages that offer relatively high-level abstractions (your variables can be arrays! not, like, pointers and other stuff that fits in registers like in C!) while staying pretty close to the bare metal. But when you do, modern Fortran doesn't have many rivals. Numerical Recipes went from FORTRAN-77 to C++. Maybe C++ with Eigen would give you similar experience. Perhaps Rust, but numeric Rust is still somewhat niche.

Gribnit

@djls45 said in An amusing rant about C:

@Benjamin-Hall said in An amusing rant about C:

Because scientist-written code is uniformly . Sorry to those of the forum dwellers who are scientists. That's a universal constant

*cries in Computer Science degree*

*restores heap property by reversing list*

HardwareGeek

@aitap said in An amusing rant about C:

Was it fixed-form "exactly like on a punch card", "GOD is REAL unless declared INTEGER" FORTRAN-77IV, or a more modern variety

Benjamin Hall

@aitap FORTRAN 90, IIRC. But I only did a little bit, fleshing out one small algorithm. It was...not fun. Of course, I was a worse programmer than I am now...and that's difficult. And only knew Python, and that self-taught.

dkf

@cvi said in An amusing rant about C:

Can it do auto-hyphenation in identifiers?

HTML/CSS auto-hyphenation only turns on if the language of the text is defined and you have a set of hyphenation rules available. And you need to turn it on in the style, but that's pretty easy. (I looked this up a couple of weeks ago.)

dkf

@cvi said in An amusing rant about C:

Have you tried programming Fortran? That language has absolutely zero meta-programming facilities.

If you want meta-programming and Fortran, use Ratfor.

Ratfor - Wikipedia

Or, better yet, don't.

dkf

@topspin said in An amusing rant about C:

It has 1) matrix types, which is nice compared to raw C but nothing special for any high-level language, 2) all the foundational stuff (BLAS/LAPACK) is built on it, and 3) the one thing where it's better at optimizing code compared to C or C++ is that the compiler assumes no aliasing (C has restrict to opt-in, C++ has nothing)

The other thing that really matters for numeric code is the order of operations; the order you do a sequence of additions or subtractions in turns out to be really important if you want to avoid significance loss, and C doesn't make strong enough guarantees without a lot of extra work. If you've got stiff matrices then you need this stuff to be right. The algorithms for this sort of thing are really really sensitive, and have been properly debugged in the old FORTRAN libraries, where they were written by actual numerical analysts.

Developing new numerical algorithms is insanely difficult precisely because determining if you've got them right is so tricky. Get them wrong and they'll still produce answers, and for a subtle error they might well produce mostly correct answers for your test cases…

topspin

@dkf said in An amusing rant about C:

the order you do a sequence of additions or subtractions in turns out to be really important if you want to avoid significance loss, and C doesn't make strong enough guarantees without a lot of extra work

That's news to me. Got an example?
The compiler (and processor) can reorder instructions, but I thought that these don't affect IEEE compliance (modulo bullshit like spilling out of 80bit extended x87 registers) unless you do -ffastmath.

dkf

@topspin said in An amusing rant about C:

That's news to me. Got an example?

If you're adding together a long list of numbers, you need to first sort them so that the numbers with the smallest magnitude are added first. That avoids as much gradual information loss in the least significant bits as possible. Why would that matter? Well, if you subtract the result from another big number, whether you end up with zero or not-zero could be exceptionally important. A lot of matrix ops involve exactly that sort of thing, and many scientific matrices (and polynomial equation systems, which are much the same thing on one level) are freaking huge.

Extended precision stuff just means you can go longer without having to be careful.

topspin

@dkf I meant an example where C messes with that, i.e. you did carefully sort the numbers like that but then the addition order is unspecified. I don’t think that happens.

dkf

@topspin said in An amusing rant about C:

I don’t think that happens.

The problem is that there's no guarantee; different compilers might choose to do different things. Digging out proof goes against the

cvi

@dkf said in An amusing rant about C:

@cvi said in An amusing rant about C:

Have you tried programming Fortran? That language has absolutely zero meta-programming facilities.

If you want meta-programming and Fortran, use Ratfor.

Ratfor - Wikipedia

Or, better yet, don't.

Ratfor (short for Rational Fortran)

It provides modern control structures, unavailable in Fortran 66, to replace GOTOs and statement numbers.

Fortunately, Fortran 66 is not something I ever had to program. (Reading programs in Fortran 66 is a different story. Specifically one filled with many moments.)

dkf

@cvi I ran into Ratfor when reading up where m4 came from. Most people only ever encounter m4 when dealing with autoconf (and related) but it's significantly more terrifying than it appears to be at first glance. In particular, it's turing-complete and knows how to do I/O so it is a general language… that happens to be used to write other languages.

It's not quite as bad as C++ templates can get.

cvi

@dkf said in An amusing rant about C:

If you're adding together a long list of numbers, you need to first sort them so that the numbers with the smallest magnitude are added first.

There are other algorithms that fix the problem without resorting to sorting. Depending on the underlying method, a lot of the parallel reduction methods already do much better. (But, again, check guarantees for whatever method you intend to use.)

Regardless, if you need to care about that,
(a) define/find a proper reduction function that uses a suitable method with suitable guarantees
(b) ban the fuck out of -ffastmath and equivalents, since that has a good chance of messing up the aforementioned method
(A solid set of test cases helps, in case some dumdum comes along and enables -ffastmath or something similarly stupid.)

I don't think there is anything specific to C that causes trouble, though. Things that might be problematic under C (e.g., platform differences, such as x86 legacy FPU vs x86 SSE/AVX use) are IME just as problematic in Fortran on the same platform.

Personally, this is one of the cases, where I'd consider reaching for ASM to be valid. If nothing else, it'll protect against overzealous end-users messing with compiler flags (regardless of whether that's for fortran or C/C++).

cvi

@dkf said in An amusing rant about C:

I ran into Ratfor when reading up where m4 came from.

Didn't know about that connection (haven't run into Ratfor, to be entirely honest).

Started reading up on m4 a few times. I've come to the conclusion that I can lead a happy and full life without knowing m4 in depth.

PleegWat

@dkf said in An amusing rant about C:

Most people only ever encounter m4 when dealing with autoconf (and related) but it's significantly more terrifying than it appears to be at first glance.

As someone who never did more than glance at autoconf stuff, I'd say that's not a low bar.

PleegWat

@topspin said in An amusing rant about C:

@dkf I meant an example where C messes with that, i.e. you did carefully sort the numbers like that but then the addition order is unspecified. I don’t think that happens.

Pure asspull but it sounds plausible. Consider this snippet, where the a[i] and b[i] are all between 0.99 and 1.01:

acc = 0;
for( i = 0 ; i < 420069 ; i++ )
{
    acc += (a[i] - b[i]);
}

Now consider this 'equivalent' example with less register interdependency:

acca = accb = 0;
for( i = 0 ; i < 420069 ; i++ )
{
    acca += a[i];
    accb += b[i];
}
acc = acca - accb;

Though I'm sure someone will be along to tell me no compiler ever does this.

topspin

@cvi said in An amusing rant about C:

@dkf said in An amusing rant about C:

If you're adding together a long list of numbers, you need to first sort them so that the numbers with the smallest magnitude are added first.

There are other algorithms that fix the problem without resorting to sorting. Depending on the underlying method, a lot of the parallel reduction methods already do much better. (But, again, check guarantees for whatever method you intend to use.)

I don't think there is anything specific to C that causes trouble, though. Things that might be problematic under C (e.g., platform differences, such as x86 legacy FPU vs x86 SSE/AVX use) are IME just as problematic in Fortran on the same platform.

A well known such algorithm is Kahan summation.

According to the Wikipedia article, that can be broken by optimizing compilers only when they allow "unsafe" optimizations (i.e. -ffastmath), which isn't standard. It also states that this was allowed under K&R but is forbidden under ANSI C, because obviously this is not a semantically sound optimization since floats are not associative. (It does state that Intel C++ apparently allows that by default, but then that's a buggy default.)

Zerosquare

@kazitor said in An amusing rant about C:

Producing whites requires significantly more green luminosity than the other primaries

No, that's the opposite, as the curve you posted shows. The human eye (more precisely, rod cells) is significantly more sensitive to green light than to red or blue.

The ratios you posted are for how much each of the primaries contribute to the perceived luminosity.

kazitor

@Zerosquare said in An amusing rant about C:

The ratios you posted are for how much each of the primaries contribute to the perceived luminosity.

And by definition of the colour space, 100% of each makes (D65) white, meaning that white is produced with significantly more green luminosity.

If they’re all the same luminosity (within quantisation), it looks like this:

… hm. Something about that colour makes people say unsubstantiated things

snide addendum: it’s defintely not a good look to mention rod cells in the context of photopic vision ;)

dkf

@kazitor said in An amusing rant about C:

If they’re all the same luminosity (within quantisation), it looks like this:

How do you know that for sure? You don't know what that will render as on my screen! OK, you can take a guess based on normal screen settings, but that guess can be very far out.

kazitor

@dkf said in An amusing rant about C:

I’ll just save everyone the trouble of repeating variations of this all day

Zerosquare

I think we actually agree, it's just that we're using different units. You meant luminance (in cd/m²), I meant irradiance (in W/m²).

Gribnit

@Zerosquare said in An amusing rant about C:

I think we actually agree

Where is your God now, @Gąska?