What Every Programmer Should Know About Memory (2007) [pdf]

Post by scoutt » Tue, Mar 05, 2019, 8:48 AM UTC

saberience wrote: post #19

mbauman wrote: post #17

Earlier quoted context omitted.

Indeed, there are a limited number of hard-hitting topics that are definitely must-haves: * Rough latency timings * Caching * Prefetching * Sequential vs. random access * N-dimensional layouts (row/column major and arbitrarily strided) * Design of cache-oblivious algorithms * SIMD-able access patterns * False sharing * Instruction cache & code size * Branch prediction and speculative execution I'd be curious to hear…

Again, you say these are "must haves." But in the real world of software, none of these would make any difference to most of the software being built today, much of which is being build in higher level languages for web applications/web sites/microservices etc. Let's say someone is building a micro-service in C#.Net. Why would any of this stuff matter to them? The company cares about features and moving forward quick…

Post by gdy » Tue, Mar 05, 2019, 12:02 PM UTC

saberience wrote: post #69

nickpsecurity wrote: post #56

Earlier quoted context omitted.

The referenced work talks about floating point errors that both computer scientists and field engineers need to avoid. Many folks in both camps screw up on floating point code without such guidance. So, at least that part is potentially helpful. You just proved their point about how you'd reply, though.

Proved their point? Their point didn't make much sense. What actual engineers NEED to know about floating point numbers could be put on a single A4 page. It doesn't have to be 50 pages, where many of those pages are full of equations that 99% of engineers don't understand. My point is, because you seem to have trouble grasping this. Most real-world programmers, working at startups or bigger companies, making their WP…

Post by drainyard » Tue, Mar 05, 2019, 12:34 PM UTC

Chlorus wrote: post #35

mhh__ wrote: post #28

Earlier quoted context omitted.

Because knowing your craft is important? Besides, if you don't find this interesting why become a programmer in the first place

There's a lot to learn about this craft, and people have to prioritize - knowing algorithms & data structures is more immediately useful compared to, say, knowing what scratchpad memory is. If I spent my time learning every detail about every system underpinning every abstraction, I would literally be 70 years old by the time I started writing code. > Besides, if you don't find this interesting why become a programme…

Post by drainyard » Tue, Mar 05, 2019, 12:36 PM UTC

blakehaswell wrote: post #81

For an accessible talk about the real-world implications of this, I enjoy watching Mike Acton's CppCon talk "Data-Oriented Design and C++": https://www.youtube.com/watch?v=rX0ItVEVjHc

Post by dragontamer » Tue, Mar 05, 2019, 6:00 PM UTC

gdy wrote: post #94

esmi wrote: post #60

Earlier quoted context omitted.

I have to admit, I was skeptical but my complier did pick SIMD for the second and not the first and it did make a huge difference. % cat t.c #include #include #include double get_time() { struct timeval t; struct timezone tzp; gettimeofday(&t, &tzp); return t.tv_sec + t.tv_usec*1e-6; } int blah[SIZE][SIZE]; int whatever() { static int i=0; return ++i; } int main() { double t0 = get_time(); for(int i=0; i 2.8G Core i7…

Now you could try to time it with -fno-tree-vectorize or whatever gcc uses nowadays. You might be surprised again :)