On Oct 30, 2015, at 11:35 AM, Paul Koning
<paulkoning at comcast.net> wrote:
On Oct 30, 2015, at 2:16 PM, Noel Chiappa <jnc
at mercury.lcs.mit.edu> wrote:
...
Apparently nobody had ever told them that a number in memory is... just a
number. At which point it became clear that they needed to know a little
more about how a computer actually worked.
That reminds me of an exchange I had with a younger colleague who was writing a document
describing how to do incremental TCP checksum update correctly. He was tripping over the
issue of negative zero. I told him the answer simply was to subtract the complement with
end around borrow. He didn't believe me and ended up proving it by exhaustively
testing every case.
My favorite of this class of issues, was when I was working at a startup doing an
embedded product with Linux as the OS. We all had Linux machines for building/testing. I
was responsible for the Linux kernel at the company. I had someone come up to me and said
?the VM system is broken?my program works fine on my desktop but I keep getting page
faults on the embedded platform?. The conversation was something like this:
Me: So, what?s the program doing memory wise?
Him: I allocate an array of structures and I read them off of disk into the array.
Me: How big are the structures?
Him: About 4K
Me: How many are you allocating?
Him: 100,000
Me: Rolls eyes. That?s 4GB. We don?t have 4GB on the embedded platform. You don?t even
have that on your workstation.
Him: But it works there and not on the embedded platform.
Me: We don?t have paging turned on in the embedded platform.
Him: Can?t we turn it on? It makes my code so simple!
Me: No! Go allocate a *reasonable* sized array (say 100) and shuffle in from the disk
when the data you need isn?t there. You walk the data structure mostly sequentially
anyway, so there?s no reason to have the entire file in memory.
I still think a 3 tape sort should be a required early assignment (learn that not
everything can fit into memory at once).
TTFN - Guy