Vlákno názorů k článku
Raspberry Pi OS 64bit průměrně téměř o 50 % rychlejší než 32bit
od soriako - "z 460 MB na 870 MB" WTF! To...
-
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. -
FíkZlatý podporovatelExistuje to i pro Aarch64 a jmenuje se to arm64-ilp32, ale není to moc rozšířené
-
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...)
-
Pavel TišnovskýZlatý podporovatelBez 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ů.
-
Pavel TišnovskýZlatý podporovatel
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 :-)
-
Pavel TišnovskýZlatý podporovatel
na x86_64 to je rozdíl jedinýho bajtu. Takže možná jen AArch64 má jiný defaultní nastavení gcc?
-
FíkZlatý podporovatel
a je verze gcc stejná? to zarovnávání je asi nějaká optimalizace na cache a tak
-
Pavel TišnovskýZlatý podporovatel
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.
