Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Qualcomm: slechts paar bedrijven kunnen van x86 op Arm overstappen voor servers

Qualcomm stapt niet uit de markt voor datacenterchips, maar verkleint de divisie voor serverprocessors en brengt deze onder bij zijn bedrijfsonderdeel voor mobiele chips. Volgens Qualcomm zijn maar een paar klanten in staat om de Arm-serverchips in te zetten.

Qualcomm-voorzitter Cristiano Amon ontkent tegenover Reuters een gerucht van meer dan een maand geleden, dat het bedrijf zou overwegen de divisie voor serverchips te sluiten of verkopen. Wel reorganiseert het bedrijf de divisie en wordt deze onderdeel van Qualcomms CDMA Technologies-onderdeel, dat mobiele chips ontwerpt.

De divisie voor serverchips gaat zich richten op grote bedrijven die actief zijn op het gebied van cloudcomputing. Behalve op grote Amerikaanse ondernemingen wil Qualcomm zich via een joint venture richten op Chinese techgiganten als Alibaba, Tencent en Baidu.

"Het is ons erg duidelijk dat de kansen voor Arm liggen bij enkele spelers, die niet het obstakel van x86-software te overwinnen hebben", zegt Amon. Veel serversoftware is voor x86 geschreven, mede door de leidende positie die Intel met zijn Xeons heeft weten op te bouwen. De grote bedrijven zouden hun software nog kunnen aanpassen aan de Qualcomm-chips, maar voor kleine bedrijven zou dat moeilijk zijn.

Qualcomm had hoge verwachtingen van zijn Centriq-chips voor servers, die onder andere een betere prestatie-per-watt dan de Intel Xeons zouden bieden. De markt voor Arm-serverchips is echter niet zo gegroeid als gehoopt, en Qualcomm is bezig zijn kosten te verlagen en zich te concentreren op zijn kernactiviteiten om de winstgevendheid te vergroten.

Door

NieuwscoŲrdinator

108 Linkedin Google+

Reacties (108)

Wijzig sortering
De hardware was er al in sommige ARM apparaten, maar het maakte geen deel uit van de ARM instructieset. In het geval van TI's implementatie kreeg je het ook alleen in de High Security varianten van de chips en was er geen openbare documentatie tot jaren later. Ik weet niet waar je het vandaan haalt dat dat jarenlang veel sneller was op ARM SoCs; de AES instructieset voor x86 stamt uit 2008, de eerste hardware implementatie volgde in 2010.

Hexagon/Spectra hebben daarnaast niets te maken met ARM. Dat zijn DSPs die los staan van de CPU core. Waarom zou Intel (of AMD) dat in godsnaam in hun processoren bakken? Qualcomm doet dat, omdat in hun primaire doelmarkt 99,9% van de producten ook een image sensor bevat. Een DSP/ISP is dan een logische toevoeging.

Zeggen dat ze achter lopen omdat ze geen DSP mee leveren is zoiets als zeggen dat Qualcomm achter loopt op Google omdat ze geen hardware oplossing specifiek voor NN/ML hebben terwijl Google dat wel heeft met hun TPU's.

[Reactie gewijzigd door Werelds op 14 juni 2018 12:34]

Ik weet niet waar je het vandaan haalt dat dat jarenlang veel sneller was op ARM SoCs
Waarschijnlijk een pamfletje van VIA uit 2009 of zo, is nu wat lastig om terug te vinden.
Hexagon/Spectra hebben daarnaast niets te maken met ARM
--> Zeg ik nergens slimpie ;) Feit is dat ARM SoC's de afgelopen 10 jaar veel meer hw-accelerators hadden als x86-chips; Intel (maar ook Apple die nu ook in een keer een "ai-unit" hebben, ook een DSP'tje) is nu met een inhaalrace bezig.
Dat is de aanpak van ARM: Hardwarematig oplossen wat Intel softwarematig doet.
:Y)

Hoe is Intel dan met een inhaalrace bezig? Ze hebben nog steeds niets van dit alles hoor. Zijn ze ook niet mee bezig.

Dat laatste is ook onzin. Welke "hw-accelerators" mist een desktop-/servercpu dan die je in SoCs specifiek bedoeld voor mobiele apparaten wel vind, waar Intel of AMD commercieel iets mee kan?
Even Intel vacatures lezen en u ziet dat het volstaat met SoC vacatures.

Geheugencontroller (AMD) en GPU waren het eerste wat Intel moest inhalen qua integratie. DSP (als AI accelerator verkocht) en ISP was reeds genoemd, dan nog hw-video en audio codecs, Core 2 duo had moeite en 90% CPU load bij video (h.264 was het niet?) wat een Raspberry beter kan. Daar komt dan nog bij Ethernet, radio (LTE en WiFi, Bluetooth), SPI / I2C, USB, PCIe, een vorm van trusted module en nog wat van die blokdiagram-kreten.
En helemaal niets van dat alles heeft ook maar het geringste met ARM te maken :)

Sommige van die dingen vind je inderdaad terug in SoC's die ARM cores hebben, maar het heeft allemaal niets met ARM te maken. Zowel de instructieset als de holdings niet. Voor bijvoorbeeld AES bestaan ook aparte blokken, maar dan vind je ze ook niet terug in de instructieset die bij dat product horen. Een iGPU (waartoe traditioneel ook video en-/decoders toe behoren) zit ook niet in de ARM danwel x86 instructieset.

Je trekt de hele discussie uit z'n verband, dit heeft allemaal niets te maken met ARM vs x86. Als je het zo wil bekijken ga ik de GPU ontwerpen wel eens uit elkaar trekken, want daar hebben ARM SoC's toch ettelijke jaren heel veel in moeten halen.
En helemaal niets van dat alles heeft ook maar het geringste met ARM te maken
U claimt dus dat het ARM-ecosysteem niets met ARM heeft te maken, en u snapt zelf ook dat dit onzin is.

Het hele ARM-ecosysteem waarbij standaard IP-blokken onafhankelijk van de leverancier gemixt en gematcht kunnen worden, is uniek voor ARM: Voor Power, X86, Itanium en bijv. SPARC heeft dit nooit (op die schaal) bestaan.

Daarom kan ik geen DSP blokje in licentie nemen bij CEVA en aan een x86-CPU vastplakken, en daarom kan dat wel bij ARM.
Als ik me niet vergis is een X86 chip ook RISC op de backend met een slimme decoder ervoor die de CISC naar RISC translatie doet.

Dus waarom RISC inherent trager zou zijn lijkt me een beetje uit de lucht gegrepen.

En ja, als je SSE en AVX ( maar ja dat is weer niet elke processor en dan heb je ook nog AVX, AVX 512 etc en dan ook nog shitload aan differentiatie in de verschillende processor types van Intel waarbij de een weer meer AVX registers ondersteund dan de ander en de processor zichzelf ook nog throttled vanwege de hitte die AVX genereerd ) gebruikt zal je dezelfde trucjes moeten toepassen op je ARM port.

Lijkt me niet onoverkomelijk, maar ja dan moet het financieel wel uitkunnen. En als je dan direct al zegt, veel bedrijven zullen er niets aan hebben dan wordt het zo'n self fulfilling prophecy.
Zoals ik mezelf hierboven al corrigeer, zijn RISC en CISC niet echt meer correct voor moderne CPU's (geldt voor beide richtingen; ARM is niet strikt RISC en een moderne x86 functioneert vaak zat als RISC). Dat is mijn fout.

Het probleem zit hem vooral in heel specifieke instructies die je in ARM niet zult vinden. Zoals ik in mijn reactie hierboven al aan geef, zal ik vanavond even naar wat benchmarks zoeken, er is vast wel ergens een goed voorbeeld te vinden. Dat geldt voor zowel de "basis" instructiesets als de uitbreidingen. Er zitten dingen in SSE of AVX die je in Neon niet vindt terwijl dat andersom minder voor komt.
RISC vs CISC is een tegenstelling uit de jaren 90 en niet meer relevant voor de moderne tijd.

ARM en POWER chips zijn tegenwoordig zo complex dat 'reduced instruction set' de naam niet meer dekt. En Intel/AMD-chips zijn sinds Pentium Pro (1995!) intern ook een RISC-processor die zogenaamde "micro-ops" uitvoert. Daarvoor is een decoder gebouwd die de CISC-stijl instructieset vertaalt naar de RISC-instructies. Dus de tegenstelling die probeert op te voeren hier is al meer dan 20 jaar niet meer relevant.

Zie ook dit Ars Technica-artikel uit 1999(!):
The majority of today's processors can’t rightfully be called completely RISC or completely CISC. The two textbook architectures have evolved towards each other to such an extent that there’s no longer a clear distinction between their respective approaches to increasing performance and efficiency.

[Reactie gewijzigd door DCK op 13 juni 2018 17:26]

Ik heb mezelf daar al op gecorrigeerd :)

Ik doe dit te vaak hier op T.net, dingen te veel vereenvoudigen in m'n reacties :P
Bovendien: als RISC vs CISC werkelijk zo'n belangrijke factor was, dan draaide alles nu op POWER en SPARC, die bestaan al decennia lang in de servermarkt, en Intel heeft zich toch met x86 aardig in die markt binnengevochten.

Het lastige van Qualcomm is vooral dat ze op mobile een enorm voordeel hebben aan hun ingebouwde LTE-modems, niemand anders die zonder een stevig bedrag te betalen 4G-connected chips kan bakken. De aanval van Intel is daardoor ook rap afgeslagen, en andere concurrenten als Samsung, Mediatek en nVidia worden daardoor eenvoudig op afstand gehouden (zo erg dat het voor Samsung zelfs zinniger is om in de VS Qualcomm chips te gebruiken voor hun telefoons). Maar in het datacenter geven die LTE-patenten je geen enkele voorsprong, en moet je bovendien heel ander soort architecturen gaan ontwikkelen - meer I/O, virtualisatie, high-speed interconnects, meer cache, etc. Daar helpen de mobile-optimised ARM-designs ook niet echt.

Er is op zich geen specifieke reden waarom je met de ARM instructieset geen goede serverchips zou kunnen maken, maar simpelweg wat mobile-optimized cores bij elkaar verbinden ben je er nog niet, het heeft Intel ook vele jaren (en een mislukt project met HP genaamd Itanium) gekost zichzelf de high-end sector in te vechten. Als Qualcomm een shortcut zou willen richting high-end cpu design zouden ze de SPARC designs van (mede-TSMC-klant) Oracle kunnen kopen, en kijken of je die monsters als ARM chip kan omtoolen. Zo is AMD ook ooit begonnen met een x86 front end op een bestaand RISC-design te knutselen, daar is niks mis mee.
Skylake is op een 14nm CPU server proces, ThunderX2 is een 16nm FinFet smartphone proces vergelijkbaar met Intels 20nm.

Verschil zit vooral in proces, minder in architectuur.

Met wat mazzel zijn het gelijkwaardige Intel 10nm en TSMC 7nm HPC tegelijk klaar voor servers, dan wordt t pas echt interessant.
Kijk eens naar wat ze wťl supporten. Die software is sowieso portable. ARM is een geldkwestie voor ORacle; waarom zou je de moeite doen? Een paar lousy centen op de CPU besparen maakt niet uit als je Oracle licenties moet afrekenen.

Nee, het grote probleem is dat grote DB's vooral I/O bandbreedte moeten hebben, en RAM cache. Dat kun je niet in software fixen.
Ik zeg niet dat Oracle slechte hardware ondersteuning heeft, of dat het zinvol is om voor databases ARM te gebruiken. Maar doordat ze bijvoorbeeld de cliŽnt niet op ARM hebben kan je dus ook niet en applicatie draaien die die cliŽnt nodig heeft, en dat dit bijdraagt om ťťn van de redenen dat bedrijven niet makkelijk zouden kunnen overstappen naar ARM.
Zijn er eigenlijk cijfers of de energie besparing?

Als het bv max 35w is voor een xeon en 30 voor arm dan is dat misschien handig in een data center met duizenden chips maar voor thuisgebruik maakt een paar procent minder stroom verbruik weinig uit. Zeker als je eerst ook nog nieuwe hardware moet aanschaffen.
Dat dacht ik vroeger ook, tot ik DEC systemen van 20 jaar oud tegen kwam die nog gewoon werken en die er nog steeds soms staan na 30/35 jaar.

Geen modern systeem wat dat nog doet.
Maar worden die systemen nog ondersteund tegen een normaal bedrag? En als het vervangen moet worden, is de kennis dan nog aanwezig wat er op detailniveau gebeurt? Kan een kostenpost worden weet ik uit ervaring.

Vervangen of onderhouden moet toch altijd een afweging blijven.
Klopt, maar helaas is dat de realiteit. Het meest beangstigende is dat het bij instanties is waar je je van kan afvragen of het echt geen tijd is om te vervangen omdat gewoonweg de veiligheid van medeburgers in het gedrang is. Maar ook bij financiŽle dienstverleners kwamen ze voor, weet nog dat bij een grote bank tot 10 jaar geleden nog PDP11 systemen draaiden voor de airco/luchtzuivering.
Had een soortgelijke ervaring bij een bedrijf dat actief zoekt naar computers met een 286 processor. Omdat deze wel gewoon gebruikt kunnen worden in hun omgeving waar het continue -23 graden Celcius is en modernere apparatuur (door condens vorming) zo vlug kapot gaat dat het voor hen zo goed als waardeloos is.

Zolang het blijft werken, is er voor hen geen reden om over te stappen.
Is trouwens een gouden markt, spare parts voor oude Digital en Wang systemen, en natuurlijk oude ISA kaarten en bijbehorende 286 systemen.
Uiteindelijke zullen er inderdaad kant en klare oplossingen komen. Maar ik denk toch dat het nog tegen gaat vallen. Microsoft zit overal goed ingeburgerd, dus ik denk dat het pas echt gaat gebeuren als Windows Server op ARM draait, en dat gaat echt nog wel even duren. Uiteraard zijn er ook bedrijven waar Linux meer gangbaar is en daar zal het ook wel sneller gaan. Maar ik werk bijvoorbeeld bij een ( vind ik zelf :P ) grote organisatie ( 13.000 man ) en ik mag hier niet eens een Linux webserver gebruiken. Allemaal IIS, de rest komt het domein niet eens in...
Ach MS heeft in het verleden Alpha en Mips ondersteund en Windows 10 kan ook op ARM draaien dus ik denk dat ze al wel een port klaar hebben.
Het ligt er inderdaad aan waar je werkt. Bij mijn laatste baan had ik Windows op mijn laptop, maar het meeste werk werd gedaan op Linux/UNIX en daarnaast had ik lokaal nog wel een virtuele Linux machine draaien. Het was alleen wel zo dat alle commerciŽle software eigenlijk alleen bestond voor Linux op x86.

Voor non-x86 hardware werden nog wel AIX, HP-UX en Solaris ingezet, maar deze servers werden steeds meer door Linux op x86 vervangen. Als je niet vastzit aan Oracle of DB2 en commerciŽle ETL tools, dan lijkt me de overgang naar ARM of POWER niet al te moeilijk. Maar dat is veel gemakkelijker voor nieuwe bedrijven die niet al te veel bagage uit het verleden hebben.
Die dingen zijn voor geen meter te beheren, veel te afhankelijk van rondklikken in een GUI. Powershell is veel te complex
Dat botst nogal wat je hier zegt, vind je ook niet? Als je gewoon zorgt dat je Powershell kan, hoef je ook niet te klikken. Ze zijn verder heel prima te beheren hoor, ik hou van klikken. :)
We hebben 1 Windows server VM op kantoor draaien als ondersteuning voor de desktops van de niet-IT'ers (IT draait allemaal Linux of Mac) en dat is het.
IT wat Mac draait, dat hoor je pas weinig haha! :P Waarom is dat dan als ik vragen mag? Wat is de meerwaarde?
Probeer dan eens SmarTTY in plaats van Putty, dan zul je zien dat zaken in een mixed Windows/Linux omgeving een flink stuk prettiger werken.
Volgens mij snap jij heel het principe van containers niet. Beheren? Nee!

Als er iets veranderd moet worden bouw je of je image opnieuw en start je de container opnieuw met nieuw image. Of je past de environment aan en restart je de container.

Kijk eens naar 12factor applications.

Als je meer isolatie wil met gebruik van containers kijk eens naar gVisor.

Kom op zeg. Diskspace een issue? Wil je soms alles op nvme draaien

[Reactie gewijzigd door cybermans op 13 juni 2018 18:22]

Dat is leuk voor een webapplicatie die alleen requests moet verwerken, maar bij ons vond een ander team het nodig om Jenkins in een container te dumpen. Want dat was zo makkelijk om op te zetten. Ofzo. Leuk joh, alle configuratie en buildbestanden in een filesystem waar je niet bij kunt. Een image opnieuw bouwen kun je wel vergeten want dan ben je alles kwijt.

Het is heel hip tegenwoordig om containers de oplossing voor al je IT problemen te noemen, maar eigenlijk zijn ze maar heel beperkt nuttig.
Je mist het probleem totaal.

Bedrijven hebben jaren gewerkt aan software. Dat porten naar een ander platform levert ontzettend veel risico op en dus werk om het te kwalificeren en garanderen dat het bij de klant niet omvalt. Dat weegt niet op tegen een iets minder efficiŽnte hardware gebruiken wat zich al lang in combinatie heeft bewezen.

En dat gaat nou eenmaal iets verder dan jouw hobby projectje.
Behalve wanneer het om disruptive innovation gaat, dan kun je je het als niet-vastgeroest bedrijf niet permitteren om niet voor de oplossing te gaan met de beste prestaties/euro. En dat is dus niet altijd Windows of Linux op x86.

Voor machine learning is een IBM POWER9 oplossing bijvoorbeeld veel beter geschikt dan een Intel Xeon oplossing. En zo zal ARM ook zijn voordelen hebben voor sommige toepassingen en nadelen voor andere.
Raspbian is een distributie van Linux. Er zijn al sinds jaar en dag apparaten met een ARM chip die een of andere versie van de Linux kernel draaien. Als je dus een OS hebt wat geen ondersteuning heeft voor ARM ben je dus al snel heel veel ontwikkeltijd kwijt (als het al mogelijk is zonder een complete rewrite te doen).
Beetje raar verhaal, ik wacht zelf al een paar jaar op een simpel NAS boardje met een ARM processor. Elke keer is het "dat komt dit jaar" en nu is het er nog niet.
Dat is toch heel simpel. Dat simpele NAS bordje met ARM processor moet voor jou goedkoop zijn, dat betekend dat het voor de maker weinig oplevert en als de vraag niet enorm is, dan is het al helemaal niet interessant. Nu blijkt dat de vraag niet enorm is, dus wordt het niet gemaakt...
Ik denk dat het probleem is dat ze de source code niet hebben.
Als de server een of ander standaard (ingekocht) pakket draait, dan is dat mogelijk alleen voor x86 beschikbaar als binary, en is er geen alternatief op andere platformen.

GUI is doorgaans geen probleem, de meeste servers hebben niet eens een monitor, en de GUI wordt alleen door systeembeheer gebruikt.

Technisch is het allemaal geen probleem, de problemen van migratie naar andere platformen gaan doorgaans meer over beleid, politiek en, niet te vergeten, geld.
ik wacht zelf al een paar jaar op een simpel NAS boardje met een ARM processor.
Trek een willekeurige low-end NAS open en je vind waarschijnlijk een simpel bordje met ARM-based CPU.... al jaren.
Debian is geen eerlijke vergelijking.

Van die repos is alles open source beschikbaar (m.u.v. non-free), dat maakt het omzetten van alle bende ook een heel stuk makkelijker.

In de server en enterprise wereld is bar weinig open source. En zet je echt niet zo maar alles over, en moet je ook zeker niet afhankelijk willen zijn van verscheidene 3rde partijen. Het upgraden van een OS is hier soms al moeilijk zat, laat staan je hele hardware inboedel overhoop halen.
Maar dat is niet waar het meerendeel van alle servers in de wereld op draait. De grote boeren draaien voor het grootste deel a) Linux en daar bovenop b) hun eigen applicaties of c) nog meer Open Source. Denk aan Amazon, Google, Microsoft, Apple, Cloudfront etcetera.

Juist partijen die third party applicaties zonder source draaien zijn vaak wat meer niche en dan draait het ook niet op 10.000en servers. Hoeveel Exchange servers heeft een bedrijf echt nodig? Of SAP? Tientallen? Voor een groot bedrijf? Zet dat af ten opzichte van wat de grote cloudboeren hebben draaien en het is niet meer dan een druppel op een gloeiende plaat.
Klopt, maar jij zegt wat anders. "Tenzij je op commerciŽle extern gebouwde software vertrouwt? Maar ook dat is toch vrij makkelijk te hercompileren naar ARM?"

Dat botst enorm. "commerciŽle extern gebouwde software" is helemaal niet vrij makkelijk te hercompileren. Je bent 100% afhankelijk van de bouwer. Stellen dat dat makkelijk is, zal per geval zeer verschillende uitkomsten opleveren. De ene werkt zo met je mee en de andere wil dat helemaal niet, want levert niks op.
Het is vrij makkelijk te hercompileren door de bouwer, zelf kun je dat uiteraard niet doen. Maar als je een klant bent die echt op grote schaal servers uitrolt dan mag je best wel eens wat vragen aan je leverancier. Het gaat voor Qualcomm niet om de hoeveelheid bedrijven maar om de hoeveelheid servers. En die verdeling ligt vrij scheef aangezien relatief weinig bedrijven maar gespecialiseerd zijn in taken waarbij duizenden servers nodig zijn. Een normaal bedrijf heeft maar een handjevol servers. En die gaan ook steeds vaker dingen juist in de cloud zetten bij een van die grote partijen. Maakt het jou uit of je Exchange op ARM draait of op x86 bij Microsoft? Alleen als de rekening anders is.
Zo makkelijk is dat altijd niet, vooral in de enterprise wereld hebben developers er een handje van om troep te 'exploiten'. Hoezo API's volgen als ik via deze hack het makkelijker kan. Zoek maar eens op hoe ziek veel uitzonderingen hiervoor in de Win32 API zitten, de Wine developers schrijven er soms wel leuke blogjes over.

Software wat halfbrak draait poort je niet zo maar naar een geheel ander platform. Zeker geen kwestie van even op de knop drukken om te hercompileren.

Daar komt de optimalisatie nog bij op. Veel software weet perfect gebruik te maken van de X86 instructies, maar bij het ontwikkeling is geen rekening gehouden met bv KISS, zo maar even wat instructies 'dumb downen' doe je lang niet altijd zo maar.

[Reactie gewijzigd door batjes op 13 juni 2018 19:33]

Je mist d) Een boel closed source enterprise software is gewoon beschikbaar op o.a. Linux.

Sommige bedrijven leunen op tientallen, honderden applicaties en bijbehorende zut. Prorail zit dacht ik al over de 150 client applicaties heen (als ik het me goed herinner) en zo'n bizar grote partij is dat niet.

Vergis je er niet in hoeveel enterprise software er beschikbaar is op Linux, hoeveel frontend Windows client applicaties waarbij de hele backend er van op Linux draait.
Er stond juist in het artikel ook expliciet genoemd dat voornamelijk kleine bedrijfjes er moeite mee zouden hebben. Maar kleine bedrijfjes gebruiken helemaal geen Citrix of SAP, dat is veel te duur.

Overigens is "volgens mij al geport" een flinke understatement. LAMP is al cross-architecture zolang ik me kan herinneren. Alle gangbare open source Linux software kun je op een veelvoud aan platformen draaien. Niet alleen de LAMP stack, maar iedere moderne programmeeromgeving, webserver, database, etc.
Ubuntu bv heeft officiŽle ondersteuning voor meerdere architecturen, niet alleen ARM maar ook power en s390x: https://www.ubuntu.com/download/server
Er mag gezegd worden dat het echt niet op gaat voor alle databases/stores hoor. Denk Oracle, ElasticSearch, daar gaat het niet verder dan "You can compile for linux on ARm without support." Dat is natuurlijk niet goed genoeg. Het gaat vaak fout als men ook nog support wil. (Dat geldt voor MySQL, PostgreSQL, MariaDb, Percona, MongoDB; bijna allemaal dus.)
Gewoon een kwestie van Debian Stable installeren. ARM support voor alle core packages.

Percona is de vreemde eend in de bijt hier, dat is meer een bedrijfsproduct dan een FLOSS package.
Debian Stable "support" is wel heel anders dan zeg de business Oracle MySQL support of zelfs de Postgre support contracts (3rd-party).

Daarij is Percona nou juist de enige die hun fork volledig open source heeft.
Denk dat wat ze in dit geval kleine bedrijfjes noemen, groter zijn dan we denken. Echt niet de bedrijven van 10-50 man.
Is dat op de dag van vandaag nog steeds het geval? De ARM instructieset wordt steeds meer en meer uitgebreid
Nog steeds valide, en Arm is nog steeds een single word instructie taal volgens mij. Enige uitbreiding op de set is nu 64 bit en Neon.

[Reactie gewijzigd door Wim-Bart op 13 juni 2018 18:44]

Lol nee. ARM heeft de meest CISC-y extensie ooit, Jazelle DBX (Direct Bytecode Execution). Een complete set extra instructies speciaal voor Java.
Dat is een extension volgens mij en niet iedere Arm SOC heeft het, maar zeker ervan ben ik niet. Was het helemaal vergeten dat ze dat inderdaad hebben. Een smet op de architectuur naar mijn inzien.
Waarom zou je dan overstappen? Klinkt alsof je testkandidaat van Qualcomm wordt.
Ja en? En wij stellen importheffingen in op amerikaanse bedrijven. Geen gewenste situatie, maar de VS pakken we blijkbaar gelijk aan.

Kijk nu naar china. Hoe pakken wij de oneerlijke handelswijze van china aan? Hoe pakken wij de chinese staatssteun aan chinese bedrijven aan terwijl daardoor door oneerlijke concurrentie met onze europese bedrijven ontstaat en europese bedrijven daardoor zelfs failliet gaan. Westerse bedrijven krijgen geen of moelijk voet aan de grond in china, terwijl china in onze open economie vrij spel heeft. Is dat eerlijk? Ik vind van niet en we laten het toe dat er misbruik van onze economie wordt gemaakt. Wat dat betreft heeft Trump gelijk, handelsverdragen moet eerlijk een gelijkwaardig zijn. Of Trumps manier de juiste is is een ander verhaal, maar misbruik toelaten vind ik ook niet wenselijk. Als EU moeten we eens daadkrachtig optreden, iets wat Trump wel doet, ongeacht of je het eens met Trump bent, hij doet tenminste iets en dat kan ik wel waarderen van Trump. Maarja, Trump erkennen dat ie iets goeds doet is natuurlijk not done, want Trump. :r
EU moet krachtiger optreden tegen zowel China alsook Amerika. Maar beiden weten het zeer zwakke punt van Europa:

Geen samenhang. Elk land kijkt op dit moment alleen naar zijn eigen belang en dat spelen beide landen slim uit.

Als alle neuzen dezelfde kant opstaan is Europa net zo machtig als China en Amerika.


Om te kunnen reageren moet je ingelogd zijn


Call of Duty: Black Ops 4 HTC U12+ dual sim LG W7 Google Pixel 3 XL OnePlus 6 Battlefield V Samsung Galaxy S9 Dual Sim Google Pixel 3

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V. © 1998 - 2018 Hosting door True

*