[cordianss]

Pytanie do osób, które portowaly większą aplikacje na ARM. Jakie tam są problemy? Na chłopskich rozum to trzeba po prostu zrobić cross-kompilacje i wszystko powinno śmigać, ale z jakiegoś powodu wielu programów na ARM nie ma. Dlaczego?

#programowanie

[groman43]

@cordianss Przede wszystkim ARM to nie jedna architektura, ale wiele różnych, zaczynających od Cortex-M0 kończąc na Cortex-X3.

Pierwszą rzecz, która przychodzi mi do głowy to zależności od systemu operacyjnego. Jeśli Twoja aplikacja korzysta z systemu operacyjnego (a korzysta albo bezpośrednio, albo pośrednio) i interfejs pomiędzy Twoją aplikacją a systemem operacyjnym nie jest ustandaryzowany (POSIX), to przeniesie jej na inny system operacyjny jest dość trudne. A często ten konkretny system operacyjny, od którego

[Saly]

@cordianss: jeśli twoja aplikacja nie używa mocno SIMDa to nie ma problemu. Największy problem to zdecydowanie przyspawanie do danej architektury na poziomie kodu i budowania. W takim go zmieniasz jedną flagę i masz działającą binarkę na dowolną wspieraną architekturę.

[Krolik]

@cordianss: dużo programistów nie umie w programowanie współbieżne i pisze kod, który tylko przez przypadek działa na Intelu, bo Intel ma koherentną pamięć podręczną i nawet jak programista zapomni o synchronizacji to ta synchronizacja tam jest i procek sam dba o to że odczyt po zapisie na innym rdzeniu jest aktualny albo o to że zapisy idą w tej samej kolejności co w kodzie. Natomiast na ARM takich gwarancji nie ma

[groman43]

@Krolik: Chyba tylko w Cortexach M nie ma koherentnego cache. To jest problem, o istnieniu którego pewnie 90% programistów na świecie nie ma zielonego pojęcia. Nie mówiąc już o tym jak programować w takim środowisku. Więc jeśli popularne architektury faktycznie nie miałyby koherentnego cache, to wszystko by się pieprzyło jak w dobrym pornolu xD

[Krolik]

@groman43: ok, cache koherentny to nie wszystko - co jak kolejność zapisów nie musi być zachowana? Tu masz przykłady: https://www.nickwilcox.com/blog/arm_vs_x86_memory_model/

[cordianss]

@Krolik Zwykle jest tak, że domyślny ordering to "strict", więc dopóki ktoś kto ogarnia nie zmieni tego na taki, dający lepszy performance, to problemu nie powinno być. Czy się mylę?

[Krolik]

@cordianss: nie, domyślny ordering nie jest strict. Domyślnie w ogóle nie ma żadnego „happens before”. Jak zrobisz w programie:

x = 1
y = 2

To inny wątek może zobaczyć te zapisy w odwrotnej kolejności albo może ich w ogóle nie zobaczyć. Ale na Intelach przez przypadek właśnie często działa to tak jak naiwnie myślą programiści - tj że x będzie ustawiony przed y. I łatwo przeoczyć w ten sposób błędy.

[cordianss]

@Krolik Miałem na myśli ordering podczas używania atomicow. No a jeśli atomicow i innych prymitywów synchronizacyjnych nie ma, to czy kod nie jest jednowątkowy?
Trudno mi sobie wyobrazić kod w którym można popełnić taki błąd bez użycia atomicow.

[Krolik]

@cordianss: Jeśli atomiców i orderingów nie ma, to może oznaczać również że programista dał ciała. :D

Trudno mi sobie wyobrazić kod w którym można popełnić taki błąd bez użycia atomicow.

A mnie bardzo łatwo i widziałem takie coś dziesiątki razy.
Zwykle wygląda to tak:
- programista A robi kod jednowątkowy i strukturę X działającą na jednym wątku, więc bez synchronizacji; wszystko działa poprawnie
- przychodzi programista B i stwierdza, że moduł