Dnia 31.12.2014 Jacek Konieczny <[email protected]> napisał/a: > On 31/12/14 12:03, Tomasz Pala wrote: > >> Większości z tego nawet nie znam, kluczowe wg mnie jest w ogóle być albo > > [...] > >> Może miało to uzasadnienie kilka lat temu, może miało w czasach, gdy GCC > > Historia komputeryzacji i stan obecny opisałeś ładnie, a jesteś w stanie > rzucić konkretami? Co na włączeniu SSE zyskamy? Np. benchmarki kilku > procesorożernych aplikacji, czy coś, pozwoliłyby świadomie podjąć > sensowną decyzję. > > IMHO nie ma sensu porzucać kompatybilności nawet z antykami, jeżeli > dzięki temu zyskamy 1% wydajności w 5% zastosowań. To byłoby wypięcie > się na niektórych (owszem, pojedynczych) użytkowników w pogoni za > numerkami. > > I czy nie jest tak, że w zastosowaniach, w których ma to największe > znaczenie, detekcja i wykorzystanie specjalnych funkcji procesorów jest > załatwiane „on runtime”? Przynajmniej kiedyś tak ze wszelkimi codekami > było. > > Pozdrawiam, > Jacek
Szkoda. Głównym argumentem za pozostawieniem kompatybilności jest to że takową zapewnia kernel, glibc i gcc. Torvalds po uśmierceniu i386, wypowiadał się że nie jest aż tak sentymentalny. http://lkml.iu.edu/hypermail/linux/kernel/1212.1/01152.html Fakt że ilość użytkowników potrzebujących tego wsparcia jest znikoma. Choć nie są to wyłącznie tylko tacy którzy odnaleźli sprzęt na strychu dziadka. Nawet Intel wypuścił serię Galileo z procesorem pozbawionym instrukcji MMX i SSE. https://en.wikipedia.org/wiki/Intel_Quark Oczywiście od dawana istnieją programy które działają tylko na Pentium Pro i nowszych. Przykładowo Webkit (konkretnie JavaScriptCore), Go (backend gcc działa poprawnie), LuaJIT. _______________________________________________ pld-devel-pl mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
