5 ms·

> as the alignment padding had made for a bigger cache footprint I argues with some of the Rust compiler members the other day about wanting to just ditch almo

• ncmncm 5y ago
  Superstition is as powerful as it ever was.
  • MBCook 5y ago
    Is this superstition or more received wisdom, which may have been true at one point in the past as is now just orthodoxy?
    • notriddle 5y ago
      Fifty bucks says it isn't even about performance, but is instead about passing pointers to C code. Zero-overhead FFI has killed a lot of radical performance improvements that Rust could have otherwise made. I don't know, because nobody's actually posting a link to it.
      • ncmncm 5y ago
        This strikes me as likely. Bitwise compatibility with machine ABI layout rules has powerful compatibility advantages even in places where it might make code slower. (And, for the large majority of code, slower doesn't matter anyway.) Of course C and C++ themselves have to keep to machine ABI layout rules for backward compatibility to code built when those rules were (still) thought a good idea. Compilers offer annotations to dictate packing for specified types, and the Rust compiler certainly also offers such a choice. So, maybe such annotations should just be used a lot more in Rust, C, and C++. This is not unlike the need to write "const" everywhere in C and C++ because the inherited default (from before it existed) was arguably wrong. We just need to get used to ignoring the annotation clutter. But there is no doubt there are lots of people who think padding to alignment boundaries is faster. And, there can be other reasons to align even more strictly than the machine ABI says, even knowing what it costs.
      • nynx 5y ago
        Rust structs have non-C layouts. You can optionally specifiy that a struct should be laid out in the same way that C does it.
        • ncmncm 5y ago
          People arguing against changing struct layout rules are probably mainly interested, then, in maintaining backward compatibility with older Rust, itself. Anyway, same policy applies: annotate your structs "packed" anywhere performance matters and bitwise compatibility with other stuff doesn't.
          • deleted 5y ago
            [deleted]
          • zozbot234 5y ago
            Rust does not keep backward compatibility like that. In the absence of any statement forcing a specific ABI, the only guaranteed compatibility is with code that's part of the same build, or else part of the current Rust runtime and being linked into said build.
            • ncmncm 5y ago
              Even in Rust, mapping memory between processes, or via files between past and future processes, happens. Although structure-blasting is frowned upon in some circles, it is very fast where allowed. But... when you are structure-blasting, you are probably also already paying generous attention to layout issues.
        • notriddle 5y ago
          Structs aren’t the problem here. It’s the primitives. You can take a pointer to an i32 and pass that pointer to C code as int32_t. This means it has to have the same alignment in Rust that it has in C.
          • ncmncm 5y ago
  • cryptonector 5y ago
    It's definitely received wisdom that may once have been right and no longer is. Most people are not used to facts having a half-life, but many facts do, or, rather, much knowledge, does. We feel very secure in knowing what we know, and the reality is that we need to be willing to question a lot of things, like authority, including our very own. Now, we can't be questioning everything all the time because that way madness lies, but we can't never question anything we think we know either! Epistemology is hard. I want a doll that says that when you pull the cord.
    • cogman10 5y ago
      Sort of depends on the knowledge. It's certainly true that in the tech industry things are CONSTANTLY shifting. However, talk physics and you'll find that things rarely change, especially the physics that most college graduates learn.
      • cryptonector 5y ago
        There was a famous study about the half-lives of "facts" in different fields. They do seem to vary by field.
• anyfoo 5y ago
  FWIW, it's still better to lay out your critical structures carefully, so that padding isn't needed. That way, you win both the cache efficiency and the efficiencies for aligned accesses.
  • mjevans 5y ago
    One of the forms of 'premature optimization' that's often worth doing. Just align everything you can to the biggest power of two data-size you can. Also, always use fixed sized data types. E.G. (modular int) uint32 or (signed 2s comp) sint32 rather than int
• kevingadd 5y ago
  There are other things you need to take into account too - padding can make it more likely for a struct to divide evenly into cache lines, which can trigger false sharing. Changing the size of a struct from 128 bytes to 120 or 122 bytes will cause it to be misaligned on cache lines and reduce the impact of false sharing and that can significantly improve performance. The last time I worked on a btree-based data store, changing the nodes from ~1024 bytes to ~1000 delivered something like a 10% throughput improvement. This was done by reducing the number of entries in each node, and not by changing padding or packing.
  • ncmncm 5y ago
    True. Another reason to avoid too much aligning is to help reduce reliance on N-way cache collision avoidance. Caches on modern chips can handle keeping up to some small fixed number, often 4, objects all in cache whose addresses are at the same offset into a page, but performance may collapse if that number is exceeded. It is quite hard to tune to avoid this, but by making things not line up on power-of-two boundaries, we can avoid out-and-out inviting it.
• titzer 5y ago
  WebAssembly ditched alignment restrictions and we don't regret it. There is an alignment hint, but I am not aware of any engine that uses it.