Vlákno názorů ke zprávičce Proč je procesor Apple M1 tak rychlý od Calculon - Nejdůležitější je předposlední odstavec, M1 sice všechny kolem...

Porting je v úplně pohodě - problém má jen kód napsaný lidma, co neviděli nikdy nic jiného než 32-bit Windows. Důležitý kód už byl ale dávno přeportovaný na Linux, takže dostat ho na MacOS/AArch64 nebude žádný problém. Ono ten memory ordering v C++ má nějaký význam a AArch64 je konečně architektura, kde se špatná volba projeví :)

I prakticky, což si může ověřit každý, kdo má MSVC a stroj s ARMem. V C++ žádné pasti ohledně CPU nejsou, to je blábol, WinAPI je od architektury dokonale odstíněné. Jediný problém byl s AMP, ale už ho opravili.

Tak jednoduchoučké příkládky, které si může ověřit každý, opravdu nejsou problém. Problém jsou velké systémy. Jako bonus věci psané v C občas používají různé triky kvůli výkonu nebo paměti. Ještě lepší bonus jsou knihovny dostupné jenom v binárkách.

Blábol? C má platformně závislé velikosti intů. Psát v Cčku platformně nezávislý kód není až taková bžunda. Použít někde špatný typedef je hrozně jednoduché. A dokud se ta platforma nepřepne, tak všechno funguje.
Přetečení intu je nedefinované chování. To jsou občas takové bugy, že by jeden lezl po zdi.
Co třeba takový midpoint? Jak těžké může být blbé půlení intervalu? https://www.youtube.com/watch?v=sBtAGxBh-XI&ab_channel=CppCon

Setkal jsem se třeba s tím, že bylo pro pořádné otestování kódu na 64b potřeba zaplnit spodní 2 giga virtuální paměti, aby se odhalila špatná práce s ukazateli. Převádění ukazatelů na inty a zpět se v Cčku občas dělá. A [u]intptr_t tu nebyly vždycky. Navíc jsou stále ještě jen volitelné.

Různou velikost intů řeší WinAPI, má svoje typové aliasy, které od toho odstiňují. Ostatně stejně jako macOS, ti je přidali do ObjC při přechodu z PowerPC na Intel. Stačí nepsat kód prasácky.

Winapi má svoje typedefy, Posix má jiné svoje typedefy. Přenositelné knihovny díky tomu musí používat směs standardních a vlastních typedefů. Takže je v tom binec. Windows.h je navíc makrožumpa, kterou je záhodno držet odděleně od zbytku kódu. Winapi typedefy mají své kořeny v 16b dobách a díky tomu jsou v novém kódu občas dost neintuitivní.

OMG. Tady nejde o POSIX, jde o to, že aplikace napsaná pro Windows (pro ty pomalejší ještě jednou, KÓD PRO WINDOWS) se dá přeložit pro ARM64 jen změnou hodnoty přepínače architektury, pokud kód nepsalo prase.

U cross-platform kódu se musí řešit mismatch mezi Windows a jinými OS, ať už jsou posixové nebo ne, ale to zase nijak nesouvisí s architekturou. S ARM64 na Linuxu nebo macOS taky nejsou žádné zvláštní problémy.

O posix tu jde proto, že windows only, ale zároveň přenositelného kódu jsem zas tak moc nepotkal. Když už to není nepřenositelná prasárna, tak už autor zrovna řeší i přenositelnost mimo Windowsí svět.
Winapi typy jsou historický nekonzistentní artefakt, na který dle mých zkušeností kašle kdo může (prasata i neprasata).

Schválně jsem si rozklikl msdn stránku s doporučeníma pro to, aby ta windowsí aplikace byla přenositelná i na ARM a není toho málo. Z toho plyne můj závěr, že kromě změny hodnoty toho přepínače bude třeba i zatraceně hodně testování a ladění.

Tím líp. Že je WinAPI změť se ví, ale i tak se v tom dá psát rozumně. Lepší je psát pro WinRT.

Jo, ono se snadno řekne, "Stačí nepsat kód prasácky." Proč nikdo neřekne "Stačí si dát bacha na ty hromady pravidel a doporučení a neudělat žádnou chybu"? To už nezní tak jednoduše.

S tím celkem obstojně pomáhá překladač/IDE. Kdo nedodržuje pravidla a doporučení, může si za problémy sám, nejen při psaní kódu, to je snad samozřejmé.

chceš říct, že píšeš kód vždy podle pravidel? Ono občas je těžké ty pravidla vůbec znát, řada regresí vzniká až během života aplikace, udržovat starý kód vždy aktuální je vždy trochu těžké. Snadno se řekne, nepiš prasácky, ale definovat prasácky kód je dnes už skoro akademická diskuze.

Kdo prevadi pointery do intu je normalni prase. Nedokazu si predstavit proc by to nekdo delal, navic i pri kompilaci pro 32bit to nejspise vyhodi warning. Neco jineho je indexovani polozek v poli, ale cpat pointery (ktere navic mohou projit realokaci a je treba na to myslet) do intu, proboha proc ? A to jeste kdyz uz teda musis, tak prece muzes pouzit void* ne ?

Ono to někdy, velice výjimečně, smysl mít může, ale pak to musí dělat člověk, který tomu rozumí do nejmenšího detailu, aby to nezprasil. To není jen v C(++), i Go nebo C# to umí, a ano, přesuny instancí objektů (aktualizace hodnot ukazatelů) je jeden z častých problémů, a nejde jen o GC nebo realokaci.

Používá se to celkem často, když jde o maximální výkon. V zarovnaném pointeru je dost nevyužitého místa minimálně na pár bitů. Na některých platformách se tam toho vleze až překvapivě hodně.
Třeba implementace vyhledávacích stromů tam ukládají pomocná data pro vyvážení. Dát bool vedle pointerů může znamenat dalších 8B nebo víc na uzel stromu.
Všechny handly ve winapi jsou pokud vím takovéhle obohacené pointery.

Pokud chci manipulovat s pointerem, tak přesně na to tady je intrptr_t a uintrptr_t. Já bych si napsal helper funkce, které udělají přesně to co potřebuju - třeba payload_from_tag­ged_ptr(), ptr_from_tagged_ptr(), make_tagged_ptr(), atd... Všechno se dá udělat buď přehledně a nebo nepřehledně.

Tak [u]intptr_t existuje až od C99/C++11. A je jenom volitelný. Není problém psát nový přenositelný kód. Problém jsou hromady starého kódu.

A co ti brani to hezky pekne usporadat do predem alokovaneho pole, kdyz chces maximalni vykon ? Mas to pekne v cache vedle sebe a jedes. Vlastne kdyz k tem pointerum pridas bool, tak z toho mas stejne index do pole + bool s pridanou prevodni gymnastikou (ok pokud potrebujes 56 bit index, tak to stejne moc jinak neudelas, ale takto definovana struktura vypada rozhodne lepe). Navic pokud neprogramujes primo pro OS, tak dostanes pointer zacinajici 0xFF a mas smulu. Nevim, jestli jsou zrovna handly ve WinApi dobry priklad, ale chapu, ze navrhnout rozsiritelny, zpetne kompatibilni system je docela slozite. Oni na to proste sli takto a proto spousta funkci konci na Ex a kazda druha struktura ma v sobe nejakou promennou, kam mas zapsat velikost cele struktury a kazda druha funkce konci na Ex -> to jsi usetril pamet, co :D

Hele, já dával příklady, kdy se to používá. Předem alokované pole má taky svoje zádrhele, hlavně při přidávání a odebírání prvků. Mimochodem ve chvíli kdy máš před sebou obrovskou hromadu legacy kódu, který má za sebou nějaký historický vývoj, tak máš kapku svázané ruce.
To, že kanonické pointery mají rozkopírované znaménko je úplně v pohodě. Máme přece aritmetický shift.

Ok chapu :) Kdyz tohle odstini pouzity programovaci jazyk, OS nebo treba debugger pro sve ucely, tak je to v pohode. Ale primo v aplikaci, ktera bezi v userspace k tomu nevidim zadny duvod. Vzdyt to nemusi byt kompatibilni ani na stejne architekture.

@Jiří Havel - pointery do intu

Nedávno jsem měl takové nutkání a rozhodování bylo těžké. Potřeboval jsem s pointerem zaznamenat vlastnictví (1 bit)

Nakonec rozhodovalo: Chci 100% přenositelný kód? Odpověď zněla "ANO". Takže tam přibyl jeden bool

Nedávno jsem měl takové nutkání a rozhodování bylo těžké. Potřeboval jsem s pointerem zaznamenat vlastnictví (1 bit). Nakonec rozhodovalo: Chci 100% přenositelný kód? Odpověď zněla "ANO". Takže tam přibyl jeden bool

Tak ono se to dá udělat i přenositelně, ale pokud někdo nepíše něco, kde je potřeba výkon, tak je to asi jedno. High-performance kód je napsaný jinak než kód, kde na výkonu vůbec nezáleží.

Ale jakou má toto spojitost s MacOS/AArch64? Aplikace pro MacOS už 64-bit jsou, takže v případě M1 se jedná jen o přechod na jinou architekturu - datové typy v takovém případě budou v C/C++ stejné. Vždyť i aplikace pro telefony jsou dneska 64-bit.

Porting z 32-bit na 64-bit je dávno vyřešený problém. I totální lama může použít UBSAN, který právě ten undefined behavior zjistí, takze když napíšu `a << b` a `b` bude větší/rovno než počet bitů v `a`, tak ten UBSAN to právě najde, signed integer overflow taky, atd... Porting 32-bit kódu na 64-bit dnes je mnohem jednodušší než kdy dřív.

Velikost intů a pointerů je jen jeden z mnoha rozdílů. Přechod z x86 na ARM je problém třeba i kvůli tomu, že každý přístup do paměti na x86 má automaticky odpovídající fency. Na ARMu to tak není. V low latency a gamedev světě se třeba hodně používají specializované datové struktury bez zámků. A tam přechod na ARM odhalí mračna bugů, které se na x86 nemají šanci projevit.

Pokud je možné použít asan, ubsan a podobné, tak je to fajn. Ale zrovna v tady zmiňovaném MSVC je jejich podpora zatím těžce experimentální.

Odhalení bugů je výhoda.

Jo, ti programatori, co to portuji, ti museji kricet nadsenim.