Mmm, fairly limited gain from going from
FnOnce for 0 | 1 calls
FnMut for 0..X calls
Fn for 0.. calls
to
Fn [X] for 0..X calls
because while the X is hidden in FnMut you can wrap Option and return Some until None.
Conversation
I'd say you'd want something more like:
Fn [0..1] for FnOnce
Fn [0..] for Fn
Fn [0.., Unique] for FnMut (not sure about this one)
This would also give you other stuff, like:
Fn [1] for a closure that *must* be used
1
1
But yeah, there are lots of unknowns, but I'd encourage you to look at some of the Granule demos that show some of the automation and error checking you get from the more precise types
1
1
Found an old talk that might be of interest! Sorry if I sound like I'm shilling this stuff pretty hard – there is a bunch of stuff that would need to be done to make this work for systems programming, but I think it seems promising!
1
1
Explain to me how it would help me make a more-correct compiler to assembly or a better API for SIMD or floating point.
1
1
I'm not sure about the specifics of SIMD, but I think there are levels of SIMD support for different processors? You could that support as part of the API, and ensure that certain properties have been checked for before calling certain ops.
1
1
I already have adequate solutions for that, actually, and a compiler is unlikely to place the check patterns correctly because that depends on out-of-band information, so it is fine to insist the programmer do so.
You see, in today's world you need to account for code mobility.
1
1
That, or you need to simply make it UB to move from machine with higher feature levels to a lower feature level.
But it would be totally unacceptable to make the check before every call in to a SIMD function. It's enough to make the choice based on entering the right scope.
1
1
I'm not talking about checking on every call, I'm talking about ensuring that you a calling in a context where the check has previously been made 😅
2
1
Current compiler analyses and programming idioms really are good enough tho', if it can't actually magically find and set the right CPUID checks at exactly the right places then why bother /s
and it's actually worse because each architecture has its own model for SIMD execution.
2
1
Fair enough! As I say I don't know the specifics of this situation (I realise things like SIMD can be fraught the more you look into it), and I'm certainly naive here. I'm curious about the issues and if we can do better, but I understand if you are fine with the status quo. 😅
well like,
x86-64 has 128, 256, or 512 bit registers.
Arm Neon has 128 bit registers.
Arm SVE2 will have 128 * N bit registers.
RISCVV allows vector registers to have almost any length starting at 32 bits.
And users don't care about this and want their program to "just work".
1
1
They don't really wanna write a lemma about program validity for each different architecture, y'see, and each of these arches has subtly different rules about how these instructions are legalized and so on, but they want the maximum perf the hardware affords anyways.
1
2
Show replies