'W10 op ARM presteert met Snapdragon 845 tot 50 procent beter dan met 835'

In de Geekbench-database zijn benchmarkresultaten verschenen van een Lenovo-systeem met Snapdragon 845-soc. De processor is hoger geklokt dan bij smartphones en presteert op Windows tot 50 procent beter dan een Snapdragon 835.

De benchmarkresultaten staan in de Geekbench-database bij twee systemen, een met de naam Qualcomm CLS en een dat Lenovo Invalid genoemd wordt. De systemen hebben 4GB ram en een moederbord met de naam Europa. Dat het om systemen met de Snapdragon 845-octacore gaat blijkt onder andere uit het cpu-id en de kloksnelheid, suggereert Winfuture.

Die kloksnelheid bedraagt 2,96GHz en dat is hoger dan het maximum van 2,8GHz bij smartphones met de Snapdragon 845. Het is ook hoger dan de 2,21GHz en 2,6GHz van de Snapdragon 835 waar respectievelijk de HP Envy x2 en Asus NovaGo mee uitgerust zijn.

Bij de singlecoretest presteert het Lenovo-systeem met Snapdragon 845 zo'n 50 procent beter dan een Asus NovaGo met Snapdragon 835. Bij de multicorebenchmarks is dat zo'n 25 procent hoger. Dat er laptops met Snapdragon 845 verschijnen is geen geheim: Microsoft en Qualcomm maakten dat zelf al bekend. Wanneer de introductie komt is niet bekend. Wellicht presenteren fabrikanten de eerste modellen tijdens de Computex-beurs, die begin juni in Taiwan plaatsvindt.

Microsoft en Qualcomm introduceerden de eerste Always Connected PC's met Snapdragon-socs en lte-modems vorig jaar. Het gaat om laptops met lange accuduur die continu met internet verbonden zijn dankzij onder andere 4g-integratie. Als nadelen worden de relatief lage prestaties van de Snapdragon tegenover Intel- en AMD-chips en de wat dat betreft hoge prijs van minimaal 599 dollar gezien.

Reacties (85)

[Luinwethion]

Tijdens MWC hadden ze (iemand van Qualcomm of MS, weet ik niet meer) toch over dat de keus voor de SD835 voor de huidige generatie Always connected PCs was omdat de rendement verschil niet zo groot was?

Anyways, hopelijk blijft MS investeren in deze rechting, ik zie veel potentie in een ARM powerded laptop als we straks minder afhankelijk zijn van x86 virtualisatie.

[klakkie.57th]

En waarom zie jij toekomst in pc’s met een arm chipset ? Ik zie zo meteen niet echt een voordeel, in zie alleen maar versplintering van het landschap.

[Gamebuster]

Er hoeft geen sprake te zijn van versplintering. De meeste software die je maakt kan je prima voor meerdere platformen compileren, het moet alleen gewoon gedaan worden.

Wat je bijv. kan doen is een soort bytecode verspreiden en dan JIT compileren voor je gewenste platform, zoals je gewend bent van Java. Volgens mij zijn er al meerdere trajecten op gang om dit gangbaar te maken, waaronder de UWP van Microsoft, en bij Apple lever je volgens mij ook al vaak een kopie in van een stuk bytecode dat zij dan kunnen compileren naar meerdere platformen.

Ik weet niet hoe dit exact werkt overigens; Bij Java is er sprake van een soort virtual machine, bij C# geloof ik ook; in dit geval deploy je je bytecode naar de client, en de virtual machine doet dan de bytecode compileren op het moment dat je de applicatie start.

Voor het Apple ecosysteem heb je volgens mij een compiler-stap die je code compileert tot een stuk bytecode die vervolgens de bytecode kan compileren naar een native app o.b.v. je platform. Dit wordt gedaan door Apple voor alle compatible apparaten, zodat je meteen een "juiste" versie kan downloaden. Volgens mij zijn er ook situaties waarbij je 1 Apple app bundle hebt met daarin verschillende binaries per platform.

Maar mijn kennis is vrij beperkt/stoffig op het gebied. Ik weet de exacte details niet, ik weet alleen dat er op vele niveaus allerlei experimenten en innovaties zijn geweest die het hele proces transparant kunnen maken voor zowel de gebruiker als de ontwikkelaar.

[Reactie gewijzigd door Gamebuster op 1 augustus 2024 14:53]

[Hans1990]

Bij Java en C# is er inderdaad sprake van JIT compilers. De IL code (intermediate language) is nog op redelijk hoog niveau. Zelfs op zo'n hoog niveau dat het een soort tokenization van de code is, wat het mogelijk maakt om IL terug te zetten naar C#/Java code.

De "Just In Time" runtime heeft de optie om de IL code te interpreteren of te compileren naar de instructieset voor het platform. Het compileren heeft wel enige one-time overhead, dus sommige JITs hebben een afwisseling tussen de 2; als een stuk code veel gedraaid wordt kiest het dan pas voor compilatie.

In C#/Java is dus een kwestie van support dat de run-time met JIT is overgezet. Dan heb je as-good performance van de taal en zou alles moeten werken zoals gewend. Natuurlijk zullen optimalisaties hier en daar mogelijk zijn -- zo zijn er libraries die afhankelijk van de instructieset eigenschappen (vroeger SSE, nu AVX bijvoorbeeld) van de host CPU, daar wel/niet gebruik van kunnen maken. Natuurlijk moeten deze ondersteuningen wel ingebakken zijn.

Er worden echter ook veel programma's nog in C of C++ geschreven. Daar bij ben je toch iets afhankelijk van hoe het CPU/geheugen architectuur werkt, wat de functionaliteit kan doen breken. Niettemin bij goed geschreven code is het een keuze voor welk platform je compileert - ook aangenomen dat alle dependencies beschikbaar zijn.

Bij GNU en Linux zie je doordat de code open beschikbaar is, dit al jaren lang mogelijk is. Er is ook een actieve wens om dit te doen, omdat Linux ook veel wordt ingezet op embedded ARM computers zoals de Raspberry Pi. Door deze support is betrekkelijk het eenvoudig om een C/C++ programma op je PC te schrijven, en die vervolgens dan ook voor een RPi te compileren.

Enkel als je op een heel laag niveau komt, binnen het OS wat regelrecht tegen hardware aan zit; dan ga je grote verschillen krijgen. Maar ik denk dat dit stadium al voor een groot deel geweest is. De Windows kernel draait al op ARM, dus veel van dit werk is al geport. Zaken zoals USB drivers zouden in theorie ook gewoon overgezet moeten kunnen worden, aangenomen dat alle USB communicatie via een interne API (bijvoorbeeld libusb) loopt.

Ik denk dat voor Windows het een kwestie van tijd is dat ARM een volwaardig alternatief wordt op x86. Het heeft alleen tijd nodig dat developers hun programma's kunnen "crosscompilen" afhankelijk of al hun dependencies beschikbaar zijn. Maar een programma die geschreven is in 1 van de "IL code"-achtige talen, zitten al redelijk snor.

Een ander deel is ook de hardware ondersteuning. Desktop computing heeft echt baat bij piek performance van 1 core. Gaming en workstations hebben pas echt baat bij hogere multi-core systemen. Als ik de benchmark screenshot zie, dan merk ik op dat er echt grote stappen zijn gezet op single-core gebied. Dat is het allermooiste nieuws.

[Reactie gewijzigd door Hans1990 op 1 augustus 2024 14:53]

[Luno]

Er worden echter ook veel programma's nog in C of C++ geschreven. Daar bij ben je toch iets afhankelijk van hoe het CPU/geheugen architectuur werkt, wat de functionaliteit kan doen breken.

Zolang de code C/C++ is, zou de functionaliteit niet gebroken mogen zijn. De taal definitie schrijft geen CPU/architectuur voor. Perfomance kan we lijden onder een cpu. Bv. als je een 8bits cpu hebt die zelf geen integer*32 operaties heeft moet de compiler daarvoor extra coding genereren. Net zoals je vroegâh een xxx86 cpu en een optionele xxx87 mathematische coprocessor. Zonder die coprocessor was floating point nog steeds binnen C gedeifinieerd, maar moest het daarna in software worden uitgevoerd.

Wel als je specifieke API's voor een OS gebruikt, maar dat is dan geen C/C++ probleem, maar API libraries. iets WINE poogt te doen op Wndows API's onder Linux enzo te implementeren.

[Hans1990]

Er kunnen wel degelijk verschillen ontstaan tussen implementaties als je C/C++ code op een x86 machine of ARM draait. Bvb: x86 is little endian, bij ARM is dat niet per definitie. Veel cores wel, maar afhankelijk van de implementatie kan het ook big endian zijn. Hoewel niet toegankelijk vanuit een applicatie, is het in theorie dus wel mogelijk om een big-endian ARM systeem te hebben draaien.

Dan nog steeds; opzich geen probleem als je binnen de high-level constructies van de taal blijft. Echter in C/C++ heb je ook veel inzicht hoe in data in geheugen wordt opgeslagen met behulp van pointers, waardoor je dus verschillende resultaten krijgt als je de code op een big of little endian systeem draait.

Misschien is dit wat ver gezocht, maar het punt blijft dat het gebruik maken van pointers en deze casten (danwel niet met reinterpret_cast<>) geldige C(++) code is, maar niet per definitie portable.
Alsook dat unaligned memory access op x86 prima is, maar op ARM processors een hardware exception kan geven.

[Reactie gewijzigd door Hans1990 op 1 augustus 2024 14:53]

[qlum]

Voorlopig zijn de desktop applicaties nog steeds gelukkig verreweg het meest gebruikt en daar bestaad zover ik weet geen mogelijkheid om arm applicaties te draaien.

[epdm2be]

"...Er hoeft geen sprake te zijn van versplintering. De meeste software die je maakt kan je prima voor meerdere platformen compileren, het moet alleen gewoon gedaan worden..."

Wat een probleem is gezien sommige devs geen interesse meer hebben in doorontwikkelen/aanpassen van hun app (en de source nou ook niet willen vrijgeven).

"...an JIT compileren voor je gewenste platform, zoals je gewend bent van Java...."
Dus toch nog in virtualisatie werken? Laat het dan toch gewoon zoals het nu is, djeez.
Bovendien is dat allemaal heel inefficiënt. Android, dat vroeger in feite niet meer was dan een basic linux kern met stevig geoptimaliseerde java VM erbovenop, is al terug van dit princiepe. De huidige apk's worden tegenwoordig ge-pre-compiled (ART) om dan in native bytecode te draaien ipv. verwerkt te worden via de JIT-interpreter (Dalvik).

Bovendien bestaat de verwarring voor het grote publiek er (nog steeds) in dat men het onderscheid niet kan maken tussen een x86-only applicatie of een "universal"-app. JIJ en ik (en de duizenden Tweakers) zijn tech-savvy genoeg maar de rest niet. Dat was ook de eigenlijke downfall van Windows op ARM vroeger alhoewel men er waarschijnlijk een draai aan heeft gegeven door met een kunstig in elkaar geflanst excuus te komen.

[Dutch2007]

UWP ;-)

https://developer.microsoft.com/nl-nl/windows/apps

[Luinwethion]

Voor mij is een combinatie van goede accu en goede mobiele verbinding icm de flexibiliteit dat de Windows UI biedt in vergelijking met iOS of Android.

[nullbyte]

Het is leuk als je veel in de trein of in het vliegtuig zit. Overal waar ik verder kom zijn stopcontacten waar ik mijn x86 laptop op aan kan sluiten.

[pe0mot]

Zit nu in de trein met stopcontact.
Deze Lenovo kan een werkdag op accu.
Samengevat pas ik niet in de businesscase van de Arm PC.

[epdm2be]

Zelfs voor thuis.

Zolang de idiote consument maar blijft een laptop te (mis-)gebruiken als desktop vervanger waardoor die batterijen na 2a3 jaar kapot zijn.

Ik begrijp "de wereld" (lees: de overheden die ons vertellen wat mag en niet mag) niet. Aan de ene kant zit men op ons kap dat we milieuvriendelijker moeten zijn en duurzamer producten moeten kopen, maar aan de andere kant dringen fabrikanten ons producten op die nu net NIET duurzaam en slecht voor milieu (batterijen) zijn. En daar "move-d" dan niemand over?

Laat mij een laptop zien de 1 week op een lading gaat en maak me dan nog maar eens wakker.

[arjandijk162]

Een fabrikant moet zijn producten maken voor "normaal" gebruik. Wat jij aangeeft is dat jij "normaal" gebruik anders wil definieren dan wat een gemiddelde gebruiker met zijn product doet. Lijkt me een beetje de omgekeerde wereld.

[epdm2be]

Trouwens waarom zou je in de trein al gaan werken?
Zet gewoon een Oculus GO op je hoofd en heb nog wat plezier ;-)

[kidde]

in zie alleen maar versplintering...

U bedoelt natuurlijk: 'gezonde concurrentie in een vrije markt'.

Op de ARM markt is veel concurrentie, en daarom krijgt de klant in grotere mate een produkt dat aansluit bij zijn wensen voor een fatsoenlijke prijs. Op CPU gebied is er bij ARM ook geen marktverstorend machtsmisbruik.

[Yoshi]

Wel, dat durf ik toch te betwijfelen. Zeker voor gewoon thuisgebruik gaat het volstaan. Maar (de heel voorlopige, is wat koffiedik kijken) performance in software die wel veel eist van de hardware is het toch wel wat minder.

anderzijds is de batterijduur voor onderweg heerlijk natuurlijk voor zakelijke gebruikers. Zal voorlopig toch alleszins nog afhangen van de use case scenario's.

[Reactie gewijzigd door Yoshi op 1 augustus 2024 14:53]

[maevian]

Ja, maar als er genoeg arm laptops zijn, gaan bedrijven misschien rechtstreeks voor arm beginnen compileren, zou me niet verwonderen als je over 5 jaar een arm geoptimaliseerde versie hebt van de Adobe suite

[ro8in]

Moet de ARM processor wel snel genoeg zijn om deze suite te draaien. Ik zie full 4k raw video editing er voorlopig nog niet op gebeuren.

[maevian]

Nu nog niet, maar ze zullen wel snel genoeg worden

[ro8in]

Maar x86’s ook en video staat ook niet stil.

[brabbelaar]

ik ook niet, maar er is ook nog nauwelijks vraag naar. Die processoren worden nu vooral ontwikkelt om in een telefoon te passen. Varianten die iets meer consessies doen om meer vermogen te creëren kunnen natuurlijk ontwikkeld worden.

[Barsonax]

Ik denk niet dat dat zo hard zal gaan. Er zijn zoveel (zware) x86 applicaties. Visual studio en resharper bijv zie ik nou niet zo snel overstappen op ARM de komende 5 jaar. Ik kan niet zonder die applicaties dus dan blijf ik lekker op x86 en tbh zijn een hoop applicaties simpelweg te zwaar voor een mobile processor.

[maevian]

Wie weet wat voor sprongen ARM in 5 jaar niet doet, de gap tussen x86 en ARM word elk jaar kleiner

[Barsonax]

5 jaar geleden werd ook al geroepen dat ARM alles ging vervangen...

[lighting_]

nu de prijs nog. Want de huidige zijn veel te duur

[Luinwethion]

Ik zie die Always connected PCs niet als een budget iets, je hebt een top of de line SoC, goede afgewerkte behuizing, grote touchscreen display, grote accu...

Misschien als Windows verder geoptimaliseerd wordt en we geen x86 virtualisatie meer nodig hebben, kunnen OEMs midrange laptops met een 600 of 700 series SoC uitbrengen.

[walteij]

Maar die x86 virtualisatie is voorlopig nog nodig, want mensen zijn gewend om hun software gewoon te downloaden bij een willekeurige website, setup.exe te runnen en daarmee een nieuw stukje software op hun laptop te kunnen gebruiken.
Microsoft heeft de infrastructuur, het distributiekanaal én de de software helemaal klaar om daarmee te stoppen, zodat ontwikkellaars de applicatie beschikbaar kunnen stellen als x86 of ARM64, voor op een desktop, laptop, tablet of een telefoon, alleen mensen willen gewoon simpelweg niet veranderen.

[Verwijderd]

En laten we hopen dat dat zo blijft, en dat de Windows Store zwaar faalt.

Microsoft is nu niet de baas over hoe software op het Windows platform gedistribueerd wordt. Laten we kijken wat er gebeurd wanneer dit wel zo is:

- Microsoft kan gewoon even een tax (30% of zo) op alle software plakken. Software waar ze geen cent in geinvesteerd hebben maar wel eindeloos omzet van blijven pakken. Ze kunnen deze tax ook gewoon eenzijdig veranderen. Zwaar nadeel voor zowel ontwikkelaars als consumenten.

- Microsoft wordt de baas over welke software het geschikt vind, of juist niet, en kan willekeurig apps obsolete verklaren of terugtrekken. Ik bepaal zelf wel welke software ik geschikt vind. De huidige vrijheid hierin is superieur tov een gesloten model.

- Microsoft gaat even als middle man tussen klant en leverancier zitten en tapt zo data waar ze geen fuck mee te maken hebben.

Windows is historisch gezien een vrijhaven, en dat is een goede zaak.

[walteij]

En hoe is de Windows Store dan anders dan die van Apple of Google/Android?
Ook zij romen pakweg 30% van de prijs af met dezelfde investering als Microsoft. Ook zij keuren software goed of af, ook zij zitten als tussenpersoon tussen klant en leverancier en zullen ook allerlei data verzamelen.
Is het daarmee goed te praten, nee absoluut niet, maar Microsoft biedt wel de mogelijkheden aan zowel ontwikkellaars als eindgebruikers, om via een veilig en bekend distributiekanaal software aan te bieden of te downloaden.

Ik zeg nergens dat de Windows Store de enige locatie is waar applicaties vandaan mogen komen. Sterker nog, ik leg hier aan iemand uit hoe hij een applicatie kan sideloaden.
Voor de simple huis-tuin-en-keuken-eindgebruiker is de Windows Store echter wel een goede oplossing. Zo kun je op eenvoudige wijze aan gecontroleerde, veilige en legale software komen, die over het algemeen ook nog eens redelijk geprijst is.
Voor (groot)zakelijk en tweakers, is een Windows Store natuurlijk geen serieuze optie te noemen.

[Verwijderd]

Ik zag die opmerking mijlenver aankomen, want in plaats van direct op kritiek in te gaan, is het tegenwoordig blijkbaar makkelijker om dan naar een ander te wijzen. Het neemt geen enkel kritiekpunt weg. Twee keer fout is niet ineens goed.

Dus ja, ook de Apple store en de Playstore heeft de problemen die ik beschreef, met 2 kleine nuances:

- Het is min of meer van meet af aan een centrale store geweest, waarbij Windows eerst 20 jaar zonder store heeft gewerkt. Dat is geen excuus, puur een historisch verschil wat in de praktijk wel belangrijk is.

- Op een mobiel staat doorgaans veel meer gevoelige data dan op een Windows desktop. Veiligheid op mobiel is om die reden belangrijker, wat deels het voordeel van een store versterkt.

[walteij]

Maar je slaat wel keurig mijn nuance over

Is het daarmee goed te praten, nee absoluut niet, maar Microsoft biedt wel de mogelijkheden aan zowel ontwikkellaars als eindgebruikers, om via een veilig en bekend distributiekanaal software aan te bieden of te downloaden.

en ook:

Voor de simple huis-tuin-en-keuken-eindgebruiker is de Windows Store echter wel een goede oplossing. Zo kun je op eenvoudige wijze aan gecontroleerde, veilige en legale software komen, die over het algemeen ook nog eens redelijk geprijst is.
Voor (groot)zakelijk en tweakers, is een Windows Store natuurlijk geen serieuze optie te noemen.

Alle stores hebben nadelen, maar ze hebben ook dezelfde voordelen, namelijk een centrale locatie voor applicaties, welke op een veilige, gecontroleerde en legale wijze verkrijgbaar zijn.
Het grote voordeel van Windows, is dat er voor de meer ervaren gebruikers, voldoende andere manieren zijn om aan je legale software te komen en deze te installeren.
Iets dat op Android en/of iOS een ander verhaal is.
Chromebooks en iPad (pro) zitten nog steeds volledig gelocked in de Stores, waar je bij Microsoft ook op andere manieren legale software kunt installeren (dus zonder een rootkit, of dubieuze websites waar je apk's kunt downloaden).

[Verwijderd]

Veiligheid is een prima argument, maar weet je wat: 30% tax, de macht om software inhoudelijk goed/af te keuren en zelfs terug te trekken, en het afluisteren van een klant-leverancier relatie zijn allemaal volstrekt onnodig om een veilige ervaring te bieden. Maar dat krijg je er wel allemaal bij, wat veelzeggend is over de daadwerkelijke doelstelling van de store.

[walteij]

De software moet gecontroleert worden (dit gebeurt deels automatisch en deels handmatig), de infrastructuur (hardware, bandbreedte enzovoorts) moeten ook betaald worden. Er zitten meer kosten aan de Store dan alleen maar dat ikoontje in je start menu.
Natuurlijk is 30% een erg hoog percentage, dat ben ik helemaal met je eens, maar je hoeft je software niet in de Store te zetten en je hoeft er ook geen geld voor te vragen.

Nu even naar dat andere punt van je. Vertel me eens, met een bronverwijzing aub (dus geen FUD-geneuzel) wat je precies bedoelt met afluisteren.
Bedoel je daarmee dat Microsoft weet welke apps je gebruikt? Want, met de standaard telemetry instellingen, weet Microsoft dat toch wel (wederom, dit is ook niet goed te praten).

[Verwijderd]

Er is geen FUD nodig om te weten dat inderdaad Microsoft exact weet welke apps je installeerd (en mogelijk ook gebruikt). Iets wat zonder store dus niet mogelijk is. Ook gaat het als payment processor tussen klant en leverancier zitten.

[walteij]

Prima, daar wil je dus niet serieus op in gaan.
Blijft alleen de vraag over, wie vertrouw je meer als tussenpersoon. Is dat Microsoft, Google of Apple? ook als het om betalingen gaat.
Ik weet het wel, en ze zitten niet in Cupertino of Mountain View.

[Verwijderd]

Mijn volgorde zou zijn: Apple, Microsoft, Google.

[Verwijderd]

En hoe is de Windows Store dan anders dan die van Apple of Google/Android?

Niet. Gelukkig kun je onder Android sideloaden, al wil Google dat ook lastiger maken. En van Apple blijf ik ver vandaan om o.a. deze reden.

[walteij]

Sideloaden kan bij Windows dus ook. Tablet/Telefoon/PC in developer mode zetten en sideloaden maar.
Tenminste, als het om appx applicaties gaat. x86 of x64 apps kun je natuurlijk gewoon via de setup.exe installeren.

[Umbrah]

Helemaal eens. Ik zou willen dat er meer werkte op die manier. Delta updates zijn zo ook eenvoudig. Ik zou graag SCCM-achtige meuk ook op het werk ontwijken als het even kan. Sideloaden kan bovendien op érg veel manieren binnen Windows. Het is geen zwart(niks mag)/wit (alles mag); er is ook de "alleen signed"-optie, waardoor je als bedrijf ook je eigen appstore veilig kan toepassen. Mocht je de ingebouwde 'domain appstore' niet tof vinden, waar dmv. diverse configuraties apps voor gebruikers in de windows marketplace kunnen worden gezet onder een apart kopje (bedrijfsnaam apps).

Sterker nog; als je een app als APPX download en je voert het uit, zal Windows je zelfs vragen of je unsigned apps wilt toestaan. Wat mij betreft gaat MS naar een "appstore-tenzij" model, hoewel ik uiteraard het er mee eens blijf dat alternatieven moeten blijven bestaan, en sideloaden ook een optie moet blijven. Windows heeft ook vrij eenvoudig standaard PIP, Conda, en apt-get staan... heck... staan zelfs vrij veel linux distro's in de marketplace die zelf ook weer appstores/package managers toevoegen.

[Luinwethion]

Maar die x86 virtualisatie is voorlopig nog nodig, want mensen zijn gewend om hun software gewoon te downloaden bij een willekeurige website, setup.exe te runnen en daarmee een nieuw stukje software op hun laptop te kunnen gebruiken.

En dat is best wel jammer, vooral vanuit de techies/tweakers die dit ontwikkeling als iets slechts zien... Natuurlijk voor de geavanceerde gebruikers wil je nog Windows Pro/Enterprise behouden met alle opties, maar voor de thuis gebruiker wil je die ontwikkeling wel.
Ik zie wel een beetje hypocrisie, waar mensen de veiligheid in iOS als een plus punt noemen, veiligheid die komt onderandere door dat je niks van buiten de App Store mag runnen , en als Microsoft iets vergelijkbaars met Windows wilt doen, dan is het weer slecht.

Je hoeft niet eens alles vanuit de store te downloaden, ook download je een appx installatie file heb je al zo veel winst over een .exe... Wordt niks in je systeem gedaan, installatie kan clean terug gedraaid worden... Maar mensen zien dat niet.

[walteij]

Is het dan zo ver, heb ik dan echt, serieus, een medestander gevonden??

[powerboat]

Hier nog een die het met je eens is

[Luinwethion]

Ik ben totaal voor de Windows store, maar ook als mensen zelf programma's willen blijven downloaden, dat we appx packages gaan gebruiken ipv .exe & family.

Enerzijds begrip ik de zorg van sommige wel, daarom zeg ik dat het bestaan van een Windows Pro / Enterprise versie zonder restricties een must is, maar voor veel thuis gebruikers is niet een zeen kwestie van makkelijker maken, maar van veilig maken.

Straks dat Windows S een optie wordt, ga ik op mijn privé PC zeker gebruiken, en niet omdat ik niet om kan gaan met Windows, ik installeer al veel van de store, maar omdat ik wil gewoon zien hoe werkbaar het is zodat ik andere familieleden kan instrueren, vooral voor de minder geek, het is een geweldige optie vind ik. Prima dat een Tweaker dat niet wilt gaan gebruiken op zijn PC, maar gelijk afhakken als iets erg slechts terwijl iedereen zit al jaren te roepen dat de te veel vrijheid in Windows een risico factor is, tja onbegrijpelijk.

[arbraxas]

Neu klopt, het grote voordeel van Windows in mijn optiek is dat je VOLLEDIG om die randdiebele appstores heen kunt werken. Niet overal voor ingelogd te zijn etc.
Op het moment dat MS appstore only gaat word de overstap naar linux gemaakt.
Ik heb een Lumia 950XL en de grootste irritatie is het niet kunnen doen met je telefoon wat je zelf wilt door allerlei restricties. En helaas kan ik die telefoon niet rooten (Hou me aanbevolen voor een link als ik iets gemist heb)
Zie verder ook de totale mislukking van de gamestore van MS door eigen schuld. Als je een spel op bv steam kunt kopen die wel exclusive fullscreen, SLI / CF ondersteuning bied etc dan nee, laat maar met die "fantastische" store van MS.

Lang verhaal kort, niet elke verandering is per definitie een verbetering.

[batjes]

Zie verder ook de totale mislukking van de gamestore van MS door eigen schuld. Als je een spel op bv steam kunt kopen die wel exclusive fullscreen, SLI / CF ondersteuning bied etc dan nee, laat maar met die "fantastische" store van MS.

Fullscreen of borderless windowed geeft geen verschil in performance meer sinds DWM de bende regelt vanaf Windows 7.

Even gezocht voor bronnen, kan het MSDN artikel zo niet terug vinden, kwam wel reddit tegen, waaronder:

Running in windowed mode adds latency because everything has to be passed through the desktop compositor. (Aero) Full-Screen Exclusive Mode bypasses the compositor so that the game is talking directly to the display.

Klopt alleen geen hol van. Ook fullscreen gaat via de desktop compositie van DWM. Elke grafische call gaat via DirectX over DWM heen.

En Windows Store games, zijn DX12, welke multiGPU's prima kan ondersteunen. Geen SLI/CF meer voor nodig. DX12 kan dit namelijk native (en nog beter ook). Alhoewel ik bij bijvoorbeeld Sea of Thieves lees dat Rare de moeite niet genomen heeft multiGPU te ondersteunen, omdat dit slechts 0.001% van hun gebruikers zijn. Zodra meer mensen multiGPU's gebruiken zal Rare er mee bezig gaan.

Nu kunnen mensen juist beter multiGPU's gebruiken, want voor DX12 kan je AMD en Nvidia kaarten door elkaar gebruiken (Net als ten tijde van Vista, jeuj vooruitgang, bedankt hè Nvidia! !). Als je dus een nieuwe kaart gaat kopen, kan je je oude erin laten zitten DX12 kan als de developer het juist implementeerd, heel variable meerdere GPU's gebruiken.

[marking]

Multi GPU is nog steeds geen peanuts en vereist echt wel flink wat meer kennis en werk om goed te werken. DX12 maakt het makkelijker voor devs om dit te gebruiken. Maar fundamentele problemen zijn er nog steeds (eg, meest gebruikte methode, AFR: frame 1 door GPU1, Frame 2 door GPU2, etc.. heeft nog steeds het probleem dat als je post processing effecten gebruikt die een "geschiedenis" vereisen (velocity buffers voor Motion blur, previous frame voor reflecties,...) deze data moet synchroniseren). Dit is niet gewoon even een checkbox voor DX12. Probleem is ook dat data kopiëren van GPU 1 naar GPU 2 enorm langzaam is (relatief dan, voor low latency dingen).

DX12 heeft wel wat toffe features die het in theorie mogelijk (een FLINK stuk makkelijker) maken om specifieke taken op andere GPU te draaien, eg GPU 1 doet normale rendering, maar GPU 2 doet simulations (Water sim, hair sim, physics, video decoding, procedural generation). DX12 helpt met syncronisatie, en regelt zelf alles voor cross device (Nvidia+AMD+Intel) support (geen specifieke SLI/CF code meer nodig). Maar zolang de markt hiervoor super klein is (< 0.1% van PC gamers?), is het nog niet echt interessant om hierin te investeren.

Verder het punt met DWM. Ik ben niet 100% zeker, maar voor zover ik me kan herinneren heeft windowed mode het nadeel dat DWM beslist wat je GPU opties zijn zoals bij Vsync, double/triple buffering, num render-ahead frames, .... ). DWM beslist altijd wat deze instellingen zijn, en in windowed mode zal deze dan ook veel waarschijnlijker een gebalanceerde keuze voor alle programmas maken. Als je fullscreen doet kan een game deze settings redelijk "gegarandeerd" sturen (DWM / Driver zal altijd laatste keuze hebben). Maar hier kan ik ook naast zitten, al even niet meer mee gewerkt.

Edit: Ook het scherm in delen en elk deel door een andere GPU laten doen is niet zo simpel (Scissor mode). Post effects die informatie van hun omgeving verzamelen werken dan niet goed bij de split (bloom, reflections, Ambient occlusion,...). Ook simulatie jobs zijn dan tricky, welke GPU doet dit, en is er tijd voor transfer van de data? Hier zijn ook weer workarounds voor, maar kost weer werk, en zal in de meeste gevallen voor een performance tick zorgen (dubbel GPU != dubbel performance).

Het kan uiteindelijk allemaal wel, en DX12 is makkelijker, maar complexe games vereisen meer werk dan simpelere. Zonder post effects (en dus ook geen deferred rendering), en complexe GPU simulations kun je echter wel relatief makkelijk een hele dikke boost krijgen (Dit kan echt een groot verschil voor VR maken!).

[Reactie gewijzigd door marking op 1 augustus 2024 14:53]

[arbraxas]

Leg dan maar uit waarom de keuze is gemaakt door MS om dat in spellen uit de Store niet toe te staan terwijl dat technisch prima mogelijk is? Uitgave van hetzelfde spel op steam laten dat zien.
De reden weet ik niet, maar 1 ding is duidelijk het is een keuze van MS. Mijn vermoeden is om het verschil met de Xbox niet te groot laten worden.
(Xbox one X was toen nog niet uit)

Dat is dus de reden dat ik de MS versies links laat liggen, ik zit niet te wachten op bewust gekortwiekte spellen.
En gezien de verkopen ben ik niet de enigste.
MS mikt op een volledig gesloten systeem als bij de consoles, gelukkig heeft de pc gamer daar de neus voor op gehaald.

[HooksForFeet]

Waaruit blijkt dat dat niet is toegestaan? Staat dat ergens in de documentatie?

[batjes]

Exclusive fullscreen is niet mogelijk in DX12, het ontbreekt in de documentatie juist.

https://blogs.msdn.micros...more-now-enabled-for-uwp/

Does DirectX 12 and UWP support full screen exclusive mode?

Full screen exclusive mode was created back in the original release of DirectDraw to provide games with enhanced performance when using the entire screen. The downside of full screen exclusive mode is that it makes the experience for gamers who wish to do other things on their system, such as alt-tab to another application or run the Windows GameDVR, more clunky with excessive flicker and transition time.

We thought it would be cool if gamers could have the versatility of gaming in a window with the performance of full screen exclusive.

So, with Windows 10, DirectX 12 games which take up the entire screen perform just as well as the old full screen exclusive mode without any of the full screen exclusive mode disadvantages. This is true for both Win32 and UWP games which use DirectX 12. All of these games can seamlessly alt-tab, run GameDVR, and exhibit normal functionality of a window without any perf degradation vs full screen exclusive.

[TWyk]

Een outdated methode is vervangen door een nieuwere betere methode met DX12 borderless Windows en MultiGPU.

[batjes]

Omdat het niet nodig is? Wat is het verschil tussen fullscreen en borderless windowed? Al je pixels worden in beide gevallen gebruikt.

Ik merk het echt niet bij Forza en Sea of Thieves dat het borderless is (nu heeft borderless altijd al de voorkeur gehad bij mij, ivm alt tabben wat smoother is en multimonitor).

Spellen worden niet gekortwiekt, er is geen performance reden voor exclusive fullscreen in DX12.

De PC gamer zit inderdaad al op het gesloten Steam systeem, of Origin...uPlay... De Apple en Play stores zijn ook geen bal anders. MS doet met de store eigenlijk weinig anders dan de concurentie volgen. Ze moeten wel. Ze hebben een OS net als Apple en Google, ze hebben game studios net als EA en Ubisoft.

Leuke is dat van al die betaalde stores, eigenlijk alleen die van MS (en Google /edit) gratis is voor betaalde producten. Je kunt zonder al te veel moeite om al die fee's heenkomen, zolang je de store enkel als repos gebruikt. (En dus zelf je betalingen e.d. regelt)

Uiteindelijk is het allemaal weinig anders dan een versie van repositories, het kwaad wat Linux geintroduceerd heeft! /s

[Reactie gewijzigd door batjes op 1 augustus 2024 14:53]

[arbraxas]

Simpel met exclusive fullscreen kunnen Nvidia en Amd zelf voor sli/cf zorgen. En om 1 andere reden wil ms dat niet.

En inderdaad android, apple of ms store het is allemaal hetzelfde

[batjes]

DX12 support geen SLI/CF. Niet nodig, want het heeft native multiGPU support.

Wat beter werkt, want het geheugen hoeft niet gedeelt te worden. Geen gehouwehoer met om en om frames naar buiten gooien. Geen gedoe met syncen van al die data en threads of de pixels en physics in sync te houden.

DX12 kan variabel GPU's gebruiken, bepaalde taken offloaden naar de zwakkere of 2de kaart, het display opdelen in meerdere delen (als je 4 dezelfde GPU's hebt a la SLI/CF, kan elke GPU een kwart van het scherm renderen) en nog wat andere leuke trucjes die SLI/CF never nooit hebben gekunt, en dit alles zonder dat developers extreem veel moeite erin hoeven te stoppen. SLI/CF is een hork om te supporten, het is niet voor niets al jaren stervende. Nu kost MultiGPU in DX12 alsnog wel wat moeite, maar lang niet zo veel. De meeste developers vinden het niet waard voor de 0,001% van de playerbase.

DX12 kan er nu juist voor gaan zorgen dat desktops straks vaker meerdere GPU's hebben, en dat in de toekomst de support een stuk beter wordt.

[Reactie gewijzigd door batjes op 1 augustus 2024 14:53]

[Wvdlinden1]

Android stelt je ook gewoon in staat om van elke willekeurige plaats apk bestanden te downloaden en dus om de play store heen te werken.

[arbraxas]

Probeer eens iets als adaway te installeren op een niet geroote telefoon. En even verder lezen als de 1e regel, het gaat niet alleen om de store zelf.

[walteij]

AFAIK is een 950(XL) Rooten inderdaad niet mogelijk, maar je kunt wel de developer mode aanzetten, waarmee je applicaties kunt sideloaden.
Dan heb je al wat meer flexibiliteit.

[Chinco]

https://www.wpinternals.net/

Deze gast heeft het een en ander uitgevogeld en beschikbaar gesteld. Je kunt zelfs de volledige versie op de 950 (xl) zetten.

[Miglow]

Mensen waren ook niet klaar om naar Windows 10 te gaan, maar dat hebben ze ook gewoon geforceerd. Of dat terecht is of niet maakt in dit geval niet uit. Microsoft heeft de macht om dat af te dwingen en als het commercieel interessant is, zullen ze dat vast wel doen.

[Rataplan_]

De markt heeft toch nog wel íets te zeggen. Zie het Windows Mobile debakel. Veel geld ingepompt, MS verwachtte er ongetwijfeld veel van maar heeft er enorm mee gefaald. Maw het is tekort door de bocht om te stellen dat MS de markt iets kan dwingen. Als het té slecht is weigert de markt. Windows RT is ook zo'n voorbeeld.

[CivLord]

De teloorgang van Windows mobile lag niet aan de markt, maar meer aan het zwalkende beleid van Microsoft rond hun telefonie OS. Daardoor werd de markt steeds huiveriger om er in te stappen.
Wanneer Microsoft volledige ondersteuning had blijven geven en niet een paar keer vreemde sprongen had gemaakt die een volledige breuk maakten met de vorige versie, dan had een versie van Windows voor de smartphone nu nog steeds één van de grote drie telefoon OS-en geweest.
En wanneer iemand bij Microsoft de koppen tegen elkaar slaat, een eenduidig en helder beleid maakt en volledige ondersteuning daarvoor krijgt, dan is dat nog steeds een mogelijkheid.

[Verwijderd]

Geweest? WM is nooit een groot mobiel OS geweest. Hooguit in de tijd van windows mobile 5 en 6. Ook in de hoogtij dagen van WM was Symbian nog steeds groter.

[Miglow]

Maar als diverse sites al kunnen detecteren dat je een X86 of X86_64, Windows, Linux of MacOs systeem hebt en daarna een passend installatie aan kunnen bieden, moet daar toch een ARM/ARM64-pakket bij kunnen?

[bbob]

Idd geen budget iets, maar voor een hele dikke prijs krijg je wel budget prestaties.
Maar goed het is een verbetering ten opzicht van de 835, dus het gaat de goede kant op. Denk dat het echter nog wel een paar jaar zal duren voordat een arm cpu met x86 emulatie een echt lekkere snelheid tegen een leuke prijs kan aanbieden.

Natuurlijk kan men software ook voor arm compileren maar dan krijgen we windows Rt 2 weer en windows RT was niet echt een succes.

[lighting_]

waarom tweakers continue op RT terug komen is mij een raadsel.
Hudige windows op arm is gewoon volwaardig windows. RT was een volledig ander product. Look and feel van windows maar dan alleen arm programma's

[bbob]

Klopt huidige windows op arm is volwaardige windows in de zin dat het via x86 emulatie draait.
Die emulatie neemt echter heel veel van de snelheid weg.

Waar een snapdragon 845 normaal heel snel taken kan uitvoeren zonder simulatie is deze met x86 simulatie eerder vergelijkbaar met de budget intel cpu's qua snelheid.

Je betaald dus premium prijzen maar krijgt budget x86 snelheid.

[CivLord]

Maar die snelheidsbeperking kom je alleen tegen wanneer je games of beeldbewerking wilt gaan emuleren.
Voor de meeste huis-tuin-en-keuken gebruik, kantoor gebruik of gebruik van voor ARM gecompileerde software zal je geen verschil met een 'normale' laptop merken. Helemaal niet in het prijssegment rond de € 700.

[laue]

Toch een interessante uitspraak van jou die je vaker op het net hoort. Maar de duurste HP W10 ARM model zit op 1000,- (tablet, tobo, pen ) niet veel duurder dan een IphoneX, S9+, Note, etc. etc.

Is dat dan zo duur? Ik vind dat je toch veel waarde voor je geld krijgt.

[lighting_]

Omdat ik het vergelijk met huidige laptops. Voor hetzelfde geld heb meer snelheid.
Ja ok je hebt beter batterij en bent altijd online. maar ARM processoren zijn goedkoper.
Afgezien daarvan zijn de high end smartphones gewoon veel te duur. maar consumenten hebben het ervoor over. Daarmee ga ik de prijzen ook niet vergelijken.

[laue]

vergelijk je het met een telefoon of laptop? Interessante kwestie, Google is moment hard de chrome books aan het pluggen met als slogan "werk met je laptop zoals je telefoon" (https://www.youtube.com/watch?v=ojOBx5tc9Jw) En dat is weer een bruggetje naar de volgende vergelijking:

Persoonlijk denk ik dat je W10 ARM moet vergelijken met chromebooks, lichte, snelle en zuinige productieve apparaten. Voordeel van W10 ARM is dat je als fallback Win32 apps kan draaien en 4G Internet hebt.

[lighting_]

Zijn andere devices maar omdat er eenmaal meer smartphones gekocht worden drijft dat de prijs op en worden hogere marges gehaald. Logische vraag vanuit de markt. De chromebook zijn juist toch goedkoper dan laptops en dan geef je zelf al aan wat ik zei. Zou goedkoper moeten zijn dan laptops.

[Dreamvoid]

maar ARM processoren zijn goedkoper

Dat hangt van de prestaties af - als er ARM chips komen met Intel/AMD-prestaties, dan gaan de fabrikanten ook Intel/AMD prijzen vragen, ze zijn daar bij Qualcomm niet helemaal op hun achterhoofd gevallen. De huidige goedkope ARM chips in Chromebooks etc concurreren nu met de ook zeer goedkope Celeron chips van Intel. Het idee dat je binnenkort een Core i5-achtige chip krijgt voor de prijs van een Mediatek chipje uit een willekeurige Chinaphone, reken er maar niet op.

Je koopt een Snapdragon 845 ook niet even voor twee tientjes om 'm in een netbookje te duwen, die HP laptop met Snapdragon is niet voor niets 1000 euro. Apple heeft ook snelle ARM chips, maar goedkoop zijn ze zeker niet.

Het grootste voordeel dat Qualcomm heeft met deze Windows devices is niet de ARM instructieset, maar hun 4G modemtechnologie: elke concurrent die een always-online tablet wil maken betaalt de hoofdprijs voor die dingen (een basisbedrag plus percentage van de totale device prijs) omdat Qualcomm de essentiele patenten heeft.

[Reactie gewijzigd door Dreamvoid op 1 augustus 2024 14:53]

[Sandor_Clegane]

"Invalid" zal denk ik een invoer foutje zijn.

[Blokker_1999]

Nee, gewoon onbekend model en daarom ongeldig in de modelnaam.

[C.Hariri]

Inderdaad, waarschijnlijk is de hardware nog een prototype en hebben ze de moederbord id's e.d. nog niet goed ingevuld.

[Verwijderd]

"Lenovo Invalid" ... zou dat "Invalid" niet de output zijn een niet-ingevulde parameter in de benchmark?
Het lijkt me namelijk niet dat je je computermodel "Invalid" noemt.

[Proxx]

of het apparaat/serienummer word niet herkent en is dit gewoon een generiek kenmerk

[Tijs Beek]

ik zie bij telefoon heel vaak veel cores,
Wil iemand me precies uitleggen waarom?
Is het vanwege dat heel veel apps op de achter grond werken?

[Quacko]

In het heel heel kort en dus kort door de bocht maar genoeg om het idee over te brengen:
Niet enkel bij telefoons maar ook andere toestellen is het zo dat 1 app al gebruik kan maken van verschillende cores als deze app 'threaded' is geprogrammeerd. Dus probeer cores niet be bekijken als 1 core per app, maar 1 core per thread (en ook dat is nog niet 100% correct gezien HT en dergelijke).

[CivLord]

Je ziet vaak dat die cores op verschillende snelheden draaien, waardoor de SoC efficiënt met stroom om kan gaan.
Maar voor een groot deel is het ook omdat het heel kek in de specificaties staat. Een octa-core die een paar procent efficiënter is, maar wel een stuk duurder dan een quad-core , zal in de meeste gevallen niet vanwege die paar procent extra efficiëntie worden gekozen.

[Gamebuster]

Vaak zijn het 4 high-performance cores en 4 energie-zuinige cores.

Waarom heb uberhaupt veel cores zijn: Stel je hebt een single-core CPU die lekker vlot is. Deze verbruikt veel stroom. Vervolgens maak je een CPU met 4 cores, waarbij iedere core net iets meer dan een kwart van de rekenkracht heeft: Deze quad-core is dan ongeveer even snel (bij het verwerken van multi-threaded taken), maar verbruikt veel minder stroom.

Qua energie-verbruik schaalt het veel beter om meerdere cores toe te voegen dan enkele cores sneller te maken. In de toekomst zullen het aantal cores dan ook op alle platformen alleen maar toenemen, terwijl de performance-per-core veel langzamer zal stijgen (of zelfs zal dalen)

[Reactie gewijzigd door Gamebuster op 1 augustus 2024 14:53]

[Verwijderd]

Gevolg: problemen die niet of slecht te paralleliseren zijn zullen nauwelijks sneller of zelfs trager draaien op nieuwe hardware.

[Gamebuster]

Welke problemen zijn daadwerkelijk 100% niet te paralleliseren? Er is altijd wel een oplossing, zelfs als deze oplossing minder efficient is.

[Reactie gewijzigd door Gamebuster op 1 augustus 2024 14:53]

[Verwijderd]

Als je voor een vervolgstap invoer uit een vorige stap nodig hebt en het berekenen van alle mogelijkheden nog meer werk is.

[gabba25]

Hopelijk houden ze vol en zetten ze door met Qualcomm. Als ik mijn laptop in standby laat een weekend, is hij maandag gewoon leeg. Dat ben je toch ook echt niet gewend meer met iPads e.d.