cv5005

Pick an appropriate base type (uintN_t) for a bitset, make an array of those (K * N/4) and write a couple inline functions or macros to set and clear those bits.

simd doesnt make much sense as a standard feature/library for a general purpose language. If you're doing simd its because you're doing something particular for a particular machine and you want to leverage platform specific instructions, so thats why intrinsics (or hell, even externally linked blobs written in asm) is the way to go and C supports that just fine.

But sure, if all youre doing is dot products I guess you can write a standard function that will work on most simd platforms, but who cares, use a linalg library instead.

Not any different from C - a given C compiler + platform will behave completetly deterministically and you can test the output and see what it does, regardless of UB or not.

How does the rust compiler assure that when compiling to machine code? Machine code is less safe than C after all.

Or it could be made faster because certain manual optimizations become possible.

An example would a table of interned strings that you wanna match against (say you're writing a parser). Since standard C says thou shall not compare pointers with < or > unless they both point into the same 'object' you are forbidden from doing the speed of light code:

  char *keywords_begin, *keywords_end;
  if(some_str >= keywords_begin && some_str < keywords_end) ...

Official standard sanctioned workarounds would require extra indirection (using indices for example) which is suboptimal.

You dont need UB for that.

A simple model for both compilers and programmers to understand:

"A variable whose address has not been taken need not be reachable via a random pointer".

I mean that's how an assembly programmer would think - if I put something in r0 I don't expect a store instruction to clobber it.

Just make a non null checking version: GetPixelUnsafe() and let the responsibility onto the user to do the null check before the loop.

All of these 'problems' have simple and straigtforward workarounds, I'm not convinced these UB are needed at all.

Then use the register keyword or just reword the standard to assume the register behavior if a variables address hasn't been taken.

The majority of useful optimizations can be kept in a "Sane C" with either code style changes (cache stuff in local vars to avoid aliasing for example) or with minor tweaks to the standard.

Since FILE io is part if standard C I guess you could do a plan9-style interface where you fopen("framebuffer"); and fwrite() means writing a pixel value to the screen. Since io is always implementation defined anyway, it wouldnt be any less portable than when you do printf("some string") and 'expects to see a string somewhere'.

Global warming.

These days it should be considered immoral to write software that uses inefficient languages/runtimes/abstractions, we simply cannot afford to waste energy doing useless computations anymore.

The thing is that modern computer architecture strikes again - like the old linked list vs array thing.

Doing a candidate loop over a bounding box with edge equations can be much faster than ye old scanline algorithm because it lends itself more easily to simd and parallel approches - you can divide things up into tiles and process multiple pixels at a time with wide instructions and schedule tiles on multiple threads.