Új hozzászólás Aktív témák

• #64 paljani aktív tag Pikari #61

  Új Válasz 2023-12-07 12:58:17 #64

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  paljani

  aktív tag

  válasz Pikari #61 üzenetére

  Érdekes. 16 bit -> total scrap, 32 bit -> some elements scrap. Igazából lehet megérné külön valami legacy vonalat "fejleszteni/fenntartani" az ilyen ipari stb. beépített rendszerekhez ahova 16/32 bit must oda úgysem kell(het) túl nagy kraft. Ami ilyenekkel találkoztam gyárakban azokhoz legalábbis nem kellett.

• #62 fatpingvin addikt Pikari #61

  Új Válasz 2023-12-07 10:30:00 #62

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  fatpingvin

  addikt

  válasz Pikari #61 üzenetére

  na, ezzel megy is a levesbe az EGYETLEN feature ami technikai szempontból érdemi létjogosultságot adott ennek a nyomorult architektúrának és a hardvereinek

• #40 paljani aktív tag Pikari #38

  Új Válasz 2023-12-04 14:47:46 #40

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  paljani

  aktív tag

  válasz Pikari #38 üzenetére

  Véleményem szerint ez most ilyen kereskedelmi adok-kapok csak, az export tiltás csak ideiglenes. Az eredeti indok, hogy katonai-ipari felhasználásúak gyakorlatilag a világ bármelyik gyártott chipjére ráhúzhatóak, már az amik is inkább teljesítmény(sűrűség) alapján szankcióznak nem ilyen balfasz indokokkal. De persze csak tippelek, arra alapozva, hogy ha van/lesz nekik egy nemzetközileg is versenyképes termékük, akkor miért ne csinálnának belőle pénzt? A fejlesztés meg rohadt sok pénz, szét szokták teríteni a sok-sok vásároló között. Lásd BYD és elektromos autók. Az sem egy Tesla mégis úgy fogy, mintha nem lenne holnap. Konzumer piacon nem feltétlen az elérhető csúcsra van szükségük az átlagembernek, hanem egy már megfizethető "elégjóra" azt meg már most is tudják ezek. Persze majd meglátjuk.

• #34 ddekany nagyúr Pikari #33

  Új Válasz 2023-12-03 14:41:01 #34

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  nagyúr

  válasz Pikari #33 üzenetére

  Ja, OK. Ezzel együtt is, hogy relatív gyorsan interpretálható, gyakorlatban használhatatlanul lassú lenne, a mai komplex Java szoftverekkel.

• #32 ddekany nagyúr Pikari #31

  Új Válasz 2023-12-03 12:54:37 #32

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  nagyúr

  válasz Pikari #31 üzenetére

  Csak a Java nem interpretált. Pontosabban a futás elején még az, de aztán rendes natív optimalizált gépikódra cserélődnek a metódusok, legalább is amit nem csak ezer évben egyszer hívsz.

• #30 ddekany nagyúr Pikari #29

  Új Válasz 2023-12-03 09:56:26 #30

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  nagyúr

  válasz Pikari #29 üzenetére

  Nem emlékeztetne, ha tényleg ránéznél. Java bytecodeban a tipikus utasításoknak (mint összeadás) nincs explicit megadott argumentuma, hanem fixen a stack legfelső 1-2 elemét elfogyasztják mint bemenetet, és az eredményt a stack tetejére teszik. Nincsenek regiszterek, amiket közvetlenül használhatnál. Ellenben a tipikus RISC ISA-knál, mint az ARM és MIPS, a hasonló utasításoknak 2-3 regisztert adsz át (cél, forrás 1, forrás 2), amiket szabadon megválaszthatsz egy jellemzően nagy regiszter készletből.

• #28 ddekany nagyúr Pikari #27

  Új Válasz 2023-12-02 23:17:59 #28

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  nagyúr

  válasz Pikari #27 üzenetére

  A Java bytekód az egy minimalista stack alapú ISA, nem hasonlít semmilyen valóságban használt CPU-éra. Mikor natívra fordul, csomó optimalizációt csinálnak, hasonlóan mint egy C/C++ fordító is, ráadásul mindezt a futás közben, a csak akkor elérhető információk alapján (pl. mit milyen gyakran hívsz a valóságban). Kb. a fél nagyvállalati világ Java-n fut szerver oldalon. Nagy kódbázisok, és sokban kritikus kérdés a teljesítmény.

• #26 ddekany nagyúr Pikari #25

  Új Válasz 2023-12-02 11:51:33 #26

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  ddekany

  nagyúr

  válasz Pikari #25 üzenetére

  Hm... elvileg van a V8-ban (a Chrome Javascript engine) LoongArch support: https://chromium-review.googlesource.com/c/v8/v8/+/3089095.

  Java byte code miért nem nagy kaland? A JIT nem egyszerű. De van nyoma, hogy talán támogatják.

  Deiban-nál van nem official LoongArch port: [link]

  Szóval nyomják a dolgot (mert gondolom politikailag is jól hangzik, hogy ennyire saját a sajátjuk). Aztán hogy ezek mennyire jók/értettek...

Új hozzászólás Aktív témák