A bejelentés elolvasható itt.
- A hozzászóláshoz be kell jelentkezni
- 562 megtekintés
Hozzászólások
Újabb szög a SPARC koporsójába, az illumus dobja a támogatását:
Officially end SPARC support in illumos and remove the SPARC code from the tree
When the illumos project was formed in 2010 as a fork of OpenSolaris, the operating system contained support for 32-bit and 64-bit x86 machines, and for various 64-bit SPARC machines from Sun Microsystems. In 2018, we officially dropped support for 32-bit x86 systems, leaving just 64-bit x86 and SPARC.
The most recent SPARC machines for which we have relatively direct and complete support were contemporary at the time of the fork; viz., the UltraSPARC T2 family of servers, such as the T5120 and T5220. The last of these systems reached their end-of-life between 2011 and 2012. In the decade hence, the size and quality of the pool of second hand systems available through eBay and other vendors has dwindled, and prices have risen to match. Desktop systems in particular are popular for collectors, and are thus now staggeringly expensive if you can find them at all. As a result, the pool of machines available to build the software is extremely limited; the project does not currently have access to a permanent official SPARC build machine.
Without ready access to build machines, one might consider cross compilation. Though we have some support for cross-architecture software generation in the tools, the operating system does not currently support being cross compiled in full. Work would be needed to complete surgery to Makefiles and arrange for packaged cross-architecture C compilers, amongst other things.
In theory one might emulate SPARC systems with QEMU, but reports in the field suggest that this does not work well enough to run modern illumos. Even if it did, it may take a very long time -- e.g., weeks! -- to build the operating system under full emulation.
In addition to the core of illumos, the external software ecosystem has changed a lot in ten years. Many new projects have emerged that generate program text at runtime (JIT) or which do not use established code generation systems like LLVM or GCC that have SPARC support; e.g., Go and Node.js. Some projects could in theory support illumos on SPARC, like Rust, but it will still require a not inconsiderable amount of work to get there. There is growing interest for use of Rust in the development of the core of illumos, and lack of current support for SPARC inhibits those efforts.
If a community of users was going to emerge to provide engineering effort and build resources for SPARC, it likely would have done so by now. It is always sad to close a chapter in our history, and SPARC systems represent a strong and positive memory for many of us. Nonetheless, the time has arrived to begin the process of removing SPARC support from the operating system.
[...]
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
És egy kis rozsdásodás:
- use of Rust to implement new facilities in the kernel, in libraries and in commands
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Hát ha az Apple M1 meg a Microsoft Surface X (és természetesen az ezek után várhatóan özönlő kínai variánsok) a múltba küldik az x86 architekturát is, akkor épp ideje leszállni a 10 éve döglött lóról, bármennyire is cuki a T2 vagy a POWER.
- A hozzászóláshoz be kell jelentkezni
Fun fact: Az új iPad Pro veri a top-top Inteles 16" MacBook Pro-t...
Szerk: mostmár csak annyi kéne, hogy bejelentsék a macOS on iPad-et; onnantól a Surface-nek nagyjából vége.
- A hozzászóláshoz be kell jelentkezni
POWER nem halott.
Verseny kepes specialis feladatokra, in-memory DB, HPC.
A kerdes az hogy lesz olyan RISC-V varians ami POWER `ellen` megy..
- A hozzászóláshoz be kell jelentkezni
Intel szerint nem:
https://www.pcworld.com/article/3606592/intel-benchmarks-say-apples-m1-…
Valoszinu hogy valamikor egy nem x86 tenyleg legyozi az x86-ot altalanos celu
szamitogepben (is), de ez meg nem jott el.
M1 `memoria a chippen` miatt 3x nagyobb memoria savszelleseggel rendelkezik,
igy nem mindegyik teszt fair core teljesimeny hasonlitashoz,
foleg hogy a verseny tars egy ~2014 -es DDR4 standardot hasznal meg mindig.
(Kerestem videot, hogyan lehet cserelni, upgradelni a memoriat egy M1 -en, egyenlore nincs)
M1 5nm, nem fair core hasonlitas 5nm vs 10/7nm.
~30% al kene gyorsabbnak lennie olyan teszteken,
ahol memoria interfacen nem nyer, ha core -t akkarod szidni.
ARM9 (SVE2) hamarosan erkezik, meglatjuk.
DDR5 5nm x86 is lesz .
SoC persze lehet hasonlitani, de ebbel meg nem kovetkezik, hogy gonosz CISC x86-at a jo
kepu RISC megveri, meg nem kovetkezik.
Kovetkezo par eveben nagy felfordulas lesz CPU/NPU/GPU korul,
a piac akkar at is rendezodhet, lesz par meglepetes ..
- A hozzászóláshoz be kell jelentkezni
Erről volt egy cikk a HWSW-n, hogy az Intel szerint mennyire nem: https://www.hwsw.hu/hirek/62891/intel-apple-m1-tiger-lake-macbook-noteb…
Érdemes szerintem más szemmel is nézni, nem csak pusztán a számokat.
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Szerintem az Apple otthagyta a POWER-t amikor képtelenek voltak egy G5-ös laptop procit legyártani. Aztán hopp, a szerverkínáltból is eltűnt, kivéve legacy high-end - nyilván ha nem akarod újraírni a brutál számdaráló appodat, akkor szervercsere esetén megtartod, meg az van a marsjárón is biztos ami biztos (de az esést már konzumer go pro-val videózzák)
Ami persze a konzumer piac, én ezt értem, de ez befolyásolja, ha a mérnök dönt éppen az IBM/Oracle Sales segítsége nélkül, mit fog választani, mondjuk az Amazonnál, a Microsoftnál, a Google-nél vagy a Facebooknál, ami a bolygó számítási kapacitásának már észrevehető része.
De mondjuk azt, hogy POWER van volt lesz, oké. SPARC architektúrából viszont az Oracle 17 óta nem hozott ki semmit, az is 20nm-es chipen összerakva több egység az előző generációból, ami az 5nm-es M1-eshez képest úgy hat, mint anno az UltraSPARC III-hoz képest a toronymagas régi Sun szerverek.
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni