www.militaar.net

Kuna jutt läks pikaks panin kiibitootmise jutust eraldi postitusse:

Kui sellest (ja USA tarkvarakeeldudest) saaks veel üle, siis palju karmim mats oli Huaweile see, et ka ARM lõpetas nendega USA survel koostöö. ARM on Briti juurtega firma, mille käsustikuga kiibid on praeguseks saanud standardiks enamvähem universaalselt: alustades mikrolaineahjudest, pesumasinatest ja printeritest ning lõpetades autode, telekate ja mobiiltelefonidega. Viimasel ajal tungib ARM hoogsalt ka viimastele pärusmaadele kuhu tal varem asja ei olnud: serberid ja sülearvutid (kohad mis on aasatkümneid olnud Inteli x86 käsustiku pärusmaa).

Väga lihtsustatult on käsustik (Instruction Set) kokkulepitud standard, mille kaudu riistvara ja tarkvara suhtlevad. Sellised standardid on vajalikud, et iga uue protsessori mudeli korral ei oleks vajalik hakata programmeerima täiesti uut operatsioonisüsteemi ja enamikku selle peal olevat tarkvara (eriti madaltaseme asju nagu kõikvõimalikud lisa-seadmete driver'id)

Sisuliselt tuleb käsustikku vahetades kogu tarkvarandus nullist üle käia. Keeruliste tarkvaralahendustega seadmete puhul (nagu sülearvuti või mobiiltelefon) võtab heal juhul 5 aastat, halval juhul üle kümne.

Hea näide ongi seesama ARM, mille peale hakati Linuxi kernelit kohandama juba nii 90-ndate keskpaigas. 2000-ndate keskpaigaks oli "tugi" Linuxi opsüsteemile justkui olemas (väikestele mikrokontrolleritele sobis täiesti). Serveri maailma jaoks vajaliku (x86 käsustikuga võrreldava) töökindlust ja võimekust on see saavutamas alles nüüd, 2020+.

Erinevalt Intelist litsenseerib ARM oma käsustikku kõigile kes seda soovivad (noh, peale Huawei siis nüüd) ning pakub ka valmislahendusi (nn valmis-"jooniseid" protsessoritest kõigest millest saad väikse kohandamisega toota igasugu kiipe ükskõik millises "valukojas"). Seetõttu on see praeguseks niivõrd laialt levinud et mobiilsete seadmete valdkonnas sisuliselt alternatiivi pole. Taamal paistab kauguses vabavaraline RISK-V käsustik, mille vastu tunnevad loomulikult suurt huvi ka hiinlased, aga läheb 10 aastat ennem kui see ARMile tõsist konkurentsi pakub. Kõik ülejäänud käsustikud on seotud mõne teise USA hiiuga.

Pikas perspektiivis ei ole siin loomulikult midagi ületamatut. Võib kindel olla et Hiina paneb täiel määral rattad käima, et mitte sõltuda sellistes asjades tulevikus USA suurkorporatsioonidest. Reaalsus on aga see et kõik see võtab ikka 5 - 10 aastat aega. Lisaks tuleb suuta valida standardid mida on nõus kasutama ka kogu ülejäänud maailm, muidu ehitavad nad lõpuks ainult Hiina tarkvara Hiina kiipidele, mis kuskil mujal ei tööta.Hiinale võib kogu ülejäänud maailmaga võidujooks olla ehk veidi jõukohasem kui NSVLile, aga vaevalt et nad seda teed minna tahavad.

Rootsi keelab 5G võrkude ehitusel Huawei ja ZTE tuumikvõrgu seadmete kasutamise

Swedish regulators on Tuesday banned the use of telecom equipment from China's Huawei and ZTE in its 5G network ahead of the spectrum auction scheduled for next month.

The Swedish Post and Telecom Authority (PTS) said the setting of the license conditions followed assessments by the Swedish Armed Forces and the Swedish Security Service.

PTS said companies taking part in the auction must remove Huawei and ZTE gear from existing central functions by Jan. 1, 2025.

https://www.dailysabah.com/business/swe ... works/news

Sisuliselt tuleb käsustikku vahetades kogu tarkvarandus nullist üle käia. Keeruliste tarkvaralahendustega seadmete puhul (nagu sülearvuti või mobiiltelefon) võtab heal juhul 5 aastat, halval juhul üle kümne.

päris nii halb olukord pole. protsente ei julge pakkuda, aga osa läheb paugust käima, osa vajab natukene järeleaitamist ja mõni veidi rohkem. protsessori arhitektuur täna väga suurt rolli ei mängi - selle kihi lahendab ära kompilaator/interpretaator. hästi lihtsustatult öeldes sina toksi aga koodi ja sihi kompilaatoriga millist arhitektuuri tahad. interpreteeritud keele puhul ei huvita sind see detail üldse. saatan on muidugi detailides ja alati pole elu nii lihtne ehk et näiteks saadud binaar ei pruugi talle pandud ülesandeid rahuldaval kiirusel sooritada. ja siis võib minna aastatepikkuseks arhitektuurispetsiifiliseks optimeerimiseks, kui kuu ja tähtede seis soodus on. seda siis alumises kihis.

ülemises kihis on probleemid tarkvaralahenduse enda arhitektuuris ja/või sellega külgnevates teenustes, kuid selle lahendab nähtus nimega infosüsteemide elutsükkel varem või hiljem. mis arhitektuurid hiljem popid on ja millised kasutusele võetakse, see selgub tegemise käigus. ja isegi siis ei pruugi see arendajale näha olla, sest koduloomad nimega kompilaatorid ja interpretaatorid.

ning lõpptarbijale suunatud "sülearvuti" ja "nutitelefoni" tarkvararaarendus on veel segasem ja laiem teema, et ma ei taha seda jänku urgu piiludagi. aga üks on kindel - protsessori arhitektuur puutub siin väga vähe asjasse.

dorpat kirjutas: päris nii halb olukord pole. protsente ei julge pakkuda, aga osa läheb paugust käima, osa vajab natukene järeleaitamist ja mõni veidi rohkem. protsessori arhitektuur täna väga suurt rolli ei mängi - selle kihi lahendab ära kompilaator/interpretaator. hästi lihtsustatult öeldes sina toksi aga koodi ja sihi kompilaatoriga millist arhitektuuri tahad. interpreteeritud keele puhul ei huvita sind see detail üldse. saatan on muidugi detailides ja alati pole elu nii lihtne ehk et näiteks saadud binaar ei pruugi talle pandud ülesandeid rahuldaval kiirusel sooritada. ja siis võib minna aastatepikkuseks arhitektuurispetsiifiliseks optimeerimiseks, kui kuu ja tähtede seis soodus on. seda siis alumises kihis.

Jah, olles üle kümne aasta programmerijana töötanud olen üsna hästi kursis mainitud loomadega nagu interpretaatorid ja kompilaatorid.

Selles osas võib nõustuda, et kirjutades mõne infosüsteemi teenuseid või geneerilist toodet/äppi ei ole tõesti suurt probleemi. Kui kasutada virtuaalmasinal jooksvaid keeli (näiteks JVM, V8) peaks asi olema sisuliselt valutu.

Isegi enamike otse masinkoodiks kompileeritavate keelte puhul (C, C++, Go, Rust) teeva uue põlvkonna kompilaatorid (eriti näiteks LLVM infrastruktuuril põhinevad, nagu clang) selle kaunis valutuks, seda siis eriti kui kasutada hästi toetatu käsustikke: x86 või ARM (vähe huvitavamaks läheb siis kui proovid midagi eksootilisemat, nagu näiteks PowerPC või MIPS).


Sellegipoolest, nagu sa ka ise mainisid, peitub kurat pisiasjades.


Kõik see näiline lihtsus seiab tegelikult "hiiglaste õlgadel", sest keegi peab kirjutama ka need interpretaatorid, kompilaatorid ja virtuaalmasinad (rääkimata siis opsüsteemidest mille peal need jooksevad).

Ka see ei ole üldse nii lihtne kui tundub, isegi mitte tunnustatud käsustike puhul (ARM ju universaalne tegija juba nii 15 aastat). Värke näite võib tuua Rust'i näol, mis toetab ARMi juba mõnda aega täitsa talutavalt, aga Tier 1 support (võrreldav x86ega) saabus alles eelmine nädal (kuigi vastavaid trackeri issue loodi 2017 ja selle eelane veel varem):

Põhiline probleem uute käsustikega ei ole üldse niiväga klassikaline tarkvara (user-spaceis ehk, Ring 3'es toimetav) vaid just see osa mis peab tihedamalt OS-kerneliga suhtlema - ehk igasugu seadmedraiverid. Need opereerivad sügavamal operatsioonisüsteemi kõhus kõrgema privileegide tasemega (ning need on ka üks vähestest kohtadest, kus ka tänapäeval tasub kohati mingeid kihte otse assembly's tasub kirjutada). Neid sa juba lihtsalt ümber ei kompileeri.

Üheks näiteks võib võtta Windows on ARM'i, mis samuti ei ole üldse uus teema (esimene õnnetu implementatsioon, Windows RT, valmis ju juba 2012). Kui reaalselt kasutada mõnda WARM seadet (näiteks Samsung Galaxy Book S) siis üldjoontes töötavad need juba kaunis hästi. (muuhulgas ka seetõttu, et ARM-windowsile on sisseehitatud x86 emulaator). Aga proovi mõnda paar aastat vana draiverit vajavat välisseaded (näitks printer) sellega ühilada. Draiverite tugi on endiselt äärmiselt kesine.

Huaweil aga ei ole vaja mingeid välise printeri draivereid vaid kõigele, mis sul ühe telefoni sees on (GPU, kaamerad, puuteekraanid, akseleromeetrid, sõrmejäljelugejad jne, jne) kõik se tuleb nende seadmete tootjatele maha müüa ja koostöös välja arendada.

Liikudes draiveritest veel edasi OSi tasemele jõuame probleemi tegeliku tuumani. OS enda tugi.

Siin tasub jälgida mida eksperdid kirjutavad. Keskendusin praegu RISC-V'le (mis on Huaweile sisuliselt ainuke USA-vaba rahvusvaheliselt natukenegi kõnetav alternatiiv). Selle kohta ilmus eelmine aasta väga hea artikkel, mille soovitan üldse tervenisti läbi lugeda:
https://www.eetimes.eu/risc-v-climbs-software-mountain/

Muuhulgas võtab seal sõna Jon Masters, kes on Red-Hati arhitekt kes on viimased 10 aastat tegelenud vaid sellega, et ARM protsessorid Linux serverites töötaksid märkamatult ja valutult (olles sisuliselt selle protsessi juhtfiguur). Tema arvamus:

The foundation just started work on a Linux boot spec, OpenSBI 0.1. Beyond Linux, there are no ports for Android, Windows, or other commercial OSes. The bad news is that the OS ports are just the tip of a software iceberg, warns Jon Masters, a computer architect and distinguished engineer at Red Hat. Masters has spent the last nine years working on a standard version of Red Hat Linux for Arm servers. So far, just two commercial systems have been announced as certified to run it.

The process involved identifying a set of low-level hardware primitives that are assumed in the x86 world for such details as how interrupts and power states work. Those de facto standards were articulated in a 50-plus-page document, then applied to the Arm architecture.

A separate effort documented x86 boot standards across Linux and Windows and applied them to Arm cores. They included obscure but crucial aspects of BIOS, power, and multiprocessing functions.

“I worry that the excitement of a new thing like RISC-V misses the real problems” of defining such support details, said Masters, who has been working on Linux for Arm servers since 2011. RISC-V backers “will learn that no one got PCI right in Arm for the first few generations — to do PCI right [in a non-x86 host system] is tricky,” he said.

Tema arvamus RISC-V ja Huawei ajakulul on 10 aastat (5 ilgelt forsseerides), sest ta on reaalselt selle kadalipu läbi teinud.

Ja mis seisus see RISC-V oli veel 2019:

A bootstrapped version of 64-bit Debian is available for RISC-V, but the architecture won’t be natively supported in the upcoming version 10 of the code. RISC-V still lacks support for a low-level virtual machine (LLVM) compiler, Java, and languages such as Golang and Rust, said a Debian developer at a recent event.
For its part, Arm led the formation of Linaro, a collaboration that has worked for several years on low-level software for servers as well as systems for telcos and the internet of things. Linaro helped pave Arm’s expansion into a variety of areas but has required dedicated engineering time from a wide swath of members at an estimated cost of US$100 million. RISC-V “needs standards and something like a Linaro, and they know this,” said Masters.

China’s burgeoning interest in RISC-V could accelerate such efforts, perhaps collapsing them to a five-year journey. However, the opportunity for servers is arguably closing with two strong x86 companies and Arm server alternatives available from Ampere, Cavium, and Huawei, he said.

“Cloud server vendors are hedging their bets with Arm, but they don’t want 10 alternatives, so I’m not sure a RISC-V server opportunity really exists,” said Masters. “I’m sure startups will get funded, but I think they will build domain-specific accelerators.”

Ehk kindlasti ei tasu arvata et täiesti uue (mitte juba mõne teise laialtlevinud) käsustiku kasutuselevõtt keerukates seadmetes on väik töö.

Tullles nüüd sügavikest tagasi abstraktsiooni kõrgeimate kihideni:

ülemises kihis on probleemid tarkvaralahenduse enda arhitektuuris ja/või sellega külgnevates teenustes, kuid selle lahendab nähtus nimega infosüsteemide elutsükkel varem või hiljem. mis arhitektuurid hiljem popid on ja millised kasutusele võetakse, see selgub tegemise käigus. ja isegi siis ei pruugi see arendajale näha olla, sest koduloomad nimega kompilaatorid ja interpretaatorid.

ning lõpptarbijale suunatud "sülearvuti" ja "nutitelefoni" tarkvararaarendus on veel segasem ja laiem teema, et ma ei taha seda jänku urgu piiludagi. aga üks on kindel - protsessori arhitektuur puutub siin väga vähe asjasse.

Teoorias küll. Samas just ülemöödunud nädalal oli vestlus sõbraga, kelle firma (Eesti üks suuremaid ja vanemaid startupe) antud teemaga kokku puutus. Nimelt katsetati paari Amazon Cloud'is jooksva Java mikroteenuse ületoomist Graviton (ARM) instance'ite peale Inteli (x86) omadelt. Võinuks olla ideaalne "kompileeri-ja-sõida" olukord (mul isiklikult pole kunagi JVMi asjade ARMil jooksutamisel probleeme esinenud). Paraku selgus et mingid teegid mis nad kasutavad lihtsalt ei toimi seal. Lõppkokkuvõtes pole see midagi kontimurdvat (saab ju välja vahetada) aga kuna nad on need moodulid sinna nati kinni kirjutanud tuleks selleks matta sinna täitsa arvestatav kogus arendustunde (millel kohe pole mõtet).

Lihtsalt näide et isegi päris kõrgtaseme keeles vägagi riistvarakauget koodi kirjutades ei ole alati päris nii, et "üldse ei puutu asjasse".

Ühesõnaga eelmise lohiseva postituse kokkuvõtteks:

Probleem ei ole niivõrd koodi kompileerimine, kuivõrd operatsioonisüsteemi (s.h. DDR ja PCIe liidestused, jms) ja draiverite ökosüsteemi toe loomine ja selle stabiliseerimine. Kõik mis omakorda selle peale ehitatakse saab tõesti väiksemate muudatustega uuesti kompileerides tööle pannna, enamikku või kõike olmemas olevast "legost" ära kasutades.

See ei ole aga üldse Huawei kõige suurem probleem. Alates septembrist nad enam Taiwanis oma (5nm ja 7nm)kiipe toota ei saa, mistõttu tuleb kasutada mahajäänumaid hiina "kiibi-valukodasid" (foundry).

Kuigi isiklikult ei ole mulle Puna-Hiina mulle absoluutselt sümpaatne, tunduvad ka need vimased ainult Huawei vastu sihitud Trumpi sanktsioonid parajalt lollakad. Huawei 5G infrastruktuuri keelust saan üsna hästi aru. Aga keelata igasugune kiipide tootmine, ARM koostöö ja Android/Windows kasutamine ka tarbijatele toodetavates telefonides ja lauaarvutites? Seda enam et kõik teised Hiina tootjad (OnePlus, Xiaomi jne) toimetavad ju rõõmsalt edasi.

Ilmselgelt sellised maffia stiilis näidispoomise tunnusmärgid, et "räägime läbi, teeme kompromissi".

Huawei enda käitumist vaadates (ostes kõvasti 5nm kiipe ette jne), tundub et panustavad praegu sellele, et Trump Valges Majas ei jätka. Eks ilmselt on nad sunnitud oma plaanid ümber vaatama kui peaks juhtuma et jätkab.

Nii-või-naa on selge et Hiina seda kogemust ei unusta ja teeb kõik sõltuva et ülesse ehitada globaalset riistvara ja tarkvara ökosüsteemi kuis USAl ei oleks päris sellist vetoõigust oma suva järgi kelle iganes 1-0 teha. Millal ja kui laia kasutuskonnaga väljaspool Hiinat see õnnestub, eks näis.

Mingit laiemat rahvusvahelist kasutajaskonda on neil igatahes vaja, muidu on nad varsti NSVLi olukorras oma alternatiivsete standarditega (ega needki enamuses ju halvad ei olnud, lihtsalt kui ühel hetkel kogu ülejäänud maailm teistmoodi toimetab, tuleb ka lõpuks asju ühtlustada)

Jah, muidugi on kõige suurem probleem see, kui moodne kiibitootmine kinni keeratakse.

Aga muu kohta ma ka programmeerijana arvaks, et kõik need hädad, millest ülal juttu, on tingitud eelkõige arendustsüklite lühenemisest. Telefonidele arendamisel on niigi hulk spetsiifilisi probleeme ja äärmiselt terav konkurents tekitab neid veel juurde. Ma arvan, et kunagi jõuab kogu see tööstusharu autotööstusega võrreldavasse kriisi.

USA bännis China Telecomi ära: https://investor.postimees.ee/7371380/u ... egutsemise

Meie meediasse see teema vist ei jõudnud.

Lithuania urges people to throw away Chinese phones

https://www.bbc.com/news/technology-58652249

Meie meediasse see teema vist ei jõudnud.

vana uudis, isegi AK-s hõigati maha

Huawei tulud kahanesid aasta jooksul kolmandiku võrra: https://investor.postimees.ee/7420139/h ... diku-vorra