Am 12.02.2013 18:33, schrieb Tom Horsley:
> On Tue, 12 Feb 2013 17:37:06 +0100
> Reindl Harald wrote:
> 
>> you can not do this because you can hardly deploy packages
>> built this way on a i7-3770 (Ivy Bdrige) to a Xeon E5640
>> which is Westmere architecture without ending in "unknown
>> CPU instruction" and random crashes and in the worst case
>> this will hit you due vMotion if the host where you started
>> a guest has the newer instructions and the target machine
>> not - if this happen due failover you are done at all
> 
> Ahh, but that sort of thing is what the GNU "indirect
> function" relocation code is all about. You can build
> libraries which decide at runtime which version of a
> routine to call and include multiple architecture variants
> of routines.
> 
> That makes it possible to have dozens of different versions
> of routines, only one of which has a bug so it only fails
> on certain architectures. Such a helpful feature :-)

besides you missed the "why not use -mnative" this would
blow up your binaries - in case of having 30 virtual machines
and 7 workstations with which makes 9 hosts and none of them
is older than 2 years you want to optimize in speed and size
by prefer speed but not for all prices

and i doubt that the feauture will not 100% work with any
generic software like mysql, httpd, dovecot, dbmail, openssl
which are a subset of my self-compiled RPM packages

in case of PRODUCTION you should prefer a good compromise
between performance, maintaince work and stability and
avoid risk the latter

additionally in case of vMotion/Failover you also need
EVC* and so the more optimized code would not be used
on the SandyBdridge Host as long you have a Westmere
CPU in the cluster, but it may happen that you build
RPMs on a physical machine with IvyBrdige in a testing
environment before a dist-upgrade with the target to
roll them out on the cluster later - here you would not
have EVC

*
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1005764



Attachment: signature.asc
Description: OpenPGP digital signature

-- 
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org

Reply via email to