John Andersen said the following on 07/23/2013 02:47 PM:
[....]
Moving the text body of the email from the the file to your screen was probably handed over to a string move operation. If the compiler writer did his work properly, the compiler will use 64bit registers to move that string, resulting in fewer actual load/store operations, and those operations (typically) operate in the same number of clocks. So fewer moves happening at the same speed = much shorter execution time.
You're going to have to explain that in more detail because as it is it doesn't make sense to me. I can see three cases: First, the old, old way where the OS got the disk driver or network driver to read the 'mail file' body into buffer memory and then copy that buffer into 'user space'. I recall the old PDP-11 UNIX 7 code for this kind of thing. while (i--) { *p++ = *s++' } Or the assembler equivalent. Later there was the hand coded "block move instruction" involving three registers, counter, source pointer, destination pointer. But it amounted to the same thing, just done in microcode rather than macrocode. Second came virtual memory. Still read into the buffer, but now there was a fiddle with the mapping tables and now LO! that memory is now addressable in user space. No move needed. Third, is what I think you are talking about and I must say it makes no sense to me. A 64-bit register has 8 bytes, a 32-bit register has 4 bytes and a 16-bit register has 2 bytes. Back in the old days of 8-but machines a 'move' involved reading a byte from memory into a register from one location into a register and writing it out to another. Part of the reason for this was that (a) such systems didn't have virtual memory to do by remapping and (b) the limited instruction sets didn't support memory to memory operations. So if you are caught up in this programming paradigm when you graduate to 16-but you do the same thing two bytes at a time and with 32-but machines four bytes at a time and with 64-but machines, eight bytes at a time. But the reality is that while with UNIX we do a lot of character manipulation, its never as blunt as that. If we are operating on strings we can't assume that are a multiple of eight bytes long. And they are going to be null terminated, so we see a lot of while (*p != '\0') { .... We might also be looking for membership of sets of characters: numbers, alpha, punctuation ... But even when we do see that the string runs from there to there, why stuff it into a register or register bank? Even if we are thinking for some reason of manipulating a string 8 characters at time the cost of coming up with the necessary 'masks' and the dealing with the 'residual' part of the string is going to be computationally more expensive. And the algorithm ... oh my, I'd hate to have to debug that! I'm a believer in KISS. Perhaps, John, you were thinking of something different from what I've thought of. If so, please do explain.
Like I mentioned, its taken years for the compiler writers to catch up, so results have changed over time.
Yes, on many projects I've taken the architects to task about their instructions about programming style by showing that the output from the compiler makes a mockery of what they were envisioning. I recall one project where they waxed on about absolute addressing and efficiency of access. The only thing was that the C compiler for the VAX, and I found alter the FORTRAN compiler as well, had the concept of a 'global data segment pointer' and all the variable you thought were being addresses at absolute locations were actually indexed off this pointer. And the pointer was in the outermost calling frame of the stack, in the start-up code before "main()" was called, and was loaded, when needed, into a register, by indexing of the calling frame nesting pointer. The compiler was smart, though. It only loaded the global data segment pointer into a register when and if you needed to access a global variable, and was very good about leaving it there and not 'dumping' it unless the computational demands for a register exceeded what was otherwise unused. Some compilers are smarter than programmers. Call them "expert systems in code generation". -- The truth of a proposition has nothing to do with its credibility. And vice versa. Excerpt from the notebooks of Lazarus Long, from Robert Heinlein's "Time Enough for Love" -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org