• 0 Posts
  • 11 Comments
Joined 2 years ago
cake
Cake day: June 25th, 2023

help-circle




  • Write-up is highly Windows-centric (though not irrelevant elsewhere).

    One thing that is regretfully ignored in discussions of async, tasks, green threads, etc. is that there is no support/consideration for native (reliable/efficient) thread-local variables. If you’re lucky you’ll get a warning about “don’t use them”.


  • Then - ignoring dunders that have weird rules - what, pray tell, is the point of protocols, other than backward compatibility with historical fragile ducks (at the cost of future backwards compatibility)? Why are people afraid of using real base classes?

    The fact that it is possible to subclass a Protocol is useless since you can’t enforce subclassing, which is necessary for maintainable software refactoring, unless it’s a purely internal interface (in which case the Union approach is probably still better).

    That PEP link includes broken examples so it’s really not worth much as a reference.

    (for that matter, the Sequence interface is also broken in Python, in case you need another historical example of why protocols are a bad idea).


  • chunks: [AtomicPtr>; 64], appears before the explanation of why 64 works, and was confusing at first glance since this is completely different than the previous use of 64, which was arbitrary. I was expecting a variable-size array of fixed-size arrays at first (using something like an rwlock you can copy/grow the internal vector without blocking - if there was a writer, the last reader of the old allocation frees it).

    Instead of separate flags, what about a single (fixed-size, if chunks are) atomic bitset? This would increase contention slightly but that only happens briefly during growth, not accesses. Many architectures actually have dedicated atomic bit operations though sadly it’s hard to get compilers to generate them.

    The obvious API addition is for a single thread to push several elements at once, which can be done more efficiently.




  • o11c@programming.devtoPython@programming.devProtocols in Python
    link
    fedilink
    English
    arrow-up
    0
    arrow-down
    1
    ·
    2 years ago

    In practice, Protocols are a way to make “superclasses” that you can never add features to (for example, readinto despite being critical for performance is utterly broken in Python). This should normally be avoided at almost all costs, but for some reason people hate real base classes?

    If you really want to do something like the original article, where there’s a C-implemented class that you can’t change, you’re best off using a (named) Union of two similar types, not a Protocol.

    I suppose they are useful for operator overloading but that’s about it. But I’m not sure if type checkers actually implement that properly anyway; overloading is really nasty in a dynamically-typed language.


  • I likewise don’t really use Godot, but for graphics in general, the 4th coordinate is important, even if it is “usually” 1. It’s most obvious to correctly interpolate near the poles of a sphere with a single rectangular texture, but think for a minute what “near” means.

    Back to the main point though: the important things we normally rely on for matrix math are associativity (particularly, for exponentiation!) and anticommutativity (beware definitions that are sloppy about “inverse”).