Comments by "Lepi Doptera" (@lepidoptera9337) on "arrays are weird" video.

  1. The linker will tell you. It's a bit more complicated than that, of course, because not every program on a multi-tasking machine can have the same memory sections mapped to the same hardware address, so what the linker actually tells you is a symbolic address that merely points to the entry in the memory management unit, which then translates that to the physical hardware address that the CPU puts onto the address bus. Even that is a multi-stage process on modern CPUs because the L1 and L2 caches are still between your program and the actual memory. So instead of grabbing the data from the main memory, the machine will try to get it from L1 first, if that fails from L2 and if that fails it will reload the caches from the main memory. Word to the wise: you really, really, really don't want that to happen because your 5.3GHz racer then basically falls back to the speed of an 80 MHz CPU or so... because the CAS latency on DDR4 is still on the order of 12.5ns! I used to have faster (but much, much smaller) memory than that on one of my boards in 1995... so we have been basically standing still with regards to board level memory access times for like 30 years now. Chip level memory is orders of magnitude faster now, of course, so try to write your program in such a way that it doesn't jump around in memory too much so that the multi-level caching strategy can actually perform its miracles.
    2
  2. He talks about the C implementation. Yes, a first semester CS student learning about linked lists for the first time will probably feel a strong urge to implement an array in that way. One should teach such students a lesson by giving them an F. :-)
    1
  3.  @aeebeecee3737  Let's put it this way... non-contiguous implementations of non-sparse arrays on machines without MMU (involvement) are a really, really bad idea, from a performance point of view. If you are looking at an array only as an access interface, then the implementation doesn't matter, of course. Few software developers have the option so say "performance is irrelevant".
    1
  4. C is basically just a smidgen of syntactic sugar on top of what your CPU instruction set does (that's why it does not hide endianness, for instance, because that would be an awfully inefficient thing to do on CPUs that have the "wrong" bye order). It requires you to think at least a little bit about the hardware that your program runs on. Not too much, just enough to make you a really good programmer over time. If you are trying to avoid that level of knowledge, then you will always stay a mediocre programmer because performance is, whether we like this or not, hardware dependent. Not saying you can't get around low level stuff most of the time by using optimized libraries and LLVM, but nobody ever died from looking underneath the hood of their car.
    1
  5. You can make the same argument for -17 based indexing. ;-)
    1