Dnia 31.12.2014 Jacek Konieczny jaj...@jajcus.net 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
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.
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
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ż
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 odpowiednika w
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ę strat
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
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
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
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.
+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
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?
No 32bit AMD
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 that
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
14 matches
Mail list logo
