[ernst_klim]

> C - there's no magic

Strict aliasing and weak typing say hello.

> wysiwyg of high level -> asm

Except neither GCC nor Clang compile even remotely predictable ASM. It's easier to predict OCaml assembly output than the GCC's one.

[madmax96]

How is strict aliasing magic? How could you possibly define the meaning of accessing an object through an incompatible type since the type of an object determines how the compiler interprets its value? The bits stored in the object do not even necessarily correspond to a value for every type, after all. And that's not even considering the fact that there is a great deal of freedom wrt how implementations can represent floating point numbers, etc. so how can the standard impose a requirement on what happens when you, say, access a double as an int?

What do you mean by weak typing? That can you cast away basically anything?

>It's easier to predict OCaml assembly output than the GCC's one

Surely you are kidding. If that were true, why doesn't OCaml curb-stomp C in benchmarks? IMO GCC's output isn't even a little surprising, esp. once you've gained experience with its favorite optimizations.

[wwright]

Not only can you cast away anything, but:

- casting away types unsafely is required for many common patterns in C, including any form of runtime polymorphism

- basically anything involving numerics has a good chance of happily casting for you without asking you or telling you

[madmax96]

>- casting away types unsafely is required for many common patterns in C, including any form of runtime polymorphism

Which patterns? I'm thinking of stuff like the Berkeley Sockets API, which you can absolutely implement safely.

re numerics: fortunately, that's 100% amenable to static analysis (see -Wconversion, -Wsign-conversion in gcc/clang and coverity's warnings about potentially unsafe casts - e.g. promoting an int to a long is always safe, but an int to a float not necessarily) and follows very straightforward rules.

[atilaneves]

> Surely you are kidding. If that were true, why doesn't OCaml curb-stomp C in benchmarks?

Exactly because nobody (except backend writers) can predict what C compiler backends emit, especially when abusing undefined behaviour.

[madmax96]

OCaml: https://godbolt.org/z/8bWDXy C: https://godbolt.org/z/WAjsvk

I've never actually looked at the output of an OCaml compiler, I have to say I'm surprised by how clean it is. But I wouldn't call it more predictable than that C's output.

[ernst_klim]

>C

You forgot about -O2/3.

[ernst_klim]

> Surely you are kidding. If that were true, why doesn't OCaml curb-stomp C in benchmarks?

You are confusing predictability with performance. OCaml is way more predictable exactly because it generates way more straightforward code.

On the other hand, GCC could do all kind of stuff, generating any sort of assembly. It can even rewrite fairly complex math functions, simplifying them.

Parent was talking about predictable ASM, not about performant ASM.

[parkovski]

I don't think optimizations count as magic. It'd be entirely unreasonable for a language to not do them and they don't change the meaning of the program, undefined behavior aside.

"No magic" is meant as shorthand for "the minimal amount of magic we can reasonably expect given the history of the language and requirements for backward compatibility, and the least magic of any high level language with more than 3 users." Please don't make me do this again for the number 3.

[ernst_klim]

> don't think optimizations count as magic

It's not about magic, you were talking about

> It's pretty much the wysiwyg of high level -> asm

which is not true until you use some ancient compiler from bell labs era. Modern C compilers emit totally unpredictable asm.