On 05/01/2021 21:06, Maciej Sobczak wrote:
> Ćwiczenie.
> 1. NVIDIA znana jest z tego, że sterowniki do kart daje w formie binarnego bloba, a
nie w postaci źródeł. Bo "IP protection", oczywiście. To oczywiście nie dotyczy tylko
tego producenta, to jest powszechna praktyka.
> 2. NVIDIA kupuje ARMa.
> Pytanie do ćwiczenia: kiedy NVIDIA będzie rozdawać sterowniki do swoich kart dla
procesorów RISC-V?

To pytanie zadaj wobec R-PI który będzie miał złacze PCI-E i da się do
niego wsadzić kartę NVidi. Są sterowniki NVidi pod linuxa, na arm?
Ojejkujejku! Nie będzie cyberpunka na r-pi?

> No i teraz hipisi od RISC-V będą musieli jeszcze karty graficzne robić, żeby te
cudowne procesory kogokolwiek zainteresowały. I tyle było z "urywania rynku x86".

Dokładnie to samo masz z armem.

Rynek x86 to nie tylko gry. Dekoder x265 i blitter do pasjasa w gpu
załatwia 80% potrzeb biur. Brak GPU załatwia 100% potrzeb wirtualizacji
ukrytych giełd narkotyków, w torze.

>> Bo nie musi: języki wyższego poziomu zapewniły abstrakcję.
> Ale ja kupuję programy już skompilowane.

Bo taki masz system dystrybucji w zabawkowym systemie operacyjnym. Są
inne, np Android ma w połowie skompilowane. Jeszcze inne mają kod
źródłowy. W zasadzie mało kto ma skompilowane, licząc tak możliwie szeroko.

>> Ogólnie industry jest
>> zaskoczone że "z niczego" w ciągu zaledwie kilku lat wyrosła
>> konkurencja, wydawało by się z najdoskonalszym procesorom embedded.
> Język C od dekad ma konkurencję w postaci doskonalszych języków, których nikt nie
używa.

Przeginasz. Język C ma konkurencje w postaci C++ której używa sie
powszechnie, również w embedded (acz tam problemem jest raczej białko
niż technologia). Starasz się zniknąć zmianę na rynku, ale ona tam jest,
od dziesięcioleci. jest wiele języków używanych powszechnie w róznych
niszach.

> DOS miał konkurencję w innych systemach, których nikt nie używał.

Przeginasz. W USA Maki były znacznie bardziej powszechne niż piedołowaty
DOS, w wielu zastosowaniach. To że u nas ich nie było, było oczywiste. U
nas musiało być tanio, bo dewizy.

>> desktopowce muszą uważać, RISC-V ma zacięcie na pokonanie ich w wersjach
>> bardzo wielo rdzeniowych, do centrów obliczeniowych.
> Ciekawe, co NVIDIA sądzi na ten temat. Zwłaszcza na ten temat bardzo wielo
rdzeniowy.

Dokładnie co teraz: nie istnieje sens robienia klastra obliczeniowego na
GPU do zastosowań ogólnych ponieważ GPU mają bardzo wiele wad i nie są
"duża iloscią rdzeni", jak wielu sądzi. Czasem są przydatne, a czasem
komplenie nieużyteczne. Beda miały swoją niszę, mają ją z resztą już w
tej chwili.

>> Jak będzie darmowy to RISC zrobi robotę. Postraszy.
> I dobrze, bo presja jest dobra. Ale zobacz, jak Linux postraszył Windowsa

Nie przypominam sobie. Linux w '99 miał gry z akceleracją 3D?

>, to masz teraz Linuksa w Windowsie i... dalej Windows jest na każdym komputerze w
biurze.

Bo są gry 3D i pasjans.

> Myślę, że ze strachu NVIDIA też będzie zarabiać miliony dzięki darmowym RISC-V.

NVidia ma obecnie na głowie AMD który stuknął ją znowu w łeb. Jesli
kogoś się boją, to raczej konkurencji w 3D a nie konkurencji w
klastrach, które są raczej kwesią hałasu medialnego.

>> Całośc rynku obecnie skupia się na produkcji narzędzi,
> Nie szkodzi. CPU to nie jest jedyna rzecz, którą trzeba kupić.

Pozostałe sie nie zmieniają.

> Zwykle kupuje się więcej różnych rzeczy. I wtedy kupuje się u takiego producenta,
który da ogólnie dobrą cenę za ogólną lojalność.

Fajnie, ale ciezko znaleźc producenta który oferuje *wszystko*. Naprawdę
cieżko. Ten ma symualtor i cpu, tamten weryfikację formalną, ale ma inne
cpu, ten ma debugger do ARMów, ale nie ma symulatora itd itp.

Może to zabrzmi śmiesznie, ale wiele bardzo drogich projektów w EDA
powstaje poprzez sklejenie wielu niespójnych narzędzi gumą do żucia i
duża ilością perla.

> W projektach przemysłowych liczy się Total Cost of Ownership, a nie to, kto ma o
centa taniej jedną część, która nie pasuje do całej reszty.

O ile to Total jest naprawdę Total. Możesię okazać że to kilka luźnuch
narzędzi, jak to obecnie jest powszechne.

>> Jesli team od software jest zdrowy psychicznie to każe
>> sie że całą ta migracja zakończy się poprzez zmianę kompilatora w
>> makefile i puszczenia testów.
> Nie. Bo ten jak najbardziej zdrowy psychicznie team wziął też od Texasa ich system
operacyjny (TI-RTOS). No i run-time, z "proprietarnymi" bibliotekami do peryferiów.

Innymi słowy wziął vendor-lockin? Przecież pisałem, ze zdrowy psychicznie.

Dodam też, że komunikacja z takimi biblitekami musi być napisana przez
abstrakcję, którą można łatwo podmienić. Nie została napisana przez
abstrakcję? Mówiłam przeciez że zdrowych...

> To, że Twoje kilka linijek kodu na wierzchu tego wszystkiego jest "przenośne", bo
napisałeś je sobie w "języku wysokiego poziomu", który "zapewnia abstrakcje", to jest
złudzenie optyczne.

Albo praktyka na codzień. Zależy gdzie siedzisz.

>> Przed chwilą nie był. Demonizujesz. Apple doskonale sobie poradziło z
>> przejściem z x86 na ARM,
> Apple to już ćwiczył, więc ma wprawę - wcześniej przechodzili z PowerPC na x86. Ale
wbrew temu co sądzisz o snobach oglądających pornole

Tak wygląda rynek laptopów: snoby oglądające pornole. Szczególnie Apple,
ich kompytery migrują w kierunku kompletnie bezuzytecznych do
profesjonalnej pracy (złacza, klawiatura, znikanie fukncji itd itp).
Niech sobie wsadzają Z80 jesli chcą. Obawiam się że nikogo to nie
interesuje.

> https://www.apple.com/final-cut-pro/

A co kupują jak chcą odpalić ModelSima?

> itp., jest tego oczywiście więcej.

Wiadomo. Zapomniałeś dorzucić klasyka profesjonalizmu, czyli Autocada.
Który w porównaniu z wieloma naprawde profesjonalnymi apliakcjami
wygląda znacząco mniej imponująco.

> I o ile widzę oczami wyobraźni jak ci producenci portują swoje produkty na nowe
procki Apple'a, to entuzjazmu na portowanie na RISC-V się nie spodziewam.

I on nigdy nie nastapi. To był argument teoretyczny: twierdzenie że
zmiana architektury procesora jest problemem, jest idityczne. Nie jest.
Ba, doświadczasz tego na codzień: kompilacja kodu na x86 i x86-64, dwie
komplenie różne ISA, nie stanowi *żadnego* problemu, poza kiepskim
kodem. API OS jest takie samo.

Gdyby, teoretycznie, Apple przeszedł na RISC-V, API systemu było by
takie samo.

Wystarczy zmienić kompilator w makefile.

No i oczywiście zapominam o vendor-lockin, ale przecież nie rozmawiamy o
chorych apliakcjach.

> I nie, nie chodzi tylko o "przekompilowanie i puszczenie testów". Te produkty mają
za sobą całe ekosystemy pluginów, od tzw. "firm trzecich".

Vendor-lockin. Jeśli programiści mieli choć cień mózgu, to dawno się od
tego odgrodzili abstrakcją. "Firmy trzecie" same sie zgłoszą, jeśli są
coś warte, aby ich pluginy zastosować.

> Pierdyliony pluginów.

Skoro wybrali model pracy z okolic "niech kompilują te kolesie w
Indiach, ojej, właśnie umarli" to dlaczego uważasz że to jest sensowny
argument?

Sporo software ma pluginy pisane w pythone, tclu itd. I co teraz? Ten
argument świadczy o tym że łatwo przejść, twój że ciężko, prawda po środku.

> I weź teraz przekonaj ich twórców, że mają zrobić osobne wersje na RISC-V, bo jacyś
hipisi chcą robić "rewolucję".

Rynek ich przekona. Dokładnie tak, jak w tym momencie, kiedy to piszę,
rynek przekonuje aby te wszystkie pluginy do photoshopa przekompilować
na gwałt na ARMa, bo snoby znowu kupiły zabawki.

>> Całośc RISC-V opiera się o dominacje w
>> embedded
> Dominację w embedded mają producenci silikonu, tacy jak przykładowy Texas.

Myślę że wyjąłeś sobie 1 mały detal z embedded i nazywać go
najważniejszym, olewając inne detale.

> Bo to u nich się robi zakupy a nie na GitHubie.

No i widzisz, nie pojmujesz. Własnie zakupy robi się "na githubie" tylko
że ceny są w milionach dolarów i nazywa się to ipcores/weryfikacja.
Raczej nie dostaniesz cennika. To nie dla nas. I to jest embedded. To
czy krzem zrobią w SMC czy Samsungu, nikogo nie obchodzi, poza księgowymi.