[Vm-dev] linux build stability

[John M McIntosh]

I recall reading a paper back in the early 2000 era about Google's finding as they were the first folks to build out extremely large linux based server farms.
Their comment was even tho we ordered oh say 1000 machines from vendor X and they were technically "identical" and we ran the same bit identical software we found that there was always a few percent that behaved differently.  Due to issues with hard drive, memory, or the fact the vendor changed suppliers for some particular week, karma or cosmic rays?   

The uptake was even if two machines were the "same" and the software bit identical, behaviour might be different. Sometimes this was explainable, other times, Karma? 


On 2011-02-02, at 12:35 PM, Eliot Miranda wrote:

> 
> 
> On Wed, Feb 2, 2011 at 11:39 AM, David T. Lewis <lewis at mail.msen.com> wrote:
> Sorry to keep replying to myself, but one more followup. In each case
> for which differences exists after stripping the symbol table, the
> difference is due to a date stamp string.
> 
> In the case of sqUnixMain.c, it is the VM_BUILD_STRING macro used in
> getAttribute(). The version.c file contains also a date string. Both
> of these date strings are created by configure. After accounting for
> these and after stripping the the symbol tables, I see no remaining
> differences in executable code.
> 
> I can't explain why the compiler might generated different symbol
> tables, but given that the resulting executables end up being identical
> except for the date string macros, this does not look like an issue
> that would affect run time stability.
> 
> Agreed.  Looking more carefully this morning using -save-temps to save the post-processed .i and output .s I see that all differences are valid.  Thanks David!
> 

--
===========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com>   Twitter:  squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110202/32d6bcf6/attachment-0001.htm