What's new in CPUs since the 80s and how does it affect programmers?
1–10 of 72 posts
Re: What's new in CPUs since the 80s and how does it affect programmers?
#2This is a wonderful post that no-one will care about. This may be the only post.
Today, programmers are more interested in the rate they can turn out "Just Works" code. These kinds of details are fare fare to down in the weeds for a continuous development artists.
Re: What's new in CPUs since the 80s and how does it affect programmers?
#3This is a wonderful post that no-one will care about. This may be the only post. Today, programmers are more interested in the rate they can turn out "Just Works" code. These kinds of details are fare fare to down in the weeds for a continuous development artists.
> This is a wonderful post that no-one will care about. This may be the only post.
I think you are underestimating the crowd here. Last time it was posted it got quite a few responses: https://news.ycombinator.com/item?id=8873250 (already a while back, but might be interesting for reference/to bring topics up again)
Re: What's new in CPUs since the 80s and how does it affect programmers?
#4"However, loads can be reordered with earlier stores. For example, if you write
mov 1, [%esp]
mov [%ebx], %eax
mov [%ebx], %eax
mov 1, [%esp]"
Re: What's new in CPUs since the 80s and how does it affect programmers?
#5It's strange the extent to which programming interview questions reflect an 80s view of the cost of operations, particularly the overabundance of linked list and binary tree questions. Cache misses ain't free and memory scans are relatively cheap after you do the initial lookup.
Re: What's new in CPUs since the 80s and how does it affect programmers?
#6"However, loads can be reordered with earlier stores. For example, if you write mov 1, [%esp] mov [%ebx], %eax it can be executed as if you wrote mov [%ebx], %eax mov 1, [%esp]" The confusing mix of Intel and GAS/AT&T syntax aside, this is not possible since it would give different results when ebx == esp.
It's not a static decision though - the memory accesses can still be reordered when %ebx != %esp, though of course this only ends up visible where there are multiple CPUs involved.
For example, consider the case above and assume that the initial conditions are:
(%esp) == 0
(%ebx) == 0
mov $1, (%ebx)
mov (%esp), %eax
Re: What's new in CPUs since the 80s and how does it affect programmers?
#7This is a wonderful post that no-one will care about. This may be the only post. Today, programmers are more interested in the rate they can turn out "Just Works" code. These kinds of details are fare fare to down in the weeds for a continuous development artists.
Two responses. First, once we find "Just Works" components that we like then they can be optimized. Second, we can use inspiration from articles like this to describe "Just Works" approaches and patterns that "go with the grain" of what Earth's real fabrication capabilities are actually producing.
For example, I found the discussion of how cores coordinate access to main memory on a shared bus to be quite fascinating; an easy insight there was that our programming patterns should support hard data partitions (less shared main memory than parallel main memory). One naive way to get there is to use N processes where N is something like the number of cores on the machine, and one of them serves as a message router. Something like what `httpd` does.
I really wouldn't mind if someone who knows more about the JVM implementation could talk about how and why the JVM threading model is better than native processes, for example, especially in light of memory contention.
Re: What's new in CPUs since the 80s and how does it affect programmers?
#8"However, loads can be reordered with earlier stores. For example, if you write mov 1, [%esp] mov [%ebx], %eax it can be executed as if you wrote mov [%ebx], %eax mov 1, [%esp]" The confusing mix of Intel and GAS/AT&T syntax aside, this is not possible since it would give different results when ebx == esp.
It's not a static decision though - the memory accesses can still be reordered when %ebx != %esp, though of course this only ends up visible where there are multiple CPUs involved. For example, consider the case above and assume that the initial conditions are: (%esp) == 0 (%ebx) == 0 Now imagine we have a second CPU executing simultaneously, with the same %ebx and %esp as the first CPU, but executing this: mov $1, (…
You're correct about it being possible for other CPUs to see "crossed" loads/stores, but within one CPU/stream of instructions the programmer-visible ordering is absolutely preserved, because if it wasn't, a lot of existing software would break. In your example, if ebx == esp, and both CPUs executed those two instructions, then they must both see eax == 1. I think you had this scenario in mind instead (where A and B are different memory locations):
CPU 1:
mov $1, (A)
mov (B), %eax
mov $1, (B)
mov (A), %eax
Re: What's new in CPUs since the 80s and how does it affect programmers?
#9Who is Dan Luu? Does he have expertise in this area? Is he a leading expert? (No offense to Dan if he is reading this; I just don't know.)
Re: What's new in CPUs since the 80s and how does it affect programmers?
#10Earlier quoted context omitted.
It's not a static decision though - the memory accesses can still be reordered when %ebx != %esp, though of course this only ends up visible where there are multiple CPUs involved. For example, consider the case above and assume that the initial conditions are: (%esp) == 0 (%ebx) == 0 Now imagine we have a second CPU executing simultaneously, with the same %ebx and %esp as the first CPU, but executing this: mov $1, (…
You're correct about it being possible for other CPUs to see "crossed" loads/stores, but within one CPU/stream of instructions the programmer-visible ordering is absolutely preserved , because if it wasn't, a lot of existing software would break. In your example, if ebx == esp, and both CPUs executed those two instructions, then they must both see eax == 1. I think you had this scenario in mind instead (where A and B…
We are of course in violent agreement.
The point to note is that the decision on whether or not the reordering can occur, based on whether or not A and B are the same or not, is made dynamically at the point of execution.