to neni bug. Pokud na adresovani potrebujes - a ty potrebujes, neb mas dvakrat vetsi sbernici - dvakrat vice bitu, tak se to zatracene projevi.
V jave na to vymysleli compressedops. Stoji za zheldnut.
Presne na tieto účely vzniklo x86_x32, samozrejme pre procesory x86_64. V kerneli má ešte stále podporu, ale podpora krížom cez disribúcie je prakticky nulová.
Skúšal som ju skompilovať na netbook s 2GB RAM (Gentoo), ale bohužiaľ. Rozbehal som Xorg server ale nepodarilo sa mi skompilovať žiaden prehliadač.
Pre Aarch64 o ničom podobnom neviem. Asi by to bolo veľmi dočasné riešenie, v mobile mám už 8GB RAM a RPI4 mám už tiež s touto porciou pamäte.
Já jsem na netbook s 2GB paměti instaloval normální 64-bitovou instalaci openSUSE už v létě 2010 a spokojeně ho používal dalších sedm let. Ale proti gustu žádný dišputát…
To neni v kontradikci. Notas mohl souzit a presto zrat o tretinu ci dve vice ram. Hold to mas bez balastu a nejsi narocny. Vim a flux box ?-)
JJ, podobne to ma AIX na PowerPC s exec formatem XCOFF. Oni prisli s 64bit modem jako jedni z prvnich a v te dobe se setril kazdy byte. A tak prisli s tim, ze jeden registr bude obsahovat pointer na zacatek sdilene knihovny a vsecha adresace v ramci te same knihovny je relativni vuci tomu base registru.
Jen aby se usetrilo misto a nemusely se pouzivat 64bit pointery na vsechno.
Pokud se spotreba pameti pri prechodu z 32b na 64b zdvojnasobi, tak to znamena, ze mas v RAMce prevazne pointery... Kde jsou pak vsechny ty data na ktery pointery ukazujou a jejichz velikost se nemeni pri zmene architektury??
(samozrejme neni neobvykly, ze se meni i jiny ciselny datovy typy, ktery jsou v C definovany jen spodni hranici, ale i tak...)
Bez podrobnějšího porovnání zdrojáků je to trošku magie odhadnout, ale bude to asi kombinace ukazatelů (ale těch bude obecně míň, než v Javě, kde je prakticky všechno nepřímá reference) se zarovnáním. Samotný code segment by asi o moc větší být neměl, to Aarch64 kódování instrukcí je navržené dost dobře.
Zarovnání se mezi armv7 a armv8/aarch64 moc nemění, ne? Téměř všechno je na 4 B.
Podle mě je to kombinace ukazatelů spolu s datovými typy odvozenými ze size_t, kterých je překvapivě hodně (zkuste si ve zdrojáku čehokoliv pustit grep -rE "(define|typedef).+size_t"). Plus bezmyšlenkovité používání typu "int", místo typů s explicitní délkou (např. u16, i32). Plus určitě nějaký ten bug, kdy si aplikace alokuje zbytečně moc.
Ono se stačí podívat na implementace moderních prostředí (prohlížeče, JS), je to tam samý linked-list a další typy plné ukazatelů.
No třeba začátky struktur se zdají být zarovnány na 8 B. Teď jsem na AArch64 mašince zkusil:
#include <stdio.h>
#include <stdlib.h>
struct {
char a;
} s1;
struct {
char a;
} s2;
struct {
char a;
} s3;
int main(void) {
struct {
char a;
} s4;
struct {
char a;
} s5;
struct {
char a;
} s6;
printf("%p\n", &s1);
printf("%p\n", &s2);
printf("%p\n\n", &s3);
printf("%p\n", &s4);
printf("%p\n", &s5);
printf("%p\n\n", &s6);
return 0;
}
A jak na code/data segmentu, tak i ve stack segmentu to zdá se zarovnává na osm bajtů:
0x420030 0x420038 0x420040 0xffffe64fa178 0xffffe64fa170 0xffffe64fa168
PS: se omlouvám, s céčkem už trošku nepřicházím do styku, tak je to asi vidět :-)
Může být. gcc na tom Aarchu64 je na tomto stroji 10.3.1. Porovnání s x86_64 asi nemá smysl, ale s A32 nebo T32 (tady bych musel zkontrolovat) je zarovnání na 4 bajty, a to je rozdíl.
Tohle je spravne. Opravdu velmi zalezi na datech. Jeli to jedenukazatel a amilarda dat, paks e to neprojevy, je li to jeden ukazatel jedna data...Tak je to v zumpe.
Jak si predstavim pruemerny benchmark, tak to je jeden ukazatel za druhym.
Jak se chvoaji realnejsi priklady uz tu probarli lepsi kalibry.
No, by mě docela zajímalo, jak moc to ovlivnila samotná platforma. Zda třeba jiný arm nebo x86 procesor by neměl výsledky jiné (podstatně).
Některé (většina) Aarch64 procesorů mají crypto instrukce, ale není to povinné, až asi od ARMv8.4-a. A zrovna Broadcom to do Raspberry nedává. To by pak openssl jelo výrazně rychleji.
Fakt ze neco umi crypto instrukce neznamena ze to umi OpenSSL automaticky ihned pouzit nebo ze jde hned vychozi pkg distra bez vlastni kompilace a dalsich patchu.
Pokud je to právě to oficiální rozšíření ARMv8 co se jmenuje souhrnně crypto (tedy např. -march=armv8.1-a+crypto) a v podstatě to zahrnuje aes (aes+pmull) a sha2, tak to jednoduše bude automaticky fungovat na libovolné distribuci pro Aarch64 a žádné patche nejsou třeba. To je právě to pěkné, že to není každý pes jiná ves, jak to bylo u ARMv7 a starších.
K tomu crypto ještě navíc může procesor mít sha3 a sm4 (sm3 a sm4).
Co je na těch testech cinknutého? Jsou tam dva testy, které trochu stáhly průměr, ale to neznamená, že jsou cinknuté.
No když máte většinu testů co vycházej s rozdílem 20-30% a do toho mícháte několik málo, kde jsou stonásobky, tak je to trochu úlet.
Ale nešť, evidentně vás to netrápí, a hlavní teda je, že 64b systém vám zrychlí komp o 50%.
18. 2. 2022, 15:19 editováno autorem komentáře
Tak stonásobek to není, maximálně tam vidím 5,4x. Trochu divné je, že oba ty testy jsou v obou dvou článcích.
Takže s vyloučením těch etcpak dává druhý článek 32 % místo původních 41 %.
To nejsou cinknuté testy. AArch64 je moderní architektura, která bude drtit původní ARMy v jakémkoliv testu. Sám mám 64-bit Linux na RPI a ten rozdíl je fakt velký.
Krom toho už taky nikdo neoptimalizuje překladače pro původní ARM, v GCC i LLVM se zaměřují na AArch64, kterážto architektura vládne mobilům a tabletům (+Apple Silicon atd.).