>>23AMD and nVidia have been shitting up the constellation of all the standards they care about by introducing oddball features they hope will give them an edge over the other. If Intel drives Vulkan I think we'll get a better interface out of it.
Intel's GPU stuff is better than I used to think it was. Their drivers are getting better too. Vulkan is the right thing to do. That die space isn't going to do as much good going to CPU cores as it would going to a highly parallel compute system. You don't need to run graphics on it, and with Vulkan the hope is doing GP compute on it will become more common. Of if you don't have IGP or want to shove it off to your DGPU, a cat is fine too.
>>24The program code, you fartknocker
If you can't resolve a variant in the interface you have a big problem, like not being able to tell which variant the interface gave you.
>>14,24oh wwwwww
I didn't comment on this the first time around but I doubt there is any ADT-specific 'smartness' built into the optimizer that would cover this. In the case at hand, the perf cost isn't so much in checking the value as it is in repackaging it, then checking it
again. But maybe this could optimize very nicely:
enum FooBar {
Foo(footype),
Bar(bartype),
}
#[inline(always)]
fn check_variant(foobar: some_c_struct) -> FooBar {
match garbage.tag {
FOO => Foo(foobar.value),
BAR => Bar(foobar.value),
_ => unreachable!()
}
}
fn uses_check_variant(...) {
// ...
match check_variant(foobar) {
Foo(foo) => {...},
Bar(bar) => {...},
}
// ...
}Since the patterns correspond well, the constructed variants don't outlive the match block and the code will be inlined, the optimizer should be able to rewrite it so that the code in the match arms replaces the variant constructors in
check_variant().
You would probably also stick
check_variant(); in an impl for
some_c_struct so the check would just look like:
match foobar.check_variant() { ... }.
What's more, I haven't kept up on the ins and outs of
Deref and it is probable implementing
Deref for
some_c_struct could turn that match into this:
match foobar { ... }. That's fucking slick, yeah?
This is a reasonable optimization, subject to the constraints above. If it doesn't exist in rustc/llvm, you could file an issue on it and be confident someone will take it seriously. This pattern should perform as well as (or better than) the C code that forces the programmer to do case analysis on the descriminant directly.