Hard- en software tot het uiterste benutten bij development

[botervlieg]

How did game developers pack entire games into so little memory twenty five years ago?
(bron: Quora)

Zeer interessant en leuk inzicht in de truken, hacks en algoritmes die game programmeurs moesten vinden om hun games in het beperkte geheugen (bvb 64k cartridges) te krijgen. En de vraag of, hoe en waar deze kennis, technieken en ideeën vandaag nog gebruikt worden.

http://www.quora.com/How-...ory-twenty-five-years-ago
http://www.quora.com/How-...s-ago/answer/Dave-Baggett

Ik zou wel eens willen weten welke geniale oplossingen mede Tweakers al hebben moeten bedenken, om een stuk code te optimaliseren, om het toch werkend te krijgen ondanks beperkingen zoals geheugen, cpu speed, het gebruikte platform, tijdsdruk, etc...

Niet beperkt tot game programming natuurlijk.

[HuHu]

Je titel is een beetje ongelukkig gekozen, want je vraag gaat niet over Extreme programming.

[Don Kedero]

Doet mij denken aan de demoscene waar verschillende groepen aan meedoen zoals Farbrauch.

Hier "propt" men ook zoveel mogelijk in zo weinig mogelijk kilobytes, hier zullen ook ongetwijfeld wat (modernere) technieken en truuken gebruikt worden.

Eén van de betere (naar mij mening) is fr-08 .the .product 64 Kbyte ... voor een dikke 15 min muziek en 3D animatie.

Als je de executables niet wil downloaden en uitvoeren, kan je ze bekijken op YouTube.

[Jogai]

Doet me denken aan one of hackerdom's great heroic epics aka The story of Mel.

[kippy]

Ik heb veel geprogrammeerd voor Atmel micro controllers. En zeker in het begin was je heel erg blij met je 1 of 2 KB aan Flash. En daar heb ik toch redelijke complexe code in verwerkt. Zowel in snelheid als geheugen gebruik. Maar het is maar net wat we tot onze beschikking hebben.

Ik denk dat tegenwoordig veel programmeurs een beetje lui zijn geworden en er niet echt meer gekeken wordt naar formaat.

[Caelorum]

kippy schreef op vrijdag 24 juli 2015 @ 13:08:
[...] Ik denk dat tegenwoordig veel programmeurs een beetje lui zijn geworden en er niet echt meer gekeken wordt naar formaat.

Er is weinig lui aan. Je programmeert met de beperkingen die je opgelegd krijgt door de hardware en de klant. Dat dat tegenwoordig vaak de hardware het minste van je problemen zijn maakt de ontwikkelaar niet lui IMO.

[Douweegbertje]

Caelorum schreef op vrijdag 24 juli 2015 @ 13:22:
[...]

Er is weinig lui aan. Je programmeert met de beperkingen die je opgelegd krijgt door de hardware en de klant. Dat dat tegenwoordig vaak de hardware het minste van je problemen zijn maakt de ontwikkelaar niet lui IMO.

Niet helemaal mee eens. Het feit dat we met redelijke computers zitten, goed internet en ga zo maar door betekend niet direct dat je nergens meer naar moet gaan kijken. Laatst stond er hier op Tweakers een image:


In dit geval was het een foutje, maar het komt vaak genoeg voor dat men denkt "Ja maar de hardware of w/e kan het wel aan". Ja nee, bullshit. Je dient gewoon dingen netjes te maken, ook al kost dat meer werk (bijv. resize of w/e).

Uiteraard hoef je niet te gaan mierenneuken maar ik merk ook dat tegenwoordig mensen al helemaal nergens meer over nadenken en dat is fout (IMO). Zelfs de kleine dingen kunnen veel schelen naarmate je veel users hebt. Stel je hebt 1 mil bezoekers p/m en je kunt iets kleins als 1MB data winst maken, dan is dat 976GB per maand aan data verkeer...
Idem met databases, daar zet je toch ook niet char(255) neer

[Ealanrian]

Douweegbertje schreef op vrijdag 24 juli 2015 @ 13:31:
[...]


Niet helemaal mee eens. Het feit dat we met redelijke computers zitten, goed internet en ga zo maar door betekend niet direct dat je nergens meer naar moet gaan kijken. Laatst stond er hier op Tweakers een image:
[afbeelding]

In dit geval was het een foutje, maar het komt vaak genoeg voor dat men denkt "Ja maar de hardware of w/e kan het wel aan". Ja nee, bullshit. Je dient gewoon dingen netjes te maken, ook al kost dat meer werk (bijv. resize of w/e).

Uiteraard hoef je niet te gaan mierenneuken maar ik merk ook dat tegenwoordig mensen al helemaal nergens meer over nadenken en dat is fout (IMO). Zelfs de kleine dingen kunnen veel schelen naarmate je veel users hebt. Stel je hebt 1 mil bezoekers p/m en je kunt iets kleins als 1MB data winst maken, dan is dat 976GB per maand aan data verkeer...
Idem met databases, daar zet je toch ook niet char(255) neer

Was dat mijn afbeelding?

Ik ben van mening dat je wel een afweging moet maken tussen de kosten van je optimalisatie. 1MB data winst is in mijn ogen ook geen kleine winst. Soms is de ontwikkeltijd gewoon beperkt en moet je optimalisaties laten liggen. Helaas zijn er inderdaad mensen die nergens over nadenken maar dat heb je altijd overal wel.

[Douweegbertje]

hehe nope, het plaatje van jouw was nog groter, 4.5MB dacht ik

[Jogai]

Om niet teveel offtopic te gaan: ik gebruikte een js-libary voor een tree view en nog wat andere dingetjes. Ik heb toen die paar componenten herschreven naar css-only oplossingen en was ik verlost van een paar extra request, paar honderd kb aan js+css bestanden, en de slechte performance.

Tegenwoordig pakt iedereen er maar een css + js framework erbij, maar dat is niet altijd nodig, en ook niet altijd compleet.

[Caelorum]

Douweegbertje schreef op vrijdag 24 juli 2015 @ 13:31:
[...]
Zelfs de kleine dingen kunnen veel schelen naarmate je veel users hebt. Stel je hebt 1 mil bezoekers p/m en je kunt iets kleins als 1MB data winst maken, dan is dat 976GB per maand aan data verkeer...
Idem met databases, daar zet je toch ook niet char(255) neer

Die schaar ik onder hardware beperking
Ik zeg ook niet dat je niet moet nadenken, alleen dat je niet meteen lui bent als je niet een 6000x6000px/300dpi plaatje in 56kb propt. Dat is in de meeste gevallen dikke overkill en je kan de tijd wel beter besteden. In jouw voorbeeld van 976GB besparing per maand op de bandbreedte scheelt dat al gauw ~60E/maand en dan praat je ergens over. Nog even los van als je die servers zelf host en het je misschien wel een server zou kosten. Snap je?

[.oisyn]

* .oisyn is momenteel bezig met de afronding van Rise of the Tomb Raider voor Xbox 360, waarbij een game van 5GB in 512MB gevrot moet worden

[WernerL]

xbox360 games staan om een schijfje van 512MB? Ik neem aan dat de resolutie van de textures dan flink naar beneden is gegaan, anders gaat dat nooit passen.

[Caelorum]

WernerL schreef op vrijdag 24 juli 2015 @ 16:37:
xbox360 games staan om een schijfje van 512MB? Ik neem aan dat de resolutie van de textures dan flink naar beneden is gegaan, anders gaat dat nooit passen.

Voor dat soort dingen zou je bijna de game onaf op de CD gooien en dan via een 'update' werkend maken. Zou alleen wel niet mogen van MS.

[HMS]

Ik vermoed dat die 512MB betrekking heeft op de hoeveelheid RAM

[WernerL]

Dat zou zomaar eens kunnen, want na een zoekactie most ik concluderen dat de xbox360 veel grotere schijfjes heeft.

[.oisyn]

Ja iets van 8GB geloof ik. Maar het gaat idd om RAM

[EnnaN]

Douweegbertje schreef op vrijdag 24 juli 2015 @ 13:31:
[...]
Ja nee, bullshit. Je dient gewoon dingen netjes te maken, ook al kost dat meer werk

Douweegbertje schreef op vrijdag 24 juli 2015 @ 13:43:
het plaatje van jouw

[Douweegbertje]

EnnaN schreef op vrijdag 24 juli 2015 @ 17:16:
[...]


[...]

Wat wil je nu zeggen?

[H!GHGuY]

Ik ben links en rechts wat aan het assisteren met een collega die bezig is met een encryptie algoritme te versnellen op Intel CPU's. Wat SSE/AVX magic kan wonderen doen, maar soms niet zoveel als gewild...
Diezelfde collega heeft een tijd terug ook een ander real-time algoritme multi-threaded gemaakt met serieuze winsten op vlak van CPU usage tot gevolg.

Verder wel eens een efficiente in-memory std::map compliant B+-tree gemaakt en wat C++ template magic om met een 10-tal niveaus templates en een toffe compiler later op 1 instructie uit te komen. But haven't we all?

In het gros van de gevallen komt performance al lang niet meer neer op CPU instructies tellen. Memory, memory, memory. CPU's die uit hun neus staan te vreten omdat je weer eens een list<some_pointer_type> of std::map gebruikt waar het eigenlijk beter niet zo is. In die zin zijn de tijden serieus veranderd (tenzij je op PIC's,etc. werkt), maar zelfs de mainstream embedded CPU's zijn al voldoende geavanceerd om daarop de bottleneck te krijgen.

[ Voor 28% gewijzigd door H!GHGuY op 24-07-2015 18:42 ]

[jeroen3]

Geheugen latency is cruciaal.
Zoals gezien in ARM micro's:
Iets ophalen uit registers is direct, de instructie zelf heeft een argument voor een register.
Iets ophalen uit ram is vaak +1 instructie. (naar register kopieren)
Iets ophalen uit flash ook +1+clk+x, waarin x afhangt van je prefetcher en cache-miss. En clk de hoeveel cycles is dat je flash trager is dan je cpu.
Iets ophalen uit extern parallel geheugen is nog trager.
Peripheral geheugen (GPU) is nog erger, want dat moet ook nog eens over de peripheral (PCI) bus.
En iets ophalen uit EEPROM of Serieel geheugen (zoals je bios) is gewoon iets wat je slechts incidenteel moet doen.

In je x86 pc geld hetzelfde, maar dan heb je nog wat extra niveau's aan "ram" on-chip. De zogenaamde L1,L2 of L3 cache. Extern parallel geheugen is je DDR3, en flash is je HDD of SSD.
Hier een afbeelding van de geheugentest in aida64. Veel CPU cache kan dus nuttiger zijn dan een hogere kloksnelheid of meer cores.

Daarom biedt de DMA heel veel winst, mits goed gebruikt. De DMA kan, zonder gebruik van de CPU, data kopieren tussen verschillende geheugenlocaties.

[ Voor 3% gewijzigd door jeroen3 op 24-07-2015 19:06 ]

[botervlieg]

kippy schreef op vrijdag 24 juli 2015 @ 13:08:
Ik heb veel geprogrammeerd voor Atmel micro controllers. En zeker in het begin was je heel erg blij met je 1 of 2 KB aan Flash. En daar heb ik toch redelijke complexe code in verwerkt. Zowel in snelheid als geheugen gebruik. Maar het is maar net wat we tot onze beschikking hebben.

Ja, ik moet toegeven dat sinds ik voor een hardware project een microcontroller moest programmeren, mijn manier van programmeren toch wel veranderd is. Ik heb gezwoegd om die 64k zo efficiënt mogelijk te gebruiken tot alle functionaliteit die ik wilde implementeren er ingepropt zat

Sinds dien besteed ik terug veel meer aandacht aan optimalisatie en het gebruik van resources. Wat je eigenlijk sowieso moet doen. Maar wanneer je veel toepassingssoftware schrijft tegen een deadline, op een super snel systeem, binnen frameworks waar je voor de minste functionaliteit een uitgebreide library ter beschikking hebt, verlies je dit soms nogal eens uit het oog.

Gelukkig zijn er terug meer en meer jongeren die hun eerste programmeer ervaring opdoen, juist op een ‘beperkt’ systeem zoals een microcontroller.

Jogai schreef op vrijdag 24 juli 2015 @ 10:19:
Doet me denken aan one of hackerdom's great heroic epics aka The story of Mel.

Leuk om te lezen, thanks voor de link !

[Douweegbertje]

Nja om nog even inhoudelijk te reageren. Ik werk voornamelijk met MsSQL, PHP, .NET en wat frontend talen.

In elk geval ben ik al maanden bezig met het optimaliseren van een grote procedure die in de nacht draait. O.a. hier nog wat terug te vinden (heel gering maar toch) SQL optimalisatie
Normaal duurde dit van ongeveer 3 uur tot soms wel half 10 in de ochtend. (6,5 uur dus). Vrij lastig aangezien de mensen rond half 8 beginnen te werken, en dan zit je met nog een relatief zware load.

Dit is grotendeels geoptimaliseerd door o.a. veel dingen op te splitsen. Je moet het zo zien dat MSSQL met stappen werkt en ook de data moet op een bepaalde flow door de procedure gaan. Even simpel gezegd moet je soms eerst stap 1 hebben gedaan om überhaupt geschikte data voor stap 2 te hebben. Uiteindelijk toch veel zaken gevonden die los van elkaar staan, en deze lopen nu ook naast elkaar.
IMO is SQL redelijk inefficiënt als het gaat om een constante flow van zware query's. Dit is toch sneller te maken door 2 statements soort van naast elkaar te laten lopen.
Verder parallelism getweakt. Dit is redelijk moeilijk om het goed te doen. Je wilt niet te snel parallel gaan lopen omdat het dan soms meer tijd kost om het werk te verdelen en op te vangen dan dat je het al in één keer doorliep. Je moet hier vaak een 'sweet spot' voor vinden en dat verschilt enorm qua data.
Echter goed geïmplementeerd kun je met gemak een query 2-4x zo snel maken.
Nog wat context: https://www.simple-talk.c...arallelism-in-sql-server/

Goed, al met al zit ik nu met een flow die rond 6 uur klaar is, soms eerder. Bijna 50% snelheidswinst zonder daadwerkelijk in het proces te snijden of wat dan ook. Verder weet ik ook zeker dat er nog meer winst te behalen valt mede door het verwijderen van de index, en deze later toe te voegen 'als je klaar bent'. Als je bijvoorbeeld 10mil records gaat verplaatsen, en hier staan 2-3 indexen op die relatief groot zijn.. dan ben je serieus een factor 1000 trager als je de indexen mee laat verwerken..


Verder nog een stukje javascript/jquery (geef het beestje een naam ) die als een soort multithreading functie functioneert om o.a. charts en dergelijk te maken. Elke thread doet 'iets' en dat komt dan uiteindelijk weer samen. Het aantal threads is ook weer afhankelijk van de serverload en dus dynamisch om ervoor te zorgen dat mensen niet opeens alles down halen met ophalen van giga veel informatie. En dan aan de andere kant: als het rustig mag er best wat resources tegenaan geworpen worden.
Helaas kan ik niet te veel details geven (of de source )

[Camulos]

Jogai schreef op vrijdag 24 juli 2015 @ 10:19:
Doet me denken aan one of hackerdom's great heroic epics aka The story of Mel.

nice!

Voor mij zorgen programmeer challenges ( https://www.hackerrank.com/ / https://projecteuler.net/ / Facebook hackercup en andere challenges ) er voor om het meeste uit de algoritmes te halen binnen een tijdslimiet.
De factoren die bijdragen zijn dat je je eigen programmeertaal goed kent; je de juiste complexiteit kan inschatten (Big O); en goed lezen wat er uberhaubt gevraagd wordt (geen overbodige dingen programmeren).

Hierdoor leer je al snel dat naieve implementaties niet snel genoeg werken, behalve op kleine sets. En dan natuurlijk welke structuren zeer snel werken (arrays, hashmaps) en best practices voor bepaalde oplossingsrichtingen, zoals je moet iets met priemgetal-reeksen doen? better know the Sieve Of Eratosthenes. Pathfinding? Doe dan iets met A*, DFS of BFS.

Hoe meer low-level je dit doet (hardware > assembly > bytecode / C > C++ > C#/Java/Python/php ), hoe groter de winst kan zijn.

[ Voor 5% gewijzigd door Camulos op 25-07-2015 09:24 ]

[H!GHGuY]

jeroen3 schreef op vrijdag 24 juli 2015 @ 19:05:
In je x86 pc geld hetzelfde, maar dan heb je nog wat extra niveau's aan "ram" on-chip. De zogenaamde L1,L2 of L3 cache. Extern parallel geheugen is je DDR3, en flash is je HDD of SSD.

Caches zijn nog niet eens het hele verhaal. Je data uitlijnen op DRAM pages (8KB - hoewel typisch door virtual memory beperkt op 4KB) kan ook een enorme boost geven aangezien je DRAM controller dan minder pages moet openen/sluiten.

Een goede memory allocator, afgestemd op het gebruik, kan een gigantisch verschil maken.

[farlane]

Beperkingen in CPU speed, FLASH, RAM whatever zijn wat mij betreft allemaal afleidingen van waar het eigenlijk om gaat : de functionaliteit die gebouwd moet worden. Wat heb je er aan als je met je uber skills al die functionaliteit in dat laatste beetje RAM kan drukken, maar bij de volgende uitbreiding de klant nee moet verkopen ( en die vraag komt toch wel ).
Nee, ik ben blij dat we inmiddels fatsoenlijke snelheden hebben met fatsoenlijke hoeveelheden geheugen. Alleen al het feit dat je peripheral bitjes/registers eindelijk fatsoenlijk gegroepeerd worden ipv dat het laatse configuratievlaggetje ergens anders in je map staat omdat daar toevallig nog een bitje vrij was.

Dat gezegd hebbende, de know-how die bij bv die demo scene gasten aanwezig is :

[soulrider]

Een paar tegenvoorbeelden van hierboven:
Webpagina's gemaakt met Word/... waarvan de HTML-code1.5MB groot zijn en 30sec. loadtijd nodig hebben met foto's die +5MB groot zijn. "omdat het kan, en iedereen heeft nu toch ongelimiterd breedband"
terwijl je diezelfde pagina kunt herschrijven naar nog geen 100kB, en de foto's even kunt herschalen en opslaan met een andere compressie zodat er visueel niets veranderd maar ze wel krimpen naar max 300kB/stuk. resultaat: laadtijd onder 1sec. incl. de afbeeldingen.

Een multi-user-HR-pakket dat max. 32MB geheugen per user nodig heeft en incl. dll's slechts 9MB schijfruimte inneemt. (excl. de data die soms tot +7GB groot kan zijn) maar wel alles beheert van je persoons-, loon-, prestatiegegevens. (verwerking, rapportering, import/export van/naar andere pakketten,...) geschreven in visual C++ waarbij je ettelijke duizenden gebruikers op een 20/30 tal servers kan laten werken, met per klant data van een paar duizend werknemers over een paar jaar/decennia.
(je had klanten met veel subfirma's en paar users/ firma maar <50 werknemers/firma, maar net zo goed klanten die 10 users hadden voor 8k+ werknemers),
terwijl een budgetbeheer-programma in .Net dat gebruik maakt van de loon- en prestatiegegevens komend uit dat HR-pakket om bv het budget van volgende jaar na te gaan 2+GB RAM en redelijk wat CPU verbruikt - per gebruiker - waarbij als je pech hebt dat er 2 gebruikers op dezelfde server (uit die pool van hierboven) dat opstarten de andere gebruikers het merken in de snelheid van het HR-pakket... (en een klant die 3 zulke budgetten regelmatig gelijk uitvoert op een dedicated server wordt gezet zodat ie enkel zijn eigen HR/budget-gebruikers kan kloten en de rest van de klanten er geen last van krijgen.)

Er zijn voor- en nadelen in optimalisaties en het is telkens een afweging natuurlijk of de tijd die gestoken wordt in de optimalisaties het wel waard zijn qua winst die behaald wordt, en eventueel zelfs afh. van de beoogde levensduur van je programma.
(de code van dat HR-pakket wordt al 20+jaren door dezelfde 2 programmeurs onderhouden die enkel dat doen, maar zo weten waar ze moeten zijn in die code, zelfs na de vele uitbreidingen/aanpassingen naar de wetgevingen - die bezig waren met optimalisaties zodra ze de tijd ervoor hadden - terwijl dat budget pakket onderhouden wordt door "diegene op wiens bureau de request terechtkomt" uit een groep van programmeurs)

als je app maakt waarmee je even snel wilt scoren maar waarvan je eigenlijk weet dat het maar voor een maand of max 3 maanden een hoogvlieger gaat zijn, kan je even quick en dirty coden (en enkel sommige dingen optimaliseren), en het achteraf gaan verder optimaliseren, terwijl bv embedded code die 30jaar later nog steeds moet werken op dezelfde hardware wel geoptimaliseerd kan worden tot de laatste byte.

[ Voor 12% gewijzigd door soulrider op 25-07-2015 23:33 ]

[bwerg]

kippy schreef op vrijdag 24 juli 2015 @ 13:08:
Ik heb veel geprogrammeerd voor Atmel micro controllers. En zeker in het begin was je heel erg blij met je 1 of 2 KB aan Flash.

Ja, dat is leuk. Ik had als opdracht een encryptiealgoritme zo snel mogelijk te maken op een 4K-atmel-kaart. De bottleneck in snelheid was te verbeteren met lookup tables, maar de gehele lookup table en de code samen waren nét te groot. Dus dan maar even uitgezocht of er lookups bij zaten die niet gebruikt werden. Die weggegooid, indices in de code gerefactored.

Dat zijn leuke puzzeltjes. Iets anders dan de games uit de TS (waar je gewoon wat data kan weggooien als het er ongeveer even goed uit blijft zien), maar toch.

H!GHGuY schreef op vrijdag 24 juli 2015 @ 18:38:
Verder wel eens een efficiente in-memory std::map compliant B+-tree gemaakt en wat C++ template magic om met een 10-tal niveaus templates en een toffe compiler later op 1 instructie uit te komen. But haven't we all?

In het gros van de gevallen komt performance al lang niet meer neer op CPU instructies tellen. Memory, memory, memory. CPU's die uit hun neus staan te vreten omdat je weer eens een list<some_pointer_type> of std::map gebruikt waar het eigenlijk beter niet zo is. In die zin zijn de tijden serieus veranderd (tenzij je op PIC's,etc. werkt), maar zelfs de mainstream embedded CPU's zijn al voldoende geavanceerd om daarop de bottleneck te krijgen.

Dan zijn die theoretici bezig met hun binary trees mooi perfect balanced maken, en dan blijkt dat unbalanced trees beter performen omdat de branch predictor het dan gemakkelijker heeft. Tot op bepaalde hoogte, natuurlijk. De complexiteit van een linked list is niet zo best.

[ Voor 41% gewijzigd door bwerg op 26-07-2015 15:53 ]

[H!GHGuY]

farlane schreef op zaterdag 25 juli 2015 @ 20:38:
Beperkingen in CPU speed, FLASH, RAM whatever zijn wat mij betreft allemaal afleidingen van waar het eigenlijk om gaat : de functionaliteit die gebouwd moet worden. Wat heb je er aan als je met je uber skills al die functionaliteit in dat laatste beetje RAM kan drukken, maar bij de volgende uitbreiding de klant nee moet verkopen ( en die vraag komt toch wel ).
Nee, ik ben blij dat we inmiddels fatsoenlijke snelheden hebben met fatsoenlijke hoeveelheden geheugen. Alleen al het feit dat je peripheral bitjes/registers eindelijk fatsoenlijk gegroepeerd worden ipv dat het laatse configuratievlaggetje ergens anders in je map staat omdat daar toevallig nog een bitje vrij was.

Dan moet je blijkbaar niet embedded werken . Hier moeten we code schrijven die nog op een embedded CPU van 10jr terug kan draaien, net omdat de klanten telkens op dezelfde kaarten alle nieuwe features wensen. Zo erg als die bit-pielerij zoals je het beschrijft is het ook weer niet, maar de code moet toch minstens scalable zijn en performant. En helaas, wordt daartegen al te vaak gezondigd

bwerg schreef op zondag 26 juli 2015 @ 15:45:
Dan zijn die theoretici bezig met hun binary trees mooi perfect balanced maken, en dan blijkt dat unbalanced trees beter performen omdat de branch predictor het dan gemakkelijker heeft. Tot op bepaalde hoogte, natuurlijk. De complexiteit van een linked list is niet zo best.

B+-tree is wel balanced maar niet binary De performance winst zit em vooral in de caches (het is een cache-aware B+-tree), de kleinere tree-hoogte (en dus minder pointer jumps), de array-like access binnen een node, etc. Trouwens is de B+-tree impliciet in balans en niet door de extra operaties zoals bij een red-black tree. En met uitzondering van 1 enkele operatie (erase() die een iterator returned) is ie volledig std::map compatible.
Ik had ook naar cache-oblivious (zie Harold Prokop) gekeken, maar dat is een andere grootte-orde en nog maar de vraag of ze ook in realiteit performant zijn...

Wat links naar die branch cache met unbalanced trees zou wel interessant leesvoer zijn

[bwerg]

Ik heb er zelf niks mee gedaan, maar hier staat wel precies wat ik bedoel.

[Onbekend]

Wat denk je van het compatibel houden van je software voor oudere Android-apparaten? Vooral de beperking van processorsnelheid en ramgeheugen is een ramp op goedkope en/of oude devices. (Ik gebruik bij sommige bewerkingen nu het flashgeheugen om een swapfile in op te slaan om te veel geheugengebruik te voorkomen.

Echt optimalisaties op hardwareniveau doe ik tegenwoordig niet meer, maar vroeger was dat wel nodig. (Flashgeheugen was duur, dus alle 256 bytes aan flashgeheugen in de microcontroller moest optimaal worden benut. )

[farlane]

H!GHGuY schreef op zondag 26 juli 2015 @ 16:53:
Dan moet je blijkbaar niet embedded werken . Hier moeten we code schrijven die nog op een embedded CPU van 10jr terug kan draaien, net omdat de klanten telkens op dezelfde kaarten alle nieuwe features wensen. Zo erg als die bit-pielerij zoals je het beschrijft is het ook weer niet, maar de code moet toch minstens scalable zijn en performant. En helaas, wordt daartegen al te vaak gezondigd

De embedded van nu is een whole lot different dan de embedded van een 10 jaar terug, en ik ben daar blij om. Nu vind men het bijna vanzelfsprekend dat er een USB aansluiting, netwerk, Bluetooth en WiFi op een embedded apparaat zit, en dat kan ook omdat de MCU's het inmiddels ook aankunnen. Heerlijk werken is dat. Ik haal ook geen voldoening uit het persen van een applicatie in 256 bytes RAM, terwijl er eigenlijk 2x zo veel nodig is om het fatsoenlijk te doen, verschikkelijk onzinning werk.

Ik zou met veel plezier onze legacy 8051 meuk aan jou uitbesteden en je er veel success mee wensen.

[jeroen3]

Embedded voor infotainment is niet hetzelfde als embedded voor besturingen, regelaars en meetsystemen.
Het optimaliseren van een digitaal filter, meet-algoritme of display driver is namelijk wel nuttig.
Je kunt dan namelijk terugschalen in MCU, wat weer minder energie verbruikt en weer een goedkoper product oplevert. Tenminste, als de volumes die marge ook toelaten. Je uren moeten wel opwegen tegen de besparing.

[farlane]

jeroen3 schreef op maandag 27 juli 2015 @ 10:12:
Embedded voor infotainment is niet hetzelfde als embedded voor besturingen, regelaars en meetsystemen.
Het optimaliseren van een digitaal filter, meet-algoritme of display driver is namelijk wel nuttig.

Die embedded is precies hetzelfde, en is ook hetzelfde als niet-embedded software. Waarom zou het ook anders zijn? Als je product voldoet aan de requirements ben je klaar, zo simpel is het.

Je kunt dan namelijk terugschalen in MCU, wat weer minder energie verbruikt en weer een goedkoper product oplevert. *Tenminste, als de volumes die marge ook toelaten.* Je uren moeten wel opwegen tegen de besparing.

Dat inderdaad : Als je met je optimalisatie een kostprijsbesparing van 0.1% bereikt moeten de volumes behoorlijk zijn om dit interessant te maken.

[H!GHGuY]

farlane schreef op maandag 27 juli 2015 @ 09:53:
[...]
De embedded van nu is een whole lot different dan de embedded van een 10 jaar terug, en ik ben daar blij om. Nu vind men het bijna vanzelfsprekend dat er een USB aansluiting, netwerk, Bluetooth en WiFi op een embedded apparaat zit, en dat kan ook omdat de MCU's het inmiddels ook aankunnen. Heerlijk werken is dat. Ik haal ook geen voldoening uit het persen van een applicatie in 256 bytes RAM, terwijl er eigenlijk 2x zo veel nodig is om het fatsoenlijk te doen, verschikkelijk onzinning werk.

Ik zou met veel plezier onze legacy 8051 meuk aan jou uitbesteden en je er veel success mee wensen.

Akkoord. Wij zijn er ook een stuk op vooruitgegaan wat debugging capabilities betreft (en gelukkig maar!).
Wij zitten trouwens met high-end embedded hardware (oud platform: 800MHz singlecore PowerPC (~10jr oud), nieuw: 1GHz 6-core MIPS64r2 (~3jr oud) en nu gaan we zelfs porten naar high-end Xeons).

farlane schreef op maandag 27 juli 2015 @ 10:28:
Die embedded is precies hetzelfde, en is ook hetzelfde als niet-embedded software. Waarom zou het ook anders zijn? Als je product voldoet aan de requirements ben je klaar, zo simpel is het.

Het verschil zit er em in dat veel embedded spul eenmaal geschreven wordt en de kous is af (zoals jij aanhaalt). Dan kan het voor heel hoge oplages opleveren om te optimaliseren zodat de kost gedrukt kan worden.
Bij ons hebben we voor het oude + nieuw platform elk jaar 4 nieuwe unified releases met een zo goed als gelijke feature set. Dus moet je ervoor zorgen dat je niet achter 3 slecht geschreven features je product opzij mag zetten. Niet elke developer houdt non-functional requirements zoals scalability/performance, security, debuggability, maintainability, ... even goed in het achterhoofd.

[farlane]

H!GHGuY schreef op maandag 27 juli 2015 @ 10:58:
Het verschil zit er em in dat veel embedded spul eenmaal geschreven wordt en de kous is af (zoals jij aanhaalt). Dan kan het voor heel hoge oplages opleveren om te optimaliseren zodat de kost gedrukt kan worden.

Mijn ervaring is dat men na 10 jaar nog om uitbreidingen vraagt Daarom wil ik bij de start ook niet zo kritiek gaan zitten met mijn specs. (Tenzij er een requirement is die dat noodzakelijk maakt )

Niet elke developer houdt non-functional requirements zoals scalability/performance, security, debuggability, maintainability, ... even goed in het achterhoofd.

De meeste van die dingen schaar ik onder "fatsoenlijke software engineering" en zijn voor mij vanzelfsprekend. Scalability is een beetje een ander ding imho, daar moet echt om gevraagd worden, of het moet overduidelijk zijn dat dat een aandachtspunt is/gaat worden.

[The Eagle]

Punt is denk ik dat, even afgezien van embedded spul, je veel te makkelijk en goedkoop bij kunt schalen en dat het heel normaal is voor een stuk software om bij een nieuwe versie hogere eisen aan de hardware te stellen.
Dan kun je wel leuk alles tot het uiterste willen benutten, maar als dat meer aan dev tijd kost dan het ooit op zal leveren dan is dat natuurlijk geen haalbare case. Bovendien: als X nu de standaard is qua mem en CPU resources, dan is X+n dat tegen de tijd dat het product uit de betafase is. Combineer dat met de al genoemde schaalbaarheid en je zult snappen dat er over het algemeen geen haan naar kraait.

Vwb embedded geldt natuurlijk ook dat de techniek daar niet stil staat en dat er steeds meer resources op een chip passen. Dus tegen de tijd dat je dan klaar bent met devven had je al die moeite ook vaak niet hoeven doen. Je moet ergens beginnen natuurlijk, en dat is met wat voor handen is. Maar de wet van Moore geldt nog steeds

[Brilsmurfffje]

Wat ik vooral vervelend vind van de huidige programm's is dat het allemaal traag en log is. Kijk waar je vroeger windows XP op draaide, een 5400rpm IDE schijf. Nu werken we met breedband verbindingen en SSD's.

Maar is de gehele experience er nou zoveel sneller op geworden? Op sommige vlakken, Office is snel nu. Maar zaken zoals Spotify starten echt traag als stront op, slurpen werkelijk ram en cachen als je niet oppast vele mb's van de hardeschijf.

[kwaakvaak_v2]

Als ik alle bovenstaande dingen zo eens lees, ben ik toch soort van blij dat ik heb leren denken en soort van programmeren op een Commodore 64 in assembly (demoscene) en tot op de dag van vandaag nog steeds bepaalde principe's daarvan gebruik zoals lookup tables ipv voor alles maar een losse query draaien, dingen snel naar een functie met parameters omzetten ipv 5 functies die bijna hetzelfde doen. Maar ook suffige dingen voor de frontend, bijna geobsedeerd CSS, JS en images optimizen en zoveel mogelijk in cache zetten waar maar kan.

[farlane]

kwaakvaak_v2 schreef op maandag 27 juli 2015 @ 22:05:
Als ik alle bovenstaande dingen zo eens lees, ben ik toch soort van blij dat ik heb leren denken en soort van programmeren op een Commodore 64 in assembly (demoscene) en tot op de dag van vandaag nog steeds bepaalde principe's daarvan gebruik zoals lookup tables ipv voor alles maar een losse query draaien, dingen snel naar een functie met parameters omzetten ipv 5 functies die bijna hetzelfde doen. Maar ook suffige dingen voor de frontend, bijna geobsedeerd CSS, JS en images optimizen en zoveel mogelijk in cache zetten waar maar kan.

Vergis je niet, ik predik niet om maar rücksichtslos resources te verkwanselen : een verkeerd gekozen container, een kreupel algoritme dat soort dingen worden echt wel aangepakt.
Het probleem ontstaat echter als men in de naam van snelheid of "optimalisatie" concessies gaat doen aan de structuur of eenvoud van de software.

[.oisyn]

kwaakvaak_v2 schreef op maandag 27 juli 2015 @ 22:05:
Als ik alle bovenstaande dingen zo eens lees, ben ik toch soort van blij dat ik heb leren denken en soort van programmeren op een Commodore 64 in assembly (demoscene) en tot op de dag van vandaag nog steeds bepaalde principe's daarvan gebruik zoals lookup tables ipv voor alles maar een losse query draaien

Maar dan vergeet je voor het gemak wel even dat het geheugen relatief gezien een stuk trager is geworden dan toentertijd. Een L2 cache miss kost je honderden cycles, daar kun je een hoop berekeningen in doen. Wat dat betreft staan bepaalde technieken die vandaag de dag zinnig zijn haaks op die van vroeger, en voor je het weet zit je de boel alleen maar slechter te maken ipv beter.

[jeroen3]

Brilsmurfffje schreef op maandag 27 juli 2015 @ 18:47:
Wat ik vooral vervelend vind van de huidige programm's is dat het allemaal traag en log is. Kijk waar je vroeger windows XP op draaide, een 5400rpm IDE schijf. Nu werken we met breedband verbindingen en SSD's.

Als je met de debugger aan een "OpenFileDialog" oproept dat komt er een enorm aantal libraries voorbij.
Eerst van je framework, dan van .NET, dan van Windows, dan van plugins, je antivirus. Die moeten allemaal van disk komen . Dat draagt niet bij aan de snelheid.

Als je met de Windows Performance Analyzer een trace maakt van het starten van Google Chrome, dan zie je dat chrome een heel groot aantal processen en threads start. Je antivirus raakt helemaal opgewonden, en aangezien al die processen een hoopje dll's moet laden is het niet zo snel op een HDD.

[kwaakvaak_v2]

.oisyn schreef op maandag 27 juli 2015 @ 23:53:
[...]

Maar dan vergeet je voor het gemak wel even dat het geheugen relatief gezien een stuk trager is geworden dan toentertijd. Een L2 cache miss kost je honderden cycles, daar kun je een hoop berekeningen in doen. Wat dat betreft staan bepaalde technieken die vandaag de dag zinnig zijn haaks op die van vroeger, en voor je het weet zit je de boel alleen maar slechter te maken ipv beter.

Dat klopt, maar ik schrijf momenteel vooral web spul, en daar is een query over het algemeen nog trager dan een lezen en schrijven naar een stukje shared geheugen.