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@xxxxxxxxxxxxxxxxxxxxxxx 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