Wetenschappers laten applicaties sneller draaien met die-stacked dram-cache

Onderzoekers van de North Carolina State University en Samsung hebben met simulaties aangetoond dat Dense Footprint Cache efficiënt ingezet kan worden: met de cachetechnologie kunnen applicaties meer dan 9 procent sneller starten.

Bij die-stacked dram wordt het geheugen op de die van de processor gestapeld. Dat maakt lagere latencies en vooral hogere bandbreedte mogelijk. Als het dram als last level cache voor de processor ingezet wordt, is het wel een probleem dat het aanspreken van het geheugen door de omvangrijke tag-array veel eist van het sram-budget.

Om de overhead bij het sram terug te brengen, kan voor grotere geheugenblokken, of Mblocks, gekozen worden. Bij een blokgrootte van 2kiB in plaats van 64B snoept 256MB llc bijvoorbeeld nog maar 1MB sram op. Onder andere Intel gebruikt Mblocks vanaf de Haswell-generatie. Nadeel is dat grote delen van de blokken helemaal niet nodig zijn voor de processor, maar wel in de cache geladen worden. Daarvoor is dan weer de Footprint-techniek ontwikkeld: die zorgt voor een onderverdeling van de Mblocks in kleinere blokken. Die worden alleen aan de cache toegevoegd als er indicaties zijn dat ze nodig kunnen zijn.

De onderzoekers van North Carolina State University en Samsung beschrijven het nieuwe probleem dat dit oplevert: delen van de Mblocks blijven ongebruikt achter en deze leemtes zouden opgevuld kunnen worden met bruikbare data. Ze stellen daarom voor bij het fetchen van delen van Mblocks, de blokken aaneengesloten in de cache te plaatsen. Ze noemen deze techniek Dense Footprint Cache. De Mblocks hebben daarbij variabele groottes, wat uitdagingen op gebied van het plaatsen, herplaatsen en updaten van geheugendelen met zich meebrengt. De eerste testresultaten laten volgens de onderzoekers echter efficiëntieverbeteringen zien.

Bij simulaties van bigdata-applicaties zou Dense Footprint Cache deze 9,5 procent sneller laten draaien dan zonder gebruik van deze techniek, met een energieverbruik dat gemiddeld 4,3 procent lager ligt. Bovendien zou de miss ratio met 43 procent afnemen: lastlevel cache-misses vinden plaats als de processor data uit de cache probeert te halen die er niet is, waarna deze uit het langzamere werkgeheugen gehaald moet worden. De prestaties zijn gemeten met de Cloudsuite-benchmark.

De paper van de onderzoekers is getiteld Dense Footprint Cache: Capacity-Efficient Die-Stacked DRAM Last Level Cache en deze zal tijdens de International Symposium on Memory Systems begin oktober gepresenteerd worden.

Reacties (53)

[MSalters]

Uit het artikel wordt het niet helemaal duidelijk, maar het probleem hier is dus het tag geheugen van de cache. De cache zelf bevat data die ook in main memory staat, en de tag bevat de originele locaties in geheugen. Als je dus adres 0x1234 wil ophelen, dan vraagt de CPU aan de cache of adres 0x1234 bekend is. Om daar snel antwoord op te geven moet de tag *alle* bekende adressen met 0x1234 vergelijken. En de CPU staat te wachten, dus dat moet snel gebeuren. Die vergelijking is daarom volledig in hardware uitgewerkt; de tag SRAM is geen gewoon geheugen maar een mix van geheugen en adres-vergelijkers.

Het probleem met grote caches is dus ook dat elke vermelding in cache een bijbehorende adres-vergelijker nodig heeft. Met 256 MB aan cache in 64 byte blokken heb je dus 4 miljoen adressen en 4 miljoen adres-vergelijkers nodig, en bij *elke* geheugenaccess moeten die dus instantaan 4 miljoen vergelijkingen doen. Dat is wel snel, maar niet zuinig.

Je kunt wel grotere blokken gebruiken, maar dan heb je vaker nutteloze data in cache die er alleen maar staat omdat die nutteloze data toevallig in de buurt van nuttige data stond.

Het idee hier is maakt de adres-vergelijkers nog complexer - ze moeten eerst kijken of het grote 2KB blok uberhaupt voorkomt, en vervolgens of de precieze 64 bytes binnen die 2KB daarin voorkomt. Maar het grote voordeel is dus dat je maar 128K adresvergelijkers in de eerste ronde nodig hebt (256MB/2kB), en dat je in de tweede ronde je maar 64 checks hoeft te doen.

[millman]

Zeer, maar dan ook zeer duidelijk verwoord. Erg fijn om op deze manier mn eigen kennis bij te spijkeren thnx 4 that!

[Squee]

Het probleem met grote caches is dus ook dat elke vermelding in cache een bijbehorende adres-vergelijker nodig heeft. Met 256 MB aan cache in 64 byte blokken heb je dus 4 miljoen adressen en 4 miljoen adres-vergelijkers nodig, en bij *elke* geheugenaccess moeten die dus instantaan 4 miljoen vergelijkingen doen. Dat is wel snel, maar niet zuinig.

In grote lijnen heb je gelijk, maar er zitten een aantal aannames in je verhaal die volgens mij niet realistisch zijn, dus ik wilde je daar graag nog even op aanvullen. Je zou een dergelijke cache nooit fully associative maken, wat je hier wel suggereerd; dus je zou nooit voor elke access alle 4 miljoen tags gaan vergelijken. Voor de L2 en L3 caches doe je dat eigenlijk al niet eens; alleen de L1 cache is soms fully associative, maar vaak is deze al 8-way set associative. L2 en L3 zijn in de praktijk altijd set associative. Een CAM (adres vergelijker) ontwerpen die een 256MB fully associative cache zou kunnen ondersteunen zal hoogst waarschijnlijk niet eens mogelijk zijn binnen de grenzen van redelijke timing, area en power.

Wat je bij dergelijk grote caches eerder zal doen is ze direct mapped maken waarbij elke cacheline een afbeelding is van zijn eigen offset in het geheugen modulo de cache grootte. Je hebt daarvoor nog steeds een tag nodig voor elke line, maar je hoeft voor een gegeven geheugen adres maar een enkele tag te bekijken om te zien of dat adres in de cache zit of niet. Als je kijkt naar het stacked memory op de Knights Landing Xeon Phi bijvoorbeeld, dat kan ook als een speciale last-level cache ingezet worden, maar dat is dan wel een 'simpele' direct-mapped cache.

Deze paper gaat dan verder op de Mblocks techniek; een manier om eigenlijk grotere cachelines te hebben (dus minder tag ruimte nodig), maar dan met een techniek om subdelen hiervan wel of niet in de cache geladen te hebben.

[Reactie gewijzigd door Squee op 24 juli 2024 18:55]

[Mic2000]

Ik vind 9 procent nou niet echt enorm veel. Zou het 20 procent zijn of 40 procent. Ik denk niet dat ik 9 procent ga merken als ik FB opstart.

[RedPixel]

Het gaat hier niet om apps op je telefoon, maar bijvoorbeeld om cloud-applicaties. Waarom Olaf dat ook apps noemt is mij een raadsel. Grote cloudaanbieders kunnen dus 4,5% energie besparen en bovendien 9% minder processoren aanschaffen. Ka-ching!

[o_f_course]

Mobiel en niet mobiel schuiven steeds meer naar elkaar toe, dus ik gebruik m'n Word app op m'n pc net zo hard als op m'n Lumia.

Ik heb me altijd verbaasd waarom ze op de mobiel juist apps genoemd worden, terwijl het om applications gaan.

Alsof het maken van een app wat anders is dan programmeren...

[RedPixel]

Maar er zit een groot verschil tussen programmeren voor smartphones en desktop-computers! Daarom is het wel handig daar een aparte naam voor te hebben. Het verschil zit vooral in de hoeveelheid resources die je voorhanden hebt, maar ook de manier waarop programma's gedraaid kunnen worden en de manier waarop zeverspreid worden. Ook heb je een compleet andere porgrammeeromgeving, beperking van programmeertalen en bijbehorende sandboxing. Die Word-app van jou is heel wat anders dan de desktopversie van Word hoor, zowel in features en prestaties als programmeerwerk.

In dit wetenschappelijke artikel gaat het over geheugen-snelheidsverbeteringen, over L2 en L3-cacheverbeteringen. De meeste (alle?) mobiele processoren hebben niet eens L3, en vrij weinig L2 cache, dus is het weinig interessant daar verbeteringen in aan te brengen, zonder er eerst überhaupt gebruik van te maken.

[Reactie gewijzigd door RedPixel op 24 juli 2024 18:55]

[Minc]

Er zit helemaal niet zo veel verschil in programmeren voor smartphones en desktop-computers. Het enige grote verschil zijn het scherm en invoer mogelijkheden.

[RedPixel]

Uhh, nee hoor. Zoals ik al zei: de hoeveelheid resources, andere porgrammeeromgeving, beperking van programmeertalen (binnen IOS, Windows Phone en Android iig) en bijbehorende sandboxing. Daarnaast kan ik nog wel wat andere dingen bedenken: andere instructieset, meestal veel minder opslagruimte, ander OS, maar ook meer connectiviteit en sensors. Ook kun je de tests vaak niet op dezelfde machine doen (hoewel emulatie het een en ander toelaat, maar das niet hetzelfde).

Ook zorgen die verschillen die jij noemt dat je moet nadenken over een andere GUI voor een veel kleiner scherm en touch; het gebrek aan toetsenbord en muis etc.

Kortom, er zit wél veel verschil in programmeren voor smartphones en desktop-computers.

[batjes]

Ondersteuning voor meerdere OSen is maar een erg klein stukje code in vergelijking tot de volledige code. Zo heb je genoeg multiplatform games en apps die op consoles, pc's, smartphones en meer beschikbaar zijn. Als je vanaf het begin van het project rekening houd met multiplatform en alle platform specifieke meuk apart weet te houden, is later meerdere platformen supporten -verhoudingsgewijs- appeltje-eitje.

Niet dat het amper werk is oid, maar in verhouding tot het totale programeren van het project wel.

En het grootste gedeelte van het werk bij de platform specifieke code is voor de GUI en inputs. Voor de platforms zelf heb je dev tools, engines, frameworks e.d. die het gross van het werk doen.

[latka]

Valt reuze mee in de praktijk: apps zijn soms meer dan 100Mb groot en er zit 1G of meer geheugen in je telefoon met een dualcore van 1Ghz+. Enige verschil is het OS, verder is het exact precies meer van hetzelfde. Oh nee, het testen is vervelend op een emulator of een los device. Maar afgezien daarvan merk ik niet zo heel veel verschil meer. Embedded systemen (<50Mhz kloksnelheid en 256 bytes ram), dat is pas anders: dan moet je echt nadenken over wat je hoe opslaat. Op een mobile device knal je SQLite aan om data op te slaan en een webview voor HTML forms met JS en CSS voor de opmaak. Weinig constraints.

[Interlace84]

Bekijk het eens zo: Als er een nieuwe CPU vandaag uit zou komen die op dezelfde clocksnelheid 10% sneller is dan de rest met 4,5% minder energieverbruik zouden mensen daar blij van worden, toch?

[koelpasta]

Nou, niet als die mensen zien heveel ze bij moeten betalen om dit onderzoek te sponsoren.
Die processor zal heus niet slechts met 10% in prijs zijn gestegen.

[Iblies]

Budget en research-kosten maken deel uit van een normale bedrijfsvoering.

Dat kost dus niets meer.

[robvanwijk]

Nou, niet als die mensen zien heveel ze bij moeten betalen om dit onderzoek te sponsoren.
Die processor zal heus niet slechts met 10% in prijs zijn gestegen.

Hoeveel zou dit onderzoek gekost hebben, ergens tussen de 1 miljoen en de 10 miljoen waarschijnlijk? Hoeveel processoren gaan deze techniek gebruiken (vanaf de eerste, totdat we ergens anders op overstappen en dit mechanisme vervangen wordt), talloze miljarden waarschijnlijk? Zelfs als we alleen naar het eerste jaar na introductie kijken komen we al snel boven de 100 miljoen uit. Dus die kosten zijn hooguit een paar cent, vermoedelijk nog veel minder. Dus dat blijft gewoon € 99,99 omdat €100,01 (twee cent meer, want inclusief allerlei marge-percentages, en om het punt duidelijk te maken) er suf uitziet.

Daarnaast is het per definitie minder dan 10% (voor 10% betere prestaties), want anders kopen mensen gewoon vrolijk de vorige versie.

[84hannes]

Een eenmalige verbetering van 9% is ook niet zoveel. Maar als je naar computerarchitecturen gaat kijken dan is deze vol met optimalisaties. Als je bits 1 voor 1 bij elkaar op zou tellen zou een 64-bit optelling twee keer zo lang duren als een 32-bit optelling. Dankzij optimalisaties die bijvoorbeeld eerst 32 optellingen parallel doen, en daarna de uitkomsten in 16 parallelle bewerkingen verwerken, is dat veel minder. Als je alle data rechtstreeks uit het RAM moet halen zou dat iedere keer milliseconden vertraging opleveren, dus is de cache uitgevonden. Als iedere instructie volledig uitgevoerd moet worden voordat de volgende instructie kan worden gestart dan zou de koksnelheid veel lager liggen, dus is pipelining geintroduceerd. Ik weet wel dat sommige van deze optimalisaties niet 9% maar eerder 900% versnelling opleverden, maar als je 100 optimalisaties met maar 9% snelheidswinst weet te stapelen dan heb je een snelheidswinst van 5529%. En reken er maar op dat moderne hardware een opeenstapeling van optimalisaties is.

[SilentLucidity]

Ik denk dat je 9% juist alleen bij Facebook gaat merken.

[Neko Koneko]

Klopt, scheelt toch al snel weer een minuut

[Rudie_V]

In het artikel wordt genoemd dat ze de simulaties op bigdata-applicaties hebben getest. Bij dit soort bigdata-applicaties is de cpu wel ietjes langer bezig met rekenen dan bij het opstarten van je fb app.

[Weapon S]

Begrijp ik het nou verkeerd, of is dit alles nog maar simulatie? Dan vind ik de titel afschuwelijk misleidend.

[Verwijderd]

Bij bigdata applicatie is dit zeer gebruikelijk. Afschuwelijk gebruikelijk zou ik bijna zeggen.

[Squee]

Onderzoek op computer architectuur gebied vindt bijna uitsluitend plaats in simulaties, en dat is ook zo bij de R&D afdelingen van alle chip ontwikkelaars. Het is veels te duur om een experimenteel algoritme in een chip te gaan ontwerpen en dan die chip te produceren om er achter te komen dat het wel/niet werkt. Er zijn wel onderzoeksgroepen (de RISC-V jongens van Berkeley bijvoorbeeld) die na uitgebreide simulaties en ontwikkelingen uiteindelijk een chip hebben laten bakken, maar dat is in dit onderzoeksgebied zeker niet gebruikelijk.

[RedPixel]

Waarom worden programma's hier apps genoemd? Ik lees apps als mobiele applicaties. Het gaat hier over SRAM, dus L2 en L3-cache-geheugen, er wordt ook niet voor niks Cloudsuite gebruikt om te benchmarken. Dit gaat over verbeteringen voor geheugenprestaties van vooral server-processoren.

[.oisyn]

Waarom worden programma's hier apps genoemd? Ik lees apps als mobiele applicaties

Je kunt je beter afvragen waarom jij "app" beperkt tot mobiele applicatie . Ik weet niet beter of app is gewoon een afkorting voor applicatie, dat gebruikte ik al ver voor de eerste iPhone.

[Shark.Bait]

Apps is een afkorting die apple voor haarzelf wilde hebben en die gekaapt is door de rest van de mobiele wereld. Mijn Amerikaanse collega's noemen alle applicaties "apps", ongeacht op welk OS het draait, en ik ben dit ondertussen ook gaan doen. Taal verandert constant, dus wen er maar aan

[RedPixel]

Prima, maar bedenk dan alsjeblieft even aparte naam voor apps op telefoons, en apps op desktop-computers; dat zijn namelijk twee verschillende dingen. Helemaal op een technische site als Tweakers, wil je duidelijk zijn over welke van die twee je hier bedoelt. In (voor mij althans) normaal taalgebruik worden vooralsnog met apps voornamelijk mobiele applicaties bedoeld.

[stefanhendriks]

Zijn beiden zo verschillend dan? Software "applicaties" blijven "applicaties". Ongeacht platform. Wat shark.bait al zei: taal veranderd. :-)

Maar dat neemt niet weg dan in het artikel ea wellicht duidelijker verwoord had kunnen worden.

[majetta]

mobile apps, desktop apps, cloud apps, software apps.

[MonkeyJohn]

Ik ben het met je eens wwwhizz.

Ik denk dat we een beetje een vergelijking kunnen maken met het Amerikaanse 'drugs', wat zowel medicatie als de illegale meuk omvat, terwijl wij in Nederland duidelijk daar verschillende benamingen voor gebruiken.

[gjmi]

Welke benamingen gebruiken we in het nederlands dan?

Zoveel ik weet heet het in het nederlands "verdovende middelen". Daaronder vallen een aspirine en ook cocaine.

Dat wij het ook "drugs" noemen komt vanuit de straattaal. het is niet dat we er zelf in het nederlands een apart woord voor hebben verzonnen, we zijn gewoon het engelse woord voor de illegale meuk gaan gebruiken.

[Reactie gewijzigd door gjmi op 24 juli 2024 18:55]

[RedPixel]

Het Engelse woord drugs omvat ook alle pilletjes die je bij de Etos kunt kopen..

[gjmi]

Ja, maar dat was niet het punt.

[Blokker_1999]

En wat ga je dan doen met UWP? MS toont net aan dat er tussen de twee eigenlijk zeer weinig verschillen hoeven te zitten en het verschil tussen mobiel en desktop zal de komende jaren alleen maar meer en meer verdwijnen.

[Exitz]

UWP we hebben het hier toch over de Universal Windows Platform ?
Die meuk van vandaag bestaat toch gewoon morgen niet meer zoals de rest van ms zijn verhaaltjes.

[josipbroz]

apps = applications
Mobile apps = mobile applications.

programma vind ik juist niet zo'n logge naam.
Zeker als je veel in IT met ITIL werkt kan een programma heel wat anders betekenen.

app is een stuk makkelijker en een gemiddelde aardebewoner weet inmiddels dat et een of ander "programnma"is wat ergens op een device draait.

Waar een app op draait moet je tegenwoordig ook hoe dan ook vermelden want zelfs mijn koelkast een tegenwoordig een app, hoe gaan we die noemen?

[wica]

Er is maar 1 verschil tussen "apps" voor de telefoon en "apps" voor de desktop.

Bij de telefoon zitten de "apps" opgesloten in de appstore en moeten voldoen aan de keuren van het bedrijf.

"Apps" voor de desktop, mag je overal vandaan halen, zonder dat er een controle van een bedrijf op zit.

[loki504]

Android kan je ook gewoon een .apk bestand downloaden. En die hoeven ook niet gekeurd te worden.

[latka]

Dan wil ik een naam voor applicaties die alleen op Windows werken en een andere naam voor applicaties die cross-platform zijn (Linux, Windows, MacOSX) en een naam voor applicaties die alleen op Unix achtige systemen draaien. Moeten we ook een andere naam hebben voor applicaties die op Windows werken middels een Unix compatibility layer (Cygwin of MingW). Je snapt mijn punt hopelijk.

[Blokker_1999]

Alleen is de afkorting apps veel ouder en dateerd deze al vanuit de begin periode van de computer industrie. In een periode waarin ruimte op het scherm beperkt was en ook de geprinte pers harde dollars rekende voor elk karakter dat je wenste te laten printen was het beter om app te schrijven ipv application.

Blokker_1999: An app for that.

[johnkeates]

Of prog voor program.

[blorf]

Ze zijn ontstaan na de eerste smartphone's, tablets en soortgelijke mobiele apparaten. Ik associeer apps zelf met plugin-achtige dingen voor op een chrooted/jailed ecosysteem, die je nodig hebt bij gebrek aan functionaliteit van je systeem (dat out of the box weigert hardware-compatible executables uit te voeren), waardoor de gebruiker volledig is aangewezen op het softwareplatform waar hij zich in bevindt en niet uit kan. Een echte computer heeft daar geen last van en kan gewoon applicaties/programma's uitvoeren op de hardware. (Het OS kan dat daarna nog steeds verknallen maar das een ander verhaal)

[loki504]

Amerikanen zijn dom. Die moet je niet achterna lopen. Al decennia praten we over programma's en programmatuur. Een app is een programma op een mobiel apparaat.

De vorm van programmatuur, het uiterlijk zogezegd zoals de programma's op een Windows PC komt van mobiele apparaten. Maar het is geen app. Zoals de NOS-app op een PC geen app is maar een programma dat lijkt op een mobiele app, omdat de look blijkbaar cool is. Maar de NOS app is geen app maar een programma dat een nieuwsfeed weergeeft.

Een app is een afkorting voor applicatie, ofwel een toepassing. Als je op een PC een app start, dan zeg je eigenlijk dat je een toepassing start.

Definitievervaging is een slechte zaak.

En als ik op een snelkoppeling rechtermuis klik en dan eigenschappen en dan snelkoppeling zie ik bij "doeltype" toepassing. Wat is daar dus slecht aan?

Tevens kan je de foutmelding krijgen http://answers.microsoft....-b7b5-45d9110d4712?auth=1

Ook hier spreken ze gewoon over een toepassing.

[Reactie gewijzigd door loki504 op 24 juli 2024 18:55]

[Verwijderd]

Ik denk dat het verschil zit in wat Microsoft bedoeld. Een applicatie of toepassing is een programma met een specifiek doel. Maar binnen een applicatie kunnen verscheidende toepassingen zijn die we soms features noemen.

Als je een foutmelding krijgt als je iets kopieert en dan wilt plakken en de boel crasht, dan is het plakken een toepassing van de code die dat mogelijk maakt. Daarin zit een bug.

Een windows programma met specifiek doel in het OS is een toepassing. Het is onderdeel van een hele serie aan elkaar gekoppelde functionaliteiten, elk met hun eigen toepassing. Maar het OS zelf is in feite een enkel programma omdat tussen al die interne applicaties code zit die alles met elkaar verbind. Zo kun je ook in een tekenprogramma een stuk code starten om een tekening te animeren, wat een omkaderde functionaliteit is binnen het programma en aangeroepen kan worden vanuit een menu. Soms noemen ze uitgebreide programmatuur een suite.

En toepassing is applicatie, dat zijn synoniemen. Maar een app is een programma op een mobiel apparaat, bedacht blijkbaar door Apple die een eigen soort van visie had, dat op een GSM of smart phone je applicaties kunt draaien, kleine toepassingen met specifiek doel, binnen het OS van de phone, die vanwege die beperkte capaciteit van zo'n phone klein moesten blijven en vaak maar een ding konden doen. Daarmee gaven ze aan dat ze niet wilden spreken over programmatuur of software.

Van oudsher maakte men onderscheid tussen applicatie en programma. Een klein tooltje was meestal een tool of applicatie, bijvoorbeeld iets om een jpg om te zetten in een gifje. Simpel en direct. Software kan vele functies hebben met meerdere doelen en manieren om iets te bereiken. Dat is dus geen applicatie meer.

M$'s OS zal nooit volledig crashen, tenminste, blue screens komen zelden voor. Alleen een applicatie binnen de conglomeratie van Windows crasht, vandaar dat ze dan spreken in de foutmelding over toepassing.

[loki504]

En macapp uit 1985 was zeker ook voor je mobiel?

APP is gewoon de afkorting voor application/applicatie. Net zoals progje gebruiken voor programma's.

https://nl.wikipedia.org/wiki/Applicatie

Een applicatie (letterlijk: "toepassing"; vaak ook afgekort als app) is een computerprogramma dat bedoeld is voor eindgebruikers

Ik en de mensen om mij heen hebben nog nooit onderscheid gemaakt tussen een tooltje en een programma. Het geen wat wij wel deden was tje er achter zetten om aan te duiden dat het om een klein programma ging.

App heeft in nederland prog overgenomen omdat de mobiel het bekent heeft gemaakt. En zoals je weet verandert taal constant.

in nederland kennen we officieel alleen Goeroe. Maar over bv 5 jaar kan je ook spreken over guru omdat het is over komen waaien. en steeds meer mensen het gebruiken.

[flippy]

programma's zijn GEEN apps. je moet het artikel goed lezen om te begrijpen dat het niet gaat om meer prestaties bij de nieuwe versie van angry birds op je iphone maar dat het gaat om serieuze big data oplossingen.

mogelijk een puntje om het artikel even aan te passen. "apps" klinkt lekker in de volksmond maar het is qua journalistiek natuurlijk compleet voudt.

[84hannes]

Apps zijn toch berichtjes die je naar elkaar stuurt?
Ik ben het met Shark.Bait eens dat apps een afkorting van applicaties is. VMWare heeft vApps, volgens mij is dat zelfs een netwerk van virtuele machines voor een specifieke toepassing (applicatie). Het enige verkeerde gebruik van 'app' is wat mij betreft 'ik gooi het in de app' en 'ik stuur je een appje' en 'ik app je'.

[Verwijderd]

Dat is het gevaar van definitie verloedering. Mensen gebruiken taal erg slordig tegenwoordig. Veel barbarismen, met name Anglicismen.

We gooien te pas en te onpas Engelse termen er uit. Ik probeer doorgaans zo veel mogelijk het correcte Nederlandse equivalent te gebruiken. En zelfs ik ben soms lui en gebruik het Engelse woord.

Een app is geen berichtje. Wat men bedoelt in de gebruikelijke taal-luiheid die onze tijd kenmerkt, is dat men via een app een berichtje stuurt. En dat kost te veel moeite, te zeggen 'Ik stuur een berichtje.'. Afgekort 'Ik app je.' Ja taal verandert maar niet altijd ten goede.

[84hannes]

En een stereo met mp3 is eigenlijk een muziekspeler met mp3-compressieformaatondersteuning en stereogeluid. Helaas werkt het zo niet, en zegt met dat het internet stuk is als met in de app geen appjes naar de app kan appen.

[Verwijderd]

Briljant!

[batjes]

Je hebt app als zelfstandig naamwoord en als werkwoord. Ik zie de verwarring niet zo, als zelfstandig naamwoord is het kort voor applicaties en als werkwoord modern smsen.

[himlims_]

device=\root\android\ himem.sys /cpuclock:on /machine:7

[HKS-Skyline]

*Battery low.Please connect charger*