Re: The future of i486 arch in Th

2014-12-15 Thread Jan Rękorajski
On Mon, 15 Dec 2014, Jeffrey Johnson wrote: > I'm more interested in the lowest common denominator Intel architecture. > > Specifically: > Can RPM assume sse2 instructions and optimize digests/crypto to use > sse2? No 32bit AMD CPU has this. So, no, you can't do it unconditionally. We're

Re: The future of i486 arch in Th

2014-12-30 Thread Tomasz Pala
+1 to abandoning i486 in current state (keeping last packages on FTP). On Mon, Dec 15, 2014 at 21:48:03 +0100, Jan Rękorajski wrote: >> Specifically: >> Can RPM assume sse2 instructions and optimize digests/crypto to use >> sse2? > > No 32bit AMD CPU has this. So, no, you can't do it uncon

Re: The future of i486 arch in Th

2014-12-30 Thread Jan Rękorajski
On Tue, 30 Dec 2014, Tomasz Pala wrote: > +1 to abandoning i486 in current state (keeping last packages on FTP). > > On Mon, Dec 15, 2014 at 21:48:03 +0100, Jan Rękorajski wrote: > > >> Specifically: > >>Can RPM assume sse2 instructions and optimize digests/crypto to use > >> sse2? > > > >

Re: The future of i486 arch in Th

2014-12-30 Thread Tomasz Pala
On Tue, Dec 30, 2014 at 20:22:01 +0100, Jan Rękorajski wrote: > If we have i686 arch we need to support i686 CPUs, not a random subset. We don't "need" to do anything. SSE2 is 13 years old now (and available for 11 years in AMD), I haven't seen unsupported CPUs in years. Hardware produced in tha

Re: The future of i486 arch in Th

2014-12-30 Thread Light-I
W odpowiedzi na wiadomość z dnia 30.12.2014, 22:33, od Tomasz Pala: Running i686 without modern extensions is a waste of resources. Creating x32 is a waste of resources (this won't ever be generic purpose arch). Let's drop i686 as well and call this i686+, i686_with_SSE2 or whatever you like if i

Re: The future of i486 arch in Th

2014-12-31 Thread Tomasz Pala
On Wed, Dec 31, 2014 at 01:04:29 +0100, Light-I wrote: > Się zastanawiam czy gałąź x86_64 zawiera SSE??? 32 bity używam tylko do wine, > bo SSE i SSE2 są rozszerzeniami do IA-32, w AMD64 (skoro Intel się wepchnął w nazwę IA, to oddajmy firmie AMD co się im należy) instrukcje są natywne. Dopiero

Re: The future of i486 arch in Th

2014-12-31 Thread Jacek Konieczny
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 > nie być dla SSE, bo o ile się nie mylę (a chciałbym), to i686 w PLD nie > korzysta nawet z pierwszej, 15-letniej wersji SSE. [...] > Może miało to uzasadnienie kilka lat temu, może

Re: The future of i486 arch in Th

2014-12-31 Thread Tomasz Pala
On Wed, Dec 31, 2014 at 12:52:56 +0100, Jacek Konieczny wrote: > Historia komputeryzacji i stan obecny opisałeś ładnie, a jesteś w stanie > rzucić konkretami? Co na włączeniu SSE zyskamy? Teoretycznie: dodatkowe rejestry XMM (żałosnej liczby rejestrów IA-32 nie trzeba chyba wyjaśniać). Ufając np.

Re: The future of i486 arch in Th

2015-01-01 Thread Tomasz Pala
OK, trochę więcej dot. tematu. Sprawdziłem sobie na takim xz i zysku nie zaobserwowałem (jedyny przyrost wydajności daje -O3), ale wydaje mi się to całkiem logiczne. Znacznie mniej logiczne, że -march=native daje mi gorszy wynik, niż i686... Wyszukałem, że openssl ma detekcję runtime. Jest libjpeg-

Re: The future of i486 arch in Th

2015-01-01 Thread Tomasz Pala
On Thu, Jan 01, 2015 at 11:45:44 +0100, Tomasz Pala wrote: > Pytanie zatem brzmi: czy glibc ma detekcję runtime? Sądząc po takich [...] > to nie ma. Zresztą grep __SSE na źródłach to potwierdza (albo nie umiem > tego poprawnie odczytać). > > $ ls **/*86/**/*sse2.* | wc -l > 46 > > pokazuje skalę

Re: The future of i486 arch in Th

2015-01-01 Thread Adam Osuchowski
Jacek Konieczny wrote: > To byłoby wypięcie się na niektórych (owszem, pojedynczych) użytkowników > w pogoni za numerkami. Taaa? A jeszcze niedawno twierdziłeś, że nie ma po co utrzymywać /etc/env.d/GREP_OPTIONS lub jego funkcjonalnego odpowiednika w postaci aliasa, tylko dla pojedynczych użytkown

Re: The future of i486 arch in Th

2015-01-01 Thread Light-I
W odpowiedzi na wiadomość z dnia 01.01.2015, 23:30, od Adam Osuchowski: BTW, czy mogę się ostatecznie dowiedzieć jaki będzie los innych aliasów ustawianych w /etc/shrc.d/*? Dlaczego jedne aliasy mogą być narzucane użytkownikowi przez system, a inne nie (pomimo, że każdy z nich można przecież nadp

Re: The future of i486 arch in Th

2015-01-01 Thread Jacek Konieczny
On 2015-01-01 23:30, Adam Osuchowski wrote: > Jacek Konieczny wrote: >> To byłoby wypięcie się na niektórych (owszem, pojedynczych) użytkowników >> w pogoni za numerkami. > > Taaa? A jeszcze niedawno twierdziłeś, że nie ma po co utrzymywać > /etc/env.d/GREP_OPTIONS lub jego funkcjonalnego odpowied

Re: The future of i486 arch in Th

2015-01-02 Thread Adam Osuchowski
Jacek Konieczny wrote: > Jest chyba różnica między niezdefiniowaniem jakiegoś podejrzanego > aliasa, którego każdy, kto potrzebuje, może sobie sam ustawić, a > skompilowaniem całej dystrybucji tak, że u niektórych nawet nie > zabootuje, o ile ktoś sobie całości dla swoich potrzeb nie przekompiluje.

Re: The future of i486 arch in Th

2015-05-11 Thread grapeli23
Dnia 31.12.2014 Jacek Konieczny 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