Western Digital stapt over op 4kB-sectoren bij Caviar Green-hdd's
Fabrikant Western Digital heeft een nieuwe indeling voor de datablokken van zijn Caviar Green-harde schijven geïntroduceerd. De datablokken zijn vergroot van 512 bytes naar 4 kilobyte, wat de hoeveelheid overhead moet verminderen.
Sinds jaar en dag zijn de logische datablokken van harde schijven onderverdeeld in sectoren van 512 bytes, maar naarmate de capaciteit van harde schijven toeneemt, zorgt dit voor veel onnodig ruimteverlies. Elk blok wordt namelijk geflankeerd door blokken gegevens die het juist wegschrijven van data moeten faciliteren. Hierbij is vooral het blok dat voor ecc of foutcorrectie gereserveerd wordt inefficiënt. Western Digital ontwikkelde daarom een moderner indeling voor de data op informatiedragers en noemt deze architectuur Advanced Format.
Volgens WD zou vooral het reduceren van het aantal ecc-blokken een forse capaciteitswinst tot gevolg hebben: het weglaten van een groot deel van de sync/dam-blokken - de lege ruimtes tussen sectoren en de ecc-blokken - zou de bruikbare capaciteit van een harde schijf met 7 tot 11 procent kunnen vergroten. Om compatibiliteit met oudere apparatuur te waarborgen emuleert de Advanced Format-firmware de nu nog gebruikelijke 512 byte grote blokken. Windows 7 en Vista kunnen out-of-the-box al met de 4kB-blokken overweg; voor Windows XP heeft Western Digital een tooltje beschikbaar gesteld die dit OS daar alsnog geschikt voor maakt.
Nieuwe harde schijven uit de Caviar Green-serie zijn de eerste drives met de Advanced Format-technologie aan boord. De platters moeten bij het fabricageproces geschikt worden gemaakt voor het gebruik van de 4kB-sectoren; het is niet mogelijk om reeds geleverde schijven met een firmware-upgrade alsnog van de nieuwe indeling te voorzien. De eerste 500GB-per-platter-drives met AF, in capaciteiten van 1TB, 1,5TB of 2TB, worden inmiddels geleverd; ze zijn herkenbaar aan het typenummer EARS op het eind en de 64MB in plaats van 32MB grote cache. WD verwacht dat het Advanced Format binnen vijf jaar door alle harddiskfabrikanten wordt gebruikt.
Reacties (151)
Ik vind het jmr dat het niet mogelijk is dit toe te passen op reeds bestaande hdd's.
Dat komt doordat op harde schijven in de fabriek een indeling wordt gemaakt die dient als leidraad voor de lees-/schrijfkoppen.
Die indeling is niet te wijzigen / herschrijven met de koppen, want die zijn afhankelijk van die indeling.
Die indeling is niet te wijzigen / herschrijven met de koppen, want die zijn afhankelijk van die indeling.
Vroeger moest je met mfm controllers nog zelf de indeling bepalen/uitrekenen m.b.v. edlin. Maar ook daar waren er beperkingen aan het OS dat je gebruikte. Je kon toen wel al 'over sizen'. Ik zie niet in waarom dat nu alleen in de fabriek kan. Lowlevel format i.c.m. een andere firmware moet gewoon kunnen lijkt me.
Ik vraag me wel af of (hardware) raid controllers hier mee overweg kunnen.
Ik vraag me wel af of (hardware) raid controllers hier mee overweg kunnen.
[Reactie gewijzigd door DukeBox op zaterdag 12 december 2009 10:51]
mbv Edlin ?
Dat was een text editor, hoe wil je daar mee rekenen ?
Dat was een text editor, hoe wil je daar mee rekenen ?
Het ging om het aanroepen van een bepaald geheugenadres in het bios van de schijfcontroller, dat vervolgens een low level format uitvoerde.
In die tijd werd koppositie nog gewoon bepaald met een stappenmotor, en was er dus ook geen noodzaak om de koppositie dynamisch te bepalen aan de hand van de data die al op de schijf staat. Het is duidelijk dat bij een dergelijke schijf het niet mogelijk is de kopen -- althans niet zomaar -- te gebruiken voor LLF. Waarschijnlijk wordt het in de fabriek gedaan door positionele feedback te voorzien dmv een directe meting op koppositie, of door de koppen mechanisch te laten aansturen door een externe motor.
In die tijd werd koppositie nog gewoon bepaald met een stappenmotor, en was er dus ook geen noodzaak om de koppositie dynamisch te bepalen aan de hand van de data die al op de schijf staat. Het is duidelijk dat bij een dergelijke schijf het niet mogelijk is de kopen -- althans niet zomaar -- te gebruiken voor LLF. Waarschijnlijk wordt het in de fabriek gedaan door positionele feedback te voorzien dmv een directe meting op koppositie, of door de koppen mechanisch te laten aansturen door een externe motor.
bedoelt waarschijnlijk debug.exe
commando voor mfm was : g=c800:5
commando voor mfm was : g=c800:5
Ah...
Bringing back sweet memories... Heb ooit een 16 bits RLL controller gekocht om m'n schijf te pimpen. Kon ipv 1024 alle 1188 tracks gebruiken, meer sectoren per track (van 17 naar 26) en dat allemaal zonder interleaves..
Kan iemand zich nog Norton Calibrat heugen?
Bringing back sweet memories... Heb ooit een 16 bits RLL controller gekocht om m'n schijf te pimpen. Kon ipv 1024 alle 1188 tracks gebruiken, meer sectoren per track (van 17 naar 26) en dat allemaal zonder interleaves..
Kan iemand zich nog Norton Calibrat heugen?
Zullen we het ook nog even over ponskaarten en ponsbanden hebben? Dat waren de echte tijden. Toen waren backup tapes nog van papier. Als die papieren band op een rol zat was het in feite een voorloper van 3 dimensionale gegevens opslag, in tastbare zin.
Kun je de tien geboden nog heugen...? Die werden uitgehakt in steen...dat is pas 3D! 
Ja, maar dat is fiction, haha
@ johncheese002
Interactieve 3D zelfs !!
Interactieve 3D zelfs !!
[Reactie gewijzigd door E_E_F op zondag 13 december 2009 11:51]
Als je die tapes ook als rol kon uitlezen ipv. de hele tape af te moeten rollen naar dat ene stukje dan was het vast populairder geweest dan het vandaag is. Want dat er veel op een tape past als zgn. "3d opslag" staat vast.
Helaas, dat was RLL.bedoelt waarschijnlijk debug.exe
commando voor mfm was : g=c800:5
de indeling van de formattering , niet de fysieke schijfindeling.
ik snap ook eigenlijk niet waarom het niet kan, - je zou toch denken dat de firmware bepaalt welke bits gebruikt worden voor x en welke voor y,
best wel een raar verhaal - maar misschien is er iemand die hier iets zinnigs over kan zeggen...
best wel een raar verhaal - maar misschien is er iemand die hier iets zinnigs over kan zeggen...
Wat de ECC blokken betreft kan dat wel, maar de genoemde Sync/DAM blokken worden ingebakken in de structuur van de platter tijdens fabricage. Daar zitten bepaalde patronen in waardoor de hardeschijfcontroller ziet wanneer hij bij een nieuwe sector aankomt. Dit is niet aan te passen zonder de platters te vervangen.
ik neem aan dat je bedoelt welke voor de 1 en welke voor de 0 
niet echt... de disk is een matrix en de indeling is anders als je 4k blokken heb natuurlijk.
De huidige schijven zijn mechanisch niet instaat te bepalen waar de kop zich bevindt in relatie tot het magnetisch oppervlak (in het XT/AT tijdperk konden ze dat wel). Niet boven welk track en ook niet waar binnen het track. Om hier achter te komen hebben ze een bepaalde indeling van het magnetisch oppervlak nodig zodat ze kunnen zien aan de bits die langskomen waar ze zich bevinden. Deze indeling bepaalt tevens de blokgrote van 512 bytes. Omdat ze van deze indeling afhankelijk zijn kunnen ze deze niet wijzigen omdat ze tijdens het wijzigen dan geen houvast hebben om de nieuwe indeling betrouwbaar en accuraat te schrijven.
Neemt de read/write performance ook toe doordat er minder headers moeten worden gelezen/geschreven of begrijp ik het dan verkeerd?
Het zall wat afhangen van de situatie. Een 2KB bestand uitlezenvergde voorheen het uitlezen van 4 sectoren van elk 512 bytes. Nu is dat 1 sector va 4KKB. In dat geval lees je dus eigenlijk veel te veel data en zakt de performantie.
Ik gok dat in deze tijden van Terrabyte schijven en Gigabyte bestanden, het in de praktijk niet zoveel gaat uitmaken. Mocht de winst significant zijn, zouden ze er wel mee uitpakken denk ik dan.
Ik gok dat in deze tijden van Terrabyte schijven en Gigabyte bestanden, het in de praktijk niet zoveel gaat uitmaken. Mocht de winst significant zijn, zouden ze er wel mee uitpakken denk ik dan.
Pagesize op de meeste architecturen is 4K. Blocksize voor NTFS en ext3/4 is over het algemeen ingesteld als een veelvoud van 4K. Het heeft dus tegenwoordig weinig zin om nog met 512 bytes per sector te werken.
Bij SSD's lopen ze hier ook al langer tegenaan, zo wordt er daar ook al langer over gesproken.
Gaat dit ook niet meer IOps aankunnen doordat de RAID Controller (als je die gebruikt) minder werk hoeft te doen bij het berekenen van ECC / pariteiten?
Gaat dit ook niet meer IOps aankunnen doordat de RAID Controller (als je die gebruikt) minder werk hoeft te doen bij het berekenen van ECC / pariteiten?
Als ik me niet vergis worden de pariteiten berekend op het bestand "as is" en heeft de manier waarop het bestand wordt weggeschreven naar de schijf hier geen invloed op.
RAID en z'n pariteiten hebben niets met de individuele bestanden van doen. Een RAID controller ziet die bestanden ook niet, die krijgt gewoon blokken data binnen en doet daar wat mee.
Nee, want de sector ECC's worden berekend/gecontroleerd door de HDD.Gaat dit ook niet meer IOps aankunnen doordat de RAID Controller (als je die gebruikt) minder werk hoeft te doen bij het berekenen van ECC / pariteiten?
[Reactie gewijzigd door Carbon op vrijdag 11 december 2009 16:41]
Nou vraag ik me af, nemen doordat het minder blokken zijn, nu ook de hoeveelheid IO's die door het IO systeem naar de schijf gestuurt moeten worden nu ook een stuk lager, en wat scheelt dat in de overhead in de rest van het OS ?
Ik kan me voorstellen dat het voor het OS/driver gemakkelijker is, om 1 opdracht voor 4K te sturen, dan dat het dat is via 8 opdrachten van 512 B.
Ik kan me voorstellen dat het voor het OS/driver gemakkelijker is, om 1 opdracht voor 4K te sturen, dan dat het dat is via 8 opdrachten van 512 B.
De meeste OSen sturen I/O opdrachten bestaande uit meerdere sectoren in 1 opdracht naar de disk controller, en die stuurt het (hopelijk) ook in 1 keer door naar de disk zelf.
Enorm veel zal het dus niet schelen, misschien alleen in het (vrij zeldzame) scenario dat je continu bestandjes van minder dan 512 bytes zit te schrijven, op een filesystem dat ook blocksizes van 512 bytes gebruikt.
Enorm veel zal het dus niet schelen, misschien alleen in het (vrij zeldzame) scenario dat je continu bestandjes van minder dan 512 bytes zit te schrijven, op een filesystem dat ook blocksizes van 512 bytes gebruikt.
De default blocksize van NTFS is 4KB maw deze nieuwe sector formatering het geen negatieve invloed op de snelheid.Enorm veel zal het dus niet schelen, misschien alleen in het (vrij zeldzame) scenario dat je continu bestandjes van minder dan 512 bytes zit te schrijven,
[Reactie gewijzigd door Carbon op vrijdag 11 december 2009 16:44]
Eerder een positieve.
Immers als een file over 8 blocken van 512 bytes staat, zal hij straks in 1 proces gelezen kunnen worden.
Wel vreemd dat blocksize van b.v. NTFS niet in overeenstemming is met harddisks, eigenlijk nooit eerder bij stilgestaan. Maar bij Microsoft (en andere filesystem ontwikkelaars) zou je toch oog moeten hebben hoe fysiek bestanden worden weggeschreven om te voorkomen dat het door je ontworpen filesystem niet langzamer is.
Immers als een file over 8 blocken van 512 bytes staat, zal hij straks in 1 proces gelezen kunnen worden.
Wel vreemd dat blocksize van b.v. NTFS niet in overeenstemming is met harddisks, eigenlijk nooit eerder bij stilgestaan. Maar bij Microsoft (en andere filesystem ontwikkelaars) zou je toch oog moeten hebben hoe fysiek bestanden worden weggeschreven om te voorkomen dat het door je ontworpen filesystem niet langzamer is.
Een kleinere blokgrote leidt tot meer "boekhouding" wat ten koste van de ruimte voor data en de snelheid gaat. Grote blok grotes zijn potentieel inefficient wat ruimte gebruik betreft voor kleine bestanden. 4 kiB is een mooi compromis die waarschijnlijk ook gekozen is omdat dit de page grote van het geheugen is. Ext2fs van Linux kan bijvoorbeeld ook wel kleinere blokken aan.
Voor de performance is het verder helemaal niet erg om met een blokgrote te werken die groter is dan die van de harde schijf. Zolang het maar gaat om een veelvoud van de blokgrote van de schijf.
Voor de performance is het verder helemaal niet erg om met een blokgrote te werken die groter is dan die van de harde schijf. Zolang het maar gaat om een veelvoud van de blokgrote van de schijf.
Niet helemaal waar, OS doet wel aan command ordering en als het goed is (wat Novell al deed) zelf bepalen wat de beste volgorde is (elevator seeking).
Eigenlijk niet zo gek, aangezien er steeds meer RAD "programmeurs" inefficiënt met geheugen om gaan, waardoor je amper meer files hebt die minder dan 4KB groot zijn.
Sla maar eens een lege notepad document op (met 1 karakter).
Jammer dat er geen lobby of andere op hef is over het feit dat programmeurs steeds luier en slechter programmeren. In de derde wereld landen beginnen ze op oudere/langzamere hardware waardoor ze ook op lagere niveau (c en assembler) leren programmeren, met duizenden tegelijkertijd, terwijl er in b.v. in Nederland amper een opleiding in reguliere onderwijs te vinden is waar je deze talen nog leert. (of leerde)
Sla maar eens een lege notepad document op (met 1 karakter).
Jammer dat er geen lobby of andere op hef is over het feit dat programmeurs steeds luier en slechter programmeren. In de derde wereld landen beginnen ze op oudere/langzamere hardware waardoor ze ook op lagere niveau (c en assembler) leren programmeren, met duizenden tegelijkertijd, terwijl er in b.v. in Nederland amper een opleiding in reguliere onderwijs te vinden is waar je deze talen nog leert. (of leerde)
Mijn notepad bestand is 1KB. Dat is toch minder dan 4KB?
Denk je dat 1 karakter 1KB nodig heeft?
Wel als je clustergrootte van de partitie is ingesteld op 1kb...
De reden waarom dit wordt gedaan is dat de blokken van een bestand moeten worden bijgehouden in een "tabel": .. De blokken van een bestand staan namelijk niet altijd achter elkaar.
Zie het volgende voorbeeld bij een bestand van 4 bytes:
Als ieder byte apart zou worden opgeslagen in de tabel had je 10 bytes nodig:
-byte 1 staat op plek 3012312
-byte 2 staat op plek 3324233
-byte 3 staat op plek 232132
-byte 4 staat op plek 967678
Je bent dan dus 10 bytes plus de 4 bytes in de tabel kwijt = 14 bytes
Als je met een blok van 1024 bytes werkt is er maar 1 byte in de tabel nodig:
-De eerste byte van de 1024 begint op plek 2048
Je bent dan 1025 bytes kwijt.
De voorbeeld hierboven zijn slechts te illustratie, en ieder byte bijhouden zou het efficïents zijn..
Vanaf 513 bytes is het echter anders.. Dan wordt het bijhouden van blokken van 1024 bytes efficïenter. Een blok van 513 bytes zou namelijk 1024+1 byte = 1025 bytes kosten.
By ieder byte apart zou dit 513+513=1026 bytes kosten....
De meest efficïent blokgrootte is dus afhankelijk van de gemiddelde bestandgrootte
@ArnoutV:
Een notepad file van 1 byte neemt wel degelijk 1kb in op de schijf.. Dat betekent alleen niet dat het bestand ook 1kb aan inhoud bevat... Het heeft in ieder geval niets met afronding naar boven te maken.
De reden waarom dit wordt gedaan is dat de blokken van een bestand moeten worden bijgehouden in een "tabel": .. De blokken van een bestand staan namelijk niet altijd achter elkaar.
Zie het volgende voorbeeld bij een bestand van 4 bytes:
Als ieder byte apart zou worden opgeslagen in de tabel had je 10 bytes nodig:
-byte 1 staat op plek 3012312
-byte 2 staat op plek 3324233
-byte 3 staat op plek 232132
-byte 4 staat op plek 967678
Je bent dan dus 10 bytes plus de 4 bytes in de tabel kwijt = 14 bytes
Als je met een blok van 1024 bytes werkt is er maar 1 byte in de tabel nodig:
-De eerste byte van de 1024 begint op plek 2048
Je bent dan 1025 bytes kwijt.
De voorbeeld hierboven zijn slechts te illustratie, en ieder byte bijhouden zou het efficïents zijn..
Vanaf 513 bytes is het echter anders.. Dan wordt het bijhouden van blokken van 1024 bytes efficïenter. Een blok van 513 bytes zou namelijk 1024+1 byte = 1025 bytes kosten.
By ieder byte apart zou dit 513+513=1026 bytes kosten....
De meest efficïent blokgrootte is dus afhankelijk van de gemiddelde bestandgrootte
@ArnoutV:
Een notepad file van 1 byte neemt wel degelijk 1kb in op de schijf.. Dat betekent alleen niet dat het bestand ook 1kb aan inhoud bevat... Het heeft in ieder geval niets met afronding naar boven te maken.
[Reactie gewijzigd door MaZeS op vrijdag 11 december 2009 17:41]
Aan 1 byte per blok extra heb je niet genoeg voor hert bijhouden een byte kan namelijk slechts waardes van 0 t/m 255 opslaan. Hedendaagse filesystemen zijn 32, 64 of zelfs 128 bits. En gebruiken dus 4, 8 of 16 bytes voor dit doel plus nog wat extra voor efficiente zoek bomen zoals B* bomen.
Aan de andere kant zijn een hoop systemen tegen woordig ook in staat om de laatste stukjes van bestanden te groeperen in een enkel blok. Reiserfs kan dit bijvoorbeeld al wordt het er niet sneller van (tail/notail optie). Tevens zijn er filesystemen die heel kleine bestanden direct opslaan in de directory entry waar ook de naam en normaal de verwijzingen staan.
Aan de andere kant zijn een hoop systemen tegen woordig ook in staat om de laatste stukjes van bestanden te groeperen in een enkel blok. Reiserfs kan dit bijvoorbeeld al wordt het er niet sneller van (tail/notail optie). Tevens zijn er filesystemen die heel kleine bestanden direct opslaan in de directory entry waar ook de naam en normaal de verwijzingen staan.
NTFS dus, bestanden tot 48 bytes grootTevens zijn er filesystemen die heel kleine bestanden direct opslaan in de directory entry waar ook de naam en normaal de verwijzingen staan.
Een notepad file met 1 character is ook niet 1KB groot.
Dat is wat de verkenner toont, nl afgerond op KB, en ja het is naar boven afgerond
Een bestand in Notepad met alleen de letter a, zonder return is precies 1 byte groot.
Dat is wat de verkenner toont, nl afgerond op KB, en ja het is naar boven afgerond
Een bestand in Notepad met alleen de letter a, zonder return is precies 1 byte groot.
Ja maar hij neemt wel een volledig blok in beslag.Dit zal bij de defautt instelling van ntfs dus 4kB zijn.
Onder NTFS niet, daar zit ie gewoon in de directory entry. Bestanden tot en met 48 bytes krijgen onder NTFS geen separate cluster.
jij moet toch maar eens goed nadenken over de werking van computers en disken... denk je dat je disk een lijst heeft van alle bytes? Dan zou je weinig overhouden. Daarom de indeling in clusters
De verkenner rondt inderdaad wat af. Als je het precies wilt weten moet je de properties opvragen en dan zie je keurig:
Size: 1 bytes (1 bytes)
Size on disk: 4.00KB (4,096 bytes)
Size: 1 bytes (1 bytes)
Size on disk: 4.00KB (4,096 bytes)
Nee, dat is de afgeronde aantal bytes. Maar dan niet eens het aantal bytes op de schijf zelf. Op Windows XP(64 bit) zie ik bij een textfile 1 byte staan, en 4.096 bytes van de harddisk in beslag nemen.
Maar ik snap even het punt niet van totaalgeenhard: Trekt hij nu een voorbeeld uit Notepad naar aanleiding van z'n eerste alinea? Dan valt er niets op te merken, behalve dat het bestand fysiek 4kb inneemt ipv de logische 1 byte met die textfile met 1 karakter. Dat moet je los zien van inefficiënt met geheugen omgaan, en dat programmeurs daar debet aan zijn in het geval van Notepad iig. Maar het is wel efficient omgaan met de technische mogelijkheden van de moderne schijf.
Maar ik snap even het punt niet van totaalgeenhard: Trekt hij nu een voorbeeld uit Notepad naar aanleiding van z'n eerste alinea? Dan valt er niets op te merken, behalve dat het bestand fysiek 4kb inneemt ipv de logische 1 byte met die textfile met 1 karakter. Dat moet je los zien van inefficiënt met geheugen omgaan, en dat programmeurs daar debet aan zijn in het geval van Notepad iig. Maar het is wel efficient omgaan met de technische mogelijkheden van de moderne schijf.
Omgaan met geheugen en de grootte van bestanden hebben meestal niet al te veel met elkaar te maken... Als helemaal niet met de minimum grootte van een notepad document..
Aangezien RAM(ik neem aan dat je dat bedoelt) geheugen daarnaast een van de snelste te benaderen bewaarplaatsen voor informatie is is het daarnaast soms verstandig om er WEL zoveel mogelijk gebruik van te maken..
En waarom assembler en c tegenwoordig steeds minder worden gebruikt? Omdat het veel langer duurt om iets te bouwen, en je dan ook nog eens een grote kans op geheugenlekken/bufferoverflows etc hebt.
Aangezien RAM(ik neem aan dat je dat bedoelt) geheugen daarnaast een van de snelste te benaderen bewaarplaatsen voor informatie is is het daarnaast soms verstandig om er WEL zoveel mogelijk gebruik van te maken..
En waarom assembler en c tegenwoordig steeds minder worden gebruikt? Omdat het veel langer duurt om iets te bouwen, en je dan ook nog eens een grote kans op geheugenlekken/bufferoverflows etc hebt.
[Reactie gewijzigd door MaZeS op vrijdag 11 december 2009 16:46]
De reden dat cluster grote is gegroeid komt door de verandering van gebruik en gemiddeld bestand grote. In dat optiek is het gewoon logisch dat fysieke cluster grote overeenkomt met dat van meeste filesystems. Dat het sneller is door o.a. grote blokken te kunnen lezen als ook minder ECC controles (een kwart minder).
Aan de andere kant bij data recovery ben je MEER data kwijt.
Dat "hogere" talen minder capabele programmeurs instaat stelt iets gericht op functionaliteit te maken, is mooi. Echter dat er minder fouten gemaakt kan worden is niet per definitie zo. Immers een "hello world" standalone compilen kost in de meeste talen tegenwoordige vele megabytes, waaraan die programmeur niet gezeten als ook niet heeft (of kan) controleren. Memoryleaks ontstaan om vele redenen, die niet allemaal afgedekt kunnen worden (heb al een tijdje last van firefox onder win7 64bits). Iemand riep garbage collectie, deze zullen nooit efficiënter kunnen werken dan indien een programmeur zijn eigen troep zelf kan opruimen. Ik denk dat juist doordat mensen rekening houden met garbage collector ze inefficiënt met geheugen om gaan.
Ben overigens geen top programmeur en al jaren geen projecten gemaakt. Maar ik vind het wel vreemd dat we meer resources accepteren als compensatie van inefficiëntie programmeurs.
Windows 3.1 kon al alles wat ik er mee zou willen, echter op hedendaagse hardware zou het qua snelheid en resources ten dienste staan van mij en niet zoals vandaag de dag dat je Quadcore CPU + 8 GB DDR3 + 1 TB (raid 1+0) hebt en je bij een paar vensters of als je virusscanner start je systeem jouw laat wachten.
Met andere woorden, qua hardware is het misschien wel veel beter en betaalbaarder geworden maar door die RAD en diens gebruikers zorgen er wel voor dat je er minder uit zult halen. (plezier aan hebt)
*** off topic ***
Had niet het idee dat ik een knuppel in een hoenderhok gooide, ben inderdaad een dinosaurus die als laatste een X windows ging gebruiken. En heb vele demoscene parties bezocht. En weet wat er met 64KB al mogelijk is. -met hedendaagse hardware... zou ik weleens willen zien-
*** /offtopic ***
Aan de andere kant bij data recovery ben je MEER data kwijt.
Dat "hogere" talen minder capabele programmeurs instaat stelt iets gericht op functionaliteit te maken, is mooi. Echter dat er minder fouten gemaakt kan worden is niet per definitie zo. Immers een "hello world" standalone compilen kost in de meeste talen tegenwoordige vele megabytes, waaraan die programmeur niet gezeten als ook niet heeft (of kan) controleren. Memoryleaks ontstaan om vele redenen, die niet allemaal afgedekt kunnen worden (heb al een tijdje last van firefox onder win7 64bits). Iemand riep garbage collectie, deze zullen nooit efficiënter kunnen werken dan indien een programmeur zijn eigen troep zelf kan opruimen. Ik denk dat juist doordat mensen rekening houden met garbage collector ze inefficiënt met geheugen om gaan.
Ben overigens geen top programmeur en al jaren geen projecten gemaakt. Maar ik vind het wel vreemd dat we meer resources accepteren als compensatie van inefficiëntie programmeurs.
Windows 3.1 kon al alles wat ik er mee zou willen, echter op hedendaagse hardware zou het qua snelheid en resources ten dienste staan van mij en niet zoals vandaag de dag dat je Quadcore CPU + 8 GB DDR3 + 1 TB (raid 1+0) hebt en je bij een paar vensters of als je virusscanner start je systeem jouw laat wachten.
Met andere woorden, qua hardware is het misschien wel veel beter en betaalbaarder geworden maar door die RAD en diens gebruikers zorgen er wel voor dat je er minder uit zult halen. (plezier aan hebt)
*** off topic ***
Had niet het idee dat ik een knuppel in een hoenderhok gooide, ben inderdaad een dinosaurus die als laatste een X windows ging gebruiken. En heb vele demoscene parties bezocht. En weet wat er met 64KB al mogelijk is. -met hedendaagse hardware... zou ik weleens willen zien-
*** /offtopic ***
Als je gewoon met een script werkt of met dynamische bibliotheken (hergebruik) dan loop je niet tegen die problemen aan van kostbare opslag.
Een script kan makkelijk uit een honderdtal bytes bestaan.
Maar ik ben het helemaal met je eens als je naar bepaalde applicaties kijkt die honderden megabytes in beslag nemen terwijl het misschien ook wel in 25 mb of minder zou kunnen.
Het is belangrijk dat je de juiste instellingen voor de compiler kiest (stack groote, initial heapsize, libraries ).
Als je naar de effectieve code in een applicatie gaat kijken kom je inderdaad vaak op hooguit een paar duizend regels uit. Dat is ruwweg 100kb, en dat is het nog niet eens gecompileerd.
Kant en klare objecten maken programmeren flexibeler en sneller maar kosten veel resources, en dat is inderdaad zonde. Vooral als de gebruikersgroep groot is zou men daar meer aandacht aan kunnen besteden.
Een script kan makkelijk uit een honderdtal bytes bestaan.
Maar ik ben het helemaal met je eens als je naar bepaalde applicaties kijkt die honderden megabytes in beslag nemen terwijl het misschien ook wel in 25 mb of minder zou kunnen.
Het is belangrijk dat je de juiste instellingen voor de compiler kiest (stack groote, initial heapsize, libraries ).
Als je naar de effectieve code in een applicatie gaat kijken kom je inderdaad vaak op hooguit een paar duizend regels uit. Dat is ruwweg 100kb, en dat is het nog niet eens gecompileerd.
Kant en klare objecten maken programmeren flexibeler en sneller maar kosten veel resources, en dat is inderdaad zonde. Vooral als de gebruikersgroep groot is zou men daar meer aandacht aan kunnen besteden.
[Reactie gewijzigd door E_E_F op zaterdag 12 december 2009 14:07]
Is het ook niet zo dat die kant en klare objecten ook heel veel functies bevatten om 'iedereen' te pleasen? En niet een enkele specifieke functie bevattten? Om iedereen dus te pleasen en niet te vervelen met duizenden downloadables om daar weer een samengesteld object of wat dan ook van te maken, heb je tegenwoordig die resourcevretende packs. Ben het met je eens dat gebruikersgroepen daar echt op moeten gaan letten. Het is de Westerse wereld op de digitale wereld geprojecteerd qua verbruik 
Ja, daar ben ik het helemaal mee eens. Al die functionaliteit / flexibiliteit is dus van harte welkom van de ene kant. Maar het creeeren van sub classes en toevoegen van functionaliteit die stroom afwaarts misschien helemaal niet nodig is kost echter veel resources. Er bestaat simpel weg geen eenvoudige manieren om classes 'lichter' te maken. Daarvoor moet je de parent classes gaan aanpassen. En dan ga je steeds dieper graven. In dat geval is het dus beter om een (bijna) geheel nieuwe class te creeeren.
[Reactie gewijzigd door E_E_F op zondag 13 december 2009 12:32]
*Hap*
Het is gebleken dat deze 'RAD is poep' software over het algemeen een stuk onderhoudbaarder is dan het obscure byte-shifting assembly obfuscated hyperperforming GOTO spul. Verder doet software tegenwoordig wel wat meer dan de console apps van de jaren zestig.
De opoffering die daarvoor wordt gebracht is inderdaad het resource gebruik, maar zoals WD hier weer laat zien, kan dit met hardwareverbeteringen opgevangen worden.
Denk er aan dat de waarde van software zit in het nut dat de gebruiker ervan heeft, niet in de trots waarmee de programmeur het op zijn CV zet
Het is gebleken dat deze 'RAD is poep' software over het algemeen een stuk onderhoudbaarder is dan het obscure byte-shifting assembly obfuscated hyperperforming GOTO spul. Verder doet software tegenwoordig wel wat meer dan de console apps van de jaren zestig.
De opoffering die daarvoor wordt gebracht is inderdaad het resource gebruik, maar zoals WD hier weer laat zien, kan dit met hardwareverbeteringen opgevangen worden.
Denk er aan dat de waarde van software zit in het nut dat de gebruiker ervan heeft, niet in de trots waarmee de programmeur het op zijn CV zet
Dat hangt van je doelgroep af, en in het grote plaatje totaal onbelangrijk wat je daar zegt.
Dat JIJ voor GUI kiest maakt niet dat de wereld jouw keuze volgt.
Dat JIJ voor GUI kiest maakt niet dat de wereld jouw keuze volgt.
Je hebt gelijk, de meeste mensen gebruiken helemaal geen GUI, veel te onhandig en kost te veel resources.
Maar ja, misschien dat volgend jaar met Windows 3.1 daar verandering in komt.
Maar ja, misschien dat volgend jaar met Windows 3.1 daar verandering in komt.
Altijd grappig hoe die paar dinosaurussen die nog bij de command line zweren menen te moeten doen alsof ze een meerderheid vormen.
Om nou te doen alsof alleen dinosaurussen de command line gebruikenen is ook een beetje apart.
Er zijn genoeg situaties waar je met de command line sneller bent, probeer maar eens ff alle .torrent bestanden van je harde schijf te verwijderen bijvoorbeeld.
Of om even 2 pdfjes te combineren.
Of even snel te kijken of je uberhaupt wel een internetverbinding hebt. (ping)
Er zijn genoeg situaties waar je met de command line sneller bent, probeer maar eens ff alle .torrent bestanden van je harde schijf te verwijderen bijvoorbeeld.
Of om even 2 pdfjes te combineren.
Of even snel te kijken of je uberhaupt wel een internetverbinding hebt. (ping)
Nooit geweten dat een paar dinosaurussen 7,4 miljard waard zijn (overname van Sun door Oracle).
Btw, ik zie niet echt wat RAD met GUI's te maken heeft (ik ken ook genoeg command line unix tools die niet vooruit te bakken zijn door RAD).
Btw, ik zie niet echt wat RAD met GUI's te maken heeft (ik ken ook genoeg command line unix tools die niet vooruit te bakken zijn door RAD).
Oracle, ook weer zo'n mooi voorbeeld van bloatware. Er zijn modernere database pakketten, die sneller en veel kleiner zijn. Het oude Oracle 8 installeert al 100.000 bestanden op je schijf. Geen wonder dat openen van een bestand dan langer duurt. Je FAT wordt er zeer inefficient en overvol van. (Liever op een aparte partitie zetten dus.)
Veel succes met het draaien van een 7TB database op je standaard Debian MySQL Oracle valt niet voor niks in de Enterprise markt (net zoals bijvoorbeeld Sybase en Informix, wat net zulke bakbeesten zijn).
Oracle valt niet voor niks in de Enterprise markt (net zoals bijvoorbeeld Sybase en Informix, wat net zulke bakbeesten zijn).Databases die wederom op functionaliteit gebaseerd zijn, en niet op snelheid Maar de enterprise markt rouwt daar over het algemeen ook niet om. Het wil gewoon veel.
Maar de enterprise markt rouwt daar over het algemeen ook niet om. Het wil gewoon veel.Typisch kapitalistisch "pragmatiek boven alles" RAD poep mentaliteit ja.
Pragmatiek en functionaliteit is inderdaad een meer primaire behoefte dan esthetiek, en natuurkundige efficiency, in tegenstelling tot een kapitalistische definitie daarvan waarbij inefficiency wordt goedgepraat door vergroten en versnellen van finitiete exploitatie.
Bedenk wel dat zonder die RAD poep je PC hardware 2x sneller had kunnen werken. De ketting is zo sterk als zijn zwakste schakel, en dat moet je dus niet hebben in de lagere lagen van je abstractie model want de effecten spelen door op alles wat ermee is gebouwd of ermee samenhangt.
Met name vandaag de dag moet je je ook nog eens extra bewust zijn van natuurkundige energieverspilling, levensduur van batterijen, etc. Dus het is ook nog eens crimineel onverantwoord om RAD poep te ontwikkelen. De enige die RAD poep rechtvaardigt is de kapitalitische mentaliteit die zowieso weinig met ethiek van doen heeft.
Dat betekent niet per definitie dat alles in assembler moet, maar de verhoudingen tussen assembler en C (voor en nadelen) liggen echt wel anders dan tussen C en .NET poep. En dan weegt het een niet op tegen het andere.
Bovendien heb ik meer vertrouwen in iemand die .NET ontwikkelt maar met sterke C/C++ achtergrond dan iemand met VB achtergrond voor wie hoe alles onder de motorkap werkt nog magie is. Met RAD kom je te makkelijk weg met gebrekkige inzichten en kennis en het bedrijfsleven kan dat niet beoordelen omdat zij enkel functioneel en financieel denken.
Software zou ook energielabels moeten hebben.. Dan krijgen meeste RAD apps een F per definitie en zal een A veelal C zijn en A+ assembler optimized, en A++ volledig assembler, wat voor veel firmware ook beste keus zal zijn.
En software met slechtere energieverbruik moet extra belast worden.. dan geven we er meteen ook een kapitalitische betekenis aan.
Pragmatiek en functionaliteit is inderdaad een meer primaire behoefte dan esthetiek, en natuurkundige efficiency, in tegenstelling tot een kapitalistische definitie daarvan waarbij inefficiency wordt goedgepraat door vergroten en versnellen van finitiete exploitatie.
Bedenk wel dat zonder die RAD poep je PC hardware 2x sneller had kunnen werken. De ketting is zo sterk als zijn zwakste schakel, en dat moet je dus niet hebben in de lagere lagen van je abstractie model want de effecten spelen door op alles wat ermee is gebouwd of ermee samenhangt.
Met name vandaag de dag moet je je ook nog eens extra bewust zijn van natuurkundige energieverspilling, levensduur van batterijen, etc. Dus het is ook nog eens crimineel onverantwoord om RAD poep te ontwikkelen. De enige die RAD poep rechtvaardigt is de kapitalitische mentaliteit die zowieso weinig met ethiek van doen heeft.
Dat betekent niet per definitie dat alles in assembler moet, maar de verhoudingen tussen assembler en C (voor en nadelen) liggen echt wel anders dan tussen C en .NET poep. En dan weegt het een niet op tegen het andere.
Bovendien heb ik meer vertrouwen in iemand die .NET ontwikkelt maar met sterke C/C++ achtergrond dan iemand met VB achtergrond voor wie hoe alles onder de motorkap werkt nog magie is. Met RAD kom je te makkelijk weg met gebrekkige inzichten en kennis en het bedrijfsleven kan dat niet beoordelen omdat zij enkel functioneel en financieel denken.
Software zou ook energielabels moeten hebben.. Dan krijgen meeste RAD apps een F per definitie en zal een A veelal C zijn en A+ assembler optimized, en A++ volledig assembler, wat voor veel firmware ook beste keus zal zijn.
En software met slechtere energieverbruik moet extra belast worden.. dan geven we er meteen ook een kapitalitische betekenis aan.
Dat energielabel moet dan ook bevatten hoeveel er verstookt is/wordt tijdens het maken en onderhouden van de software. Dat duurt namelijk net iets langer als je Cof Assembly pakt.
dat een leeg notepad document een relatief grote ruimte aaneemt heeft niks met efficiëntie van de programmeur te maken, maar met de clustergrootte van een bestand.
Ga een willekeurige (Technische) Informatica studie of Elektrotechniek volgen en je leert het wel hoor, assembly en C.
Er is alleen gewoon veel vraag naar programmeurs voor hogere level talen, zoals C#, Java en de rest. Simpelweg omdat het programmeren makkelijk en snel gaat. Ook de goedkope x86 hardware helpt hier natuurlijk bij. Iedereen heeft tegenwoordig wel een of meerdere PC's.
Ga jij maar eens een windows applicatie in assembler schrijven, ik wens je succes.
Wat ik wel met je eens ben is dat veel programmeurs in hoge talen als C# bijv. geen flauw benul hebben hoe het geheugen van een PC gemanaged wordt of inderdaad ook hoe de opslag van data gebeurt. Ze zouden dit mijns inziens wel (ongeveer) moeten weten, ook al gebruiken ze de kennis in de praktijk nooit direct.
Er is alleen gewoon veel vraag naar programmeurs voor hogere level talen, zoals C#, Java en de rest. Simpelweg omdat het programmeren makkelijk en snel gaat. Ook de goedkope x86 hardware helpt hier natuurlijk bij. Iedereen heeft tegenwoordig wel een of meerdere PC's.
Ga jij maar eens een windows applicatie in assembler schrijven, ik wens je succes.
Wat ik wel met je eens ben is dat veel programmeurs in hoge talen als C# bijv. geen flauw benul hebben hoe het geheugen van een PC gemanaged wordt of inderdaad ook hoe de opslag van data gebeurt. Ze zouden dit mijns inziens wel (ongeveer) moeten weten, ook al gebruiken ze de kennis in de praktijk nooit direct.
Dat is de rede dat wij wat assembler en C hebben gekregen op school. Nou ja C ook voor de embedded zooi. Om inzicht te krijgen wat een processor en geheugen precies doen, en dat dan ongeveer te onthouden.
Een programmeur hoeft die zaken helemaal niet weten, das voor het CLR ontwikkelteam. Zij moeten vervolgens wel uitleggen aan de programmeur wat het beste is en daarvoor hebben we common practices.
Leuk als je gepassioneerd bent door je werk maar ik kan gerust zeggen dat minstens 50% van de programmeurs buiten het werk hun pc voor niet meer gebruikt dan mailtjes lezen of naar porno surfen. Ik zie elke dag mensen die niet verder kijken dan de lettertjes in hun cursus.
Leuk als je gepassioneerd bent door je werk maar ik kan gerust zeggen dat minstens 50% van de programmeurs buiten het werk hun pc voor niet meer gebruikt dan mailtjes lezen of naar porno surfen. Ik zie elke dag mensen die niet verder kijken dan de lettertjes in hun cursus.
Gelukkig is er ook meer op deze wereld dan .NET (CLR). Er zijn ook genoeg talen waar geen VM nodig is dat de compiler het naar native code compiled (C++ etc). Ik heb ook Elektrotechniek gedaan en daar leer je veel programmeren voor embedded apparatuur, daar leer je wel degelijk efficient programeren. Ik doe nu Java, maar dat neemt niet weg dat ik niet efficient programmeer. Ik vind dat je hoe dan ook zo efficient moet programmeren, ongeacht hoe makkelijk een taal moet zijn.
Of je nu voor een virtuele of echte machine ontwikkelt, het heeft altijd nut om kennis te hebben van hoe de compiler/machine omgaat met opslag en datatypes. Ook een virtuele machine slaat immers dingen op. Dat is standaard kennis dat je er bij een Programmer certificaat (in ieder geval bij Sun) ingeramd krijgt. Zal bij Microsoft niet anders zijn vermoed ik???
[Reactie gewijzigd door NLxAROSA op zaterdag 12 december 2009 10:15]
Maar je zult altijd wel leaky abstractions hebben, waardoor het wel handig is om wat meer te weten van de laag eronder.Een programmeur hoeft die zaken helemaal niet weten, das voor het CLR ontwikkelteam. Zij moeten vervolgens wel uitleggen aan de programmeur wat het beste is en daarvoor hebben we common practices.
Dat is een interessant artikel en het is ook meteen de reden waarom ik vaak c++ builder objecten mix met win32api aanroepen. Vaak is de documentatie van voorgebakken objecten ook dusdanig beperkt dat het sneller gaat zelf de benodigde functionaliteit te produceren, met soms ook meer betrouwbaarheid en overzicht (dat is ironisch). Deze mix werkt vaak ook efficienter.
Anders ga je eerst even gedegen onderzoek doen voor je een willekeurige groep mensen ergens de schuld van geeft. Feitelijk bega je nu exact dezelfde fout als waar je die lui van beschuldigt, namelijk niet rekening houden met alles in het systeem.Eigenlijk niet zo gek, aangezien er steeds meer RAD "programmeurs" inefficiënt met geheugen om gaan, waardoor je amper meer files hebt die minder dan 4KB groot zijn.
De inefficienctie van files hebben compleet niets te maken met de sectorgrootte van de HDD, en alles met de indeling van het filesysteem. Het is ranzig inefficient (zowel kwa snelheid als kwa hoeveelheid gebruikte schijfruimte!) om iedere individuele byte van een partitie alloceerbaar te maken, en daarom gebeurt dat doorgaans in blokken van typisch 4kB (wat tevens ook de page-grootte is van de CPU). Het resultaat is dan idd dat een file van 4097 bytes op een dergelijk filesystem dan idd 8kB in beslag neemt. Dit lijkt in eerste instantie weggegooide ruimte, maar daar krijg je wel een veel sneller systeem voor terug.
[Reactie gewijzigd door .oisyn op vrijdag 11 december 2009 16:51]
Precies. En dan nog zijn de prestaties met kleine benstanden niet geweldig; daar heeft je harddisk geel veel moeite mee. Jammer dat daar niks op te verzinnen is.
Als de bestanden nog kleiner zouden zijn, ik zou er niet aan moeten denken wat dat doet voor de prestaties van de harddisk
Als de bestanden nog kleiner zouden zijn, ik zou er niet aan moeten denken wat dat doet voor de prestaties van de harddisk
0 bytes, zegt Vista, bij een leeg tekstbestand. Met enkel het karakter '0' erin wordt 'ie meteen 4096 bytes.Eigenlijk niet zo gek, aangezien er steeds meer RAD "programmeurs" inefficiënt met geheugen om gaan, waardoor je amper meer files hebt die minder dan 4KB groot zijn.
Sla maar eens een lege notepad document op (met 1 karakter).
@deKeijzer: Ja, maar hij neemt dus al meteen 1 sector van 4KB in (niet 1KB).
[Reactie gewijzigd door Aham brahmasmi op vrijdag 11 december 2009 22:44]
Alleen de grootte op de schijf, de werkelijke grootte is toch nog gewoon 1 byte.
En ook dat lege bestand neemt ergens in een tabel een plekje in. Er moet tenslotte worden bijgehouden dat dat bestand bestaat. Evenals lege directory's/mappen/folders.
Dit is veel te kort door de bocht. Doordat computers veel sneller geworden zijn, is het mogelijk om veel meer abstracties te introduceren waardoor de programmeur minder werk *hoeft* uit te voeren. Met als extra voordeel dat heel veel fouten afgevangen kunnen worden in de abstractielagen (zoals libraries), die voorkomen dat programmeurs het wiel telkens opnieuw moeten uitvinden. Daarnaast is, doordat ze breed ingezet worden, de kans ook kleiner om fouten te bevatten.Jammer dat er geen lobby of andere op hef is over het feit dat programmeurs steeds luier en slechter programmeren.
Veel programma's zijn helemaal niet gebaat bij optimalisaties van cpu, bestandsgrootte, e.d. Dat wil niet zeggen dat je dan zo maar wat aan moet prutsen, maar je hoeft echt niet meer elk bitje 3 keer om te draaien
reusability is goed en handig en dus niet wiel opnieuw uitvinden.
Abstractie ook, mits onderliggende lagen maximaal zijn geoptimaliseert.
Als je dan MFC vergelijkt met STL, dan is dat slechts voorbeeld hoe Microsoft omgaat met die zaken en grootste deel van opensource community.
Dus je mag gerust ervan uitgaan dat .NET rad poep is.
Abstractie ook, mits onderliggende lagen maximaal zijn geoptimaliseert.
Als je dan MFC vergelijkt met STL, dan is dat slechts voorbeeld hoe Microsoft omgaat met die zaken en grootste deel van opensource community.
Dus je mag gerust ervan uitgaan dat .NET rad poep is.
Moderne garbage collectors zijn enorm goed geworden in het opruimen van inefficient geallocceerd geheugen, dus je bewering houdt weinig steek.
Voor wat meer uitleg paste ik hier een informatief linkje van een interview met James Gosling waarbij het heeft over de garbage collector:
http://parleys.com/displa...ing%20at%20JavaPolis%2707
Voor wat meer uitleg paste ik hier een informatief linkje van een interview met James Gosling waarbij het heeft over de garbage collector:
http://parleys.com/displa...ing%20at%20JavaPolis%2707
Lang leve de HEEEL efficiente garbage collectors. Ik heb eens een eenvoudige proef gedaan op het werk. Een eenvoudige proef applicatie met een eenvoudig 'spreadsheet' datamodel. Dus 4 classes een root, kolom, rjj en cell, de rij had een klein array met wat willekeurige data. vervolgens een spreadsheet van 1000x1000 geinstantieerd. En als test om de 10 rijjen 1 rij weggooien en aan het eind weer niewe rijen maken totdat originele groote er weer was. Vervolgens hetzelfde met de kolomen. Dit vervolgens in een loop 100.000 keer doen. Dit alles was in 15 min in elkaar geclicked met een freeware code generator tool 'ClassBuilder', deze had een run time van ongeveer 40 seconden. Een collega die de uitdaging aannam maakte een equivalente oplossings maar deed de implementatie met de STL librarie, die had 400 seconden nodig, dus al 10x langzamer. Vervolgens mocht een grote C# adapth aan de gang, helaas voor hem is de applicate na enige uren draaien maar afgebroken. De geweldige gargabe collector was helemaal niet zo geweldig.
Lees nog maar eens heel goed, als swtukken geheugen tweede orde worden, dan wordt het heel erg duur om ze te collecten, tevens als het in core geheugen gebruik hoog is, dan is de compactie van het geheugen ook geen pretige bezigheid. Dus er zitten wel degelijk wel wat haken en ogen aan het garbage collecting. Voor veel toepassingen kom je ermee weg, maar er zijn situaties dat het heel pijnlijk kan worden.
Voor de liefhebbers stuur ik met alle liefde de C++ code op, dan kunnen ze zelf java, C# of andere derivaten maken en zelf kijken wat er gebeurt.
Lees nog maar eens heel goed, als swtukken geheugen tweede orde worden, dan wordt het heel erg duur om ze te collecten, tevens als het in core geheugen gebruik hoog is, dan is de compactie van het geheugen ook geen pretige bezigheid. Dus er zitten wel degelijk wel wat haken en ogen aan het garbage collecting. Voor veel toepassingen kom je ermee weg, maar er zijn situaties dat het heel pijnlijk kan worden.
Voor de liefhebbers stuur ik met alle liefde de C++ code op, dan kunnen ze zelf java, C# of andere derivaten maken en zelf kijken wat er gebeurt.
Basis van een GC is gewoon als de verwijzing van de stack naar de heap weg is dat ie dan wordt opgeruimd. Dus als je dan wat rijen gaat verwijderen en je gooit de parent class weg (alle verwijzingen van de subclasses verdwijnen dan ook) is het object gelijk aangemerkt voor GC. "Probleem" van Java etc dat geheugen beperkt wordt. C++ gaat eigenlijk onbeperkt verder. Ik durf de uitdaging zeker wel aan met Java. Ik heb C++ gedaan (niet heel veel). Op mijn Java examens wordt ook veel aandacht besteeds aan GC.
De huidige GC algoritmes zijn zeer uitgebreid en efficient, zolang je alles goed afconfigureerd (genoeg geheugen als je plotseling erg veel gaat doen). Tevens in deze zeer geheugen intensieve programma's kun je beter GC hebben vanwege geheugen lekken etc, die krijg je redelijk snel in grote applicaties waar veel data heen e nweer gepompt wordt.
De huidige GC algoritmes zijn zeer uitgebreid en efficient, zolang je alles goed afconfigureerd (genoeg geheugen als je plotseling erg veel gaat doen). Tevens in deze zeer geheugen intensieve programma's kun je beter GC hebben vanwege geheugen lekken etc, die krijg je redelijk snel in grote applicaties waar veel data heen e nweer gepompt wordt.
Zelfs recente JVMs van Sun ruimen geheugen nog niet helemaal goed op en veroorzaken met bepaalde best normale constructies out of memory issues waar hiervoor helemaal geen noodzaak voor is. En dat is na meer dan 15 jaar werk eraan. En er is al die tijd altijd een betere bijna klaar die het probleem zal oplossen...het komt er alleen nooit van. Het is volgens mij ook meer een geloof in GC en een gebrek aan basale programmeer kennis die GC zo populair maakt onder nieuwe programmeurs.
Wat betreft demo programma's....als je goed kan programmeren is het doorgaans functioneel goed mogelijk in C++ een veel beter presterend resultaat neer te zetten dan met een op een GC gebaseerde taal. Je moet dan natuurlijk wel zelf over geheugen opbouw na gaan denken en hoe je interactie ermee is....die vrijheid heb je en daarmee komt ook meer verantwoordelijkheid. En ja, dat kost zeker meer programmeer werk en tijd. Je wordt dan wel beloond met een kleinere en meer statische (beter voor je processor) geheugen footprint en minder overhead waardoor je geavanceerdere constructies kan implementeren met betere prestaties als gevolg.
Zo moet je geheugen allocaties met eenzelfde lifetime als een groot blok (of serie daarvan) met meerdere elementen tegelijk alloceren (niet te verwarren met "contructen"). Als je verwacht 500 elementen van objecttype A nodig te hebben voor een bepaalde operatie, dan doe je 1 geheugen allocatie met ruimte voor 500 elementen en doe je individuele dynamische new operaties als nodig met behulp van een placement new. Vrijgeven van geheugen kun je dan voor alle 500 elementen in 1 keer doen. Eventuele destructors die als je het goed doet inline zijn worden gewoon optimaal verwerkt zonder overhead of zelfs weg geoptimaliseerd door de compiler als ze leeg zijn.
Daar kan geen GC tegenop. Je moet dit met template classes invullen natuurlijk, je gaat dit niet voor iedere class opnieuw programmeren. En natuurlijk zijn er altijd scenario's te verzinnen waar een GC (automatische runtime afhandeling) beter werkt, net zoals iedere benchmark naar je hand gezet kan worden. Maar claims dat een GC * per definitie * beter werkt en we niet meer om moeten kijken zijn onzin. Het werkt voor de meesten echt gemakkelijker, maar het is niet zonder nadelen...niets is geheel gratis in het leven en je kan in iedere taal troep schrijven. Vergeet dit laatste nooit in dit soort vergelijkingen.
Wat betreft geheugen lekken in C++, met een bepaalde programmeer stijl zijn lekken vrijwel uitgesloten aangezien de compiler voor alle mogelijke exits de passende opruim code automatisch voor je aanroept. Als iedere classe zichzelf netjes op kan ruimen is het voldoende met behulp van de stack unwinding de levensduur van objecten van die klasse te scopen en de compiler doet de rest. Dit kan ook voor objecten die op een heap zijn gealloceerd, moet je alleen een smartpointer of met een template gemaakte opruim classe voor het specifieke object op je stack zetten die wanneer het out of scope gaat automatisch destruct en ook het gealloceerde heap object meeneemt.
Uiteraard moet je geen circulaire referenties maken of alles met referenties aan elkaar pointeren zoals beginners vaak doen omdat er geen helder design is. Je moet dus weten waar je mee bezig bent en kunnen programmeren. Dezelfde constructies zijn voor een GC ook een ramp bij het opruimen van geheugen, maar zoals de eerdere poster al schreef...je komt er heel vaak mee weg en dat maakt het gemakkelijk.
Wat betreft demo programma's....als je goed kan programmeren is het doorgaans functioneel goed mogelijk in C++ een veel beter presterend resultaat neer te zetten dan met een op een GC gebaseerde taal. Je moet dan natuurlijk wel zelf over geheugen opbouw na gaan denken en hoe je interactie ermee is....die vrijheid heb je en daarmee komt ook meer verantwoordelijkheid. En ja, dat kost zeker meer programmeer werk en tijd. Je wordt dan wel beloond met een kleinere en meer statische (beter voor je processor) geheugen footprint en minder overhead waardoor je geavanceerdere constructies kan implementeren met betere prestaties als gevolg.
Zo moet je geheugen allocaties met eenzelfde lifetime als een groot blok (of serie daarvan) met meerdere elementen tegelijk alloceren (niet te verwarren met "contructen"). Als je verwacht 500 elementen van objecttype A nodig te hebben voor een bepaalde operatie, dan doe je 1 geheugen allocatie met ruimte voor 500 elementen en doe je individuele dynamische new operaties als nodig met behulp van een placement new. Vrijgeven van geheugen kun je dan voor alle 500 elementen in 1 keer doen. Eventuele destructors die als je het goed doet inline zijn worden gewoon optimaal verwerkt zonder overhead of zelfs weg geoptimaliseerd door de compiler als ze leeg zijn.
Daar kan geen GC tegenop. Je moet dit met template classes invullen natuurlijk, je gaat dit niet voor iedere class opnieuw programmeren. En natuurlijk zijn er altijd scenario's te verzinnen waar een GC (automatische runtime afhandeling) beter werkt, net zoals iedere benchmark naar je hand gezet kan worden. Maar claims dat een GC * per definitie * beter werkt en we niet meer om moeten kijken zijn onzin. Het werkt voor de meesten echt gemakkelijker, maar het is niet zonder nadelen...niets is geheel gratis in het leven en je kan in iedere taal troep schrijven. Vergeet dit laatste nooit in dit soort vergelijkingen.
Wat betreft geheugen lekken in C++, met een bepaalde programmeer stijl zijn lekken vrijwel uitgesloten aangezien de compiler voor alle mogelijke exits de passende opruim code automatisch voor je aanroept. Als iedere classe zichzelf netjes op kan ruimen is het voldoende met behulp van de stack unwinding de levensduur van objecten van die klasse te scopen en de compiler doet de rest. Dit kan ook voor objecten die op een heap zijn gealloceerd, moet je alleen een smartpointer of met een template gemaakte opruim classe voor het specifieke object op je stack zetten die wanneer het out of scope gaat automatisch destruct en ook het gealloceerde heap object meeneemt.
Uiteraard moet je geen circulaire referenties maken of alles met referenties aan elkaar pointeren zoals beginners vaak doen omdat er geen helder design is. Je moet dus weten waar je mee bezig bent en kunnen programmeren. Dezelfde constructies zijn voor een GC ook een ramp bij het opruimen van geheugen, maar zoals de eerdere poster al schreef...je komt er heel vaak mee weg en dat maakt het gemakkelijk.
[Reactie gewijzigd door TheCodeForce op zaterdag 12 december 2009 02:53]
Ik ben benieuwd hoe goed dat nu in de praktijk allemaal werkt bij COM objecten en interfaces waarbij de programmeur vaak zelf aan moet geven dat de reference counter van een instance verlaagd moet worden. Ervaring met geheugen leaks en het debuggen ervan m.b.t. COM ? Ik neem aan dat GC niet altijd goed zal werken.
[Reactie gewijzigd door E_E_F op zaterdag 12 december 2009 14:02]
COM objecten worden geschreven in C/C++. Dus niet in managed code zoals C# of Java. Er is hier dus geen sprake van GC.
Ik heb begrepen dat com objecten ook in andere talen geschreven kunnen zijn (niet alle) zolang aan bepaalde regels voldaan wordt. Dat van die GC is me nu duidelijk. Maar mijn volgende vraag is dan eigenlijk: Hoe gemakkelijk is het over het algemeen om memory leak te voorkomen als je applicaties schrijft die COM gebruiken. Het lijkt me dat het met die reference counters snel onoverzichtelijk wordt.
Je hebt gelijk dat er ook andere talen zijn waarin COM objecten geprogrammeerd kunnen worden. De meest gemakkelijke is wel het oude bekende "Visual Basic 6".
Wanneer je in VB6 COM objecten maakt en/of gebruikt heb je helemaal niets met reference counters te maken, dat wordt onder water voor je geregeld door de VB compiler. In deze omgeving gaat het dan ook eerder fout door circulaire referenties, waardoor een reference counter nooit op 0 kan komen. Met als gevolg dat het object en ALLE van daaruit gerefereerde objecten niet worden opgeruimd...de wel bekende memory leaks. Je moet eerst alle referenties zien te breken en dat betekend dat het dus niet altijd automatisch voor je gebeurd by een slecht uitgewerkt object model.
Vanuit C++, waar ik overigens nog zelden in ontwikkel (helaas), gebruikte ik nooit COM objecten. Dus hoe het daar met reference mamagement zit dat weet ik niet uit ervaring. Ik denk dat het normaal is dat er een wrapper class omheen te zetten die het voor je afvangt.
Wanneer de wrapper class instance (smartpointer) deleted wordt, dan zal de destructor de COM referentie met 1 verlagen en wordt het object opgeruimd als de teller op 0 komt. Niet zo heel ingewikkeld, maar wel net iets meer werk dan met bijvoorbeeld VB6. Het is denk ik een kwestie van een juiste techniek aanleren.
Verder heb je nog threading.locking issues als je met C++ werkt, iets waar VB6 met een COM object volgens het appartment threaded model geen extra werk vergt. Zij het dat je dan maar 1 thread tegelijk gebruik kan laten maken van het object. In C++ kun je dus COM objecten maken die wel threaded werken met alle extra complexiteit van dien.
Wanneer je in VB6 COM objecten maakt en/of gebruikt heb je helemaal niets met reference counters te maken, dat wordt onder water voor je geregeld door de VB compiler. In deze omgeving gaat het dan ook eerder fout door circulaire referenties, waardoor een reference counter nooit op 0 kan komen. Met als gevolg dat het object en ALLE van daaruit gerefereerde objecten niet worden opgeruimd...de wel bekende memory leaks. Je moet eerst alle referenties zien te breken en dat betekend dat het dus niet altijd automatisch voor je gebeurd by een slecht uitgewerkt object model.
Vanuit C++, waar ik overigens nog zelden in ontwikkel (helaas), gebruikte ik nooit COM objecten. Dus hoe het daar met reference mamagement zit dat weet ik niet uit ervaring. Ik denk dat het normaal is dat er een wrapper class omheen te zetten die het voor je afvangt.
Wanneer de wrapper class instance (smartpointer) deleted wordt, dan zal de destructor de COM referentie met 1 verlagen en wordt het object opgeruimd als de teller op 0 komt. Niet zo heel ingewikkeld, maar wel net iets meer werk dan met bijvoorbeeld VB6. Het is denk ik een kwestie van een juiste techniek aanleren.
Verder heb je nog threading.locking issues als je met C++ werkt, iets waar VB6 met een COM object volgens het appartment threaded model geen extra werk vergt. Zij het dat je dan maar 1 thread tegelijk gebruik kan laten maken van het object. In C++ kun je dus COM objecten maken die wel threaded werken met alle extra complexiteit van dien.
Aan de andere kant, je harde schijf capaciteit neemt ook weer af. Immers, een file van een paar byte wegschrijven kost minimaal 4 KB. De prestatiewinst wordt dus alleen behaald bij bestanden die groter dan 512 bytes.
En aangezien dat de meeste bestanden tegenwoordig wel zijn, zal dus winst dus voldoende zijn.
Als je alleen maar foto's/muziek/films op een HD zet dan ben je wel bij dat je een stuk meer ruimte heb. Ik zou er wel blij mee zijn.
Dat is alleen maar zo als je je schijf ook geformateerd hebt met een filesysteem dat blocks van 512 bytes gebruikt.
Maar bv NTFS gebruikt standaard al 4KB. Dus dan maakt het niet uit.
Maar bv NTFS gebruikt standaard al 4KB. Dus dan maakt het niet uit.
Dit ligt ook aan het bestandssysteem dat je gebruikt. FAT32 gebruikt bijvoorbeeld standaard al 4kb clusters als ik het goed heb. Dus dan levert het sowieso al geen verlies op, want dat verlies had je al door het bestandssysteem.
Gelukkig zijn niet alle bestandssystemen zo inefficient als FAT32.
Je kunt deze schijven natuurlijk ook alleen gebruiken voor opslag van grote bestanden. Ik zelf heb bijvoorbeeld een 500gb schijf waar vrijwel geen enkel bestand kleiner dan 4KB op staat. Dan zou voor mij de snelheidswinst wel degelijk nuttig zijn.
Gelukkig zijn niet alle bestandssystemen zo inefficient als FAT32.
Je kunt deze schijven natuurlijk ook alleen gebruiken voor opslag van grote bestanden. Ik zelf heb bijvoorbeeld een 500gb schijf waar vrijwel geen enkel bestand kleiner dan 4KB op staat. Dan zou voor mij de snelheidswinst wel degelijk nuttig zijn.
Een bijkomend voordeeltje is natuurlijk dat je de 2 TiB limiet even vooruitschuift. Die komt namelijk van 2^32 sectors * 512 bytes per sector = 2 TiB bytes. Met 4 kiB sectors kun je dan voorlopig nog tot 16 TiB.
Bovendien gebruiken de meeste OSen van tegenwoordig sowieso meestal al 4 kiB als standaard blocksize in hun filesystems, en 4 kiB is ook de meest gebruikte pagesize.
Alleen is het gegeven "sectoren zijn 512 bytes" wel in heel erg veel software hard gecodeerd, dus zul je wel een compatibiliteitsnachtmerrie krijgen.
Bovendien gebruiken de meeste OSen van tegenwoordig sowieso meestal al 4 kiB als standaard blocksize in hun filesystems, en 4 kiB is ook de meest gebruikte pagesize.
Alleen is het gegeven "sectoren zijn 512 bytes" wel in heel erg veel software hard gecodeerd, dus zul je wel een compatibiliteitsnachtmerrie krijgen.
Als de software goed gemaakt is kan je dat vrij makkelijk veranderen door één waarde aan te passen.
(waarschijnlijk zal er wel wat omvallen, maar als het allemaal goed is opgezet moet het niet al te veel problemen opleveren).
Verder is het misschien alleen de controller die het zo doet zodat jij als gebruiker/programmeur en niet al te veel van merkt.
(waarschijnlijk zal er wel wat omvallen, maar als het allemaal goed is opgezet moet het niet al te veel problemen opleveren).
Verder is het misschien alleen de controller die het zo doet zodat jij als gebruiker/programmeur en niet al te veel van merkt.
Helaas wordt er maar weinig software "goed" gemaakt.
Ik vraag me af in hoeverre ik dit kan vergelijken met bijvoorbeeld Variable Sector Size van Highpoint.
Zou het dan, met deze schijven, ook mogelijk zijn een MBR partitie te maken die groter is dan 2TB?
Ik kan me wel niet voorstellen dat je met de highpoint oplossing capaciteit wint. Anders is het wel jammer dat ik er niet mee geëxperimenteerd heb
Zou het dan, met deze schijven, ook mogelijk zijn een MBR partitie te maken die groter is dan 2TB?
Ik kan me wel niet voorstellen dat je met de highpoint oplossing capaciteit wint. Anders is het wel jammer dat ik er niet mee geëxperimenteerd heb
Maar dit betekent wel dat de interne fragmentatie een stuk groter wordt? Bij een DataHD waar je alleen films en series opzet zou het een stuk beter zijn, maar programma's en Windows zelf gebruiken vaak veel kleine bestandjes (bijv logs), dus daar verlies je mogelijk veel. Ook als een file over meer blokken verdeeld wordt zal het laatste blok ipv max 511 fragmentatie zelfs max 4095 bytes fragmentatie hebben.
Of ik beredeneer het volledig verkeerd
Of ik beredeneer het volledig verkeerd
[Reactie gewijzigd door Kixtart op vrijdag 11 december 2009 18:12]
Enigszins verkeerd, fragmentatie houdt in dat de datablokken die door een bestand gebruikt worden, verspreid over de schijf liggen.
Heb je nu een bestand van 513 bytes, dan had je in het verleden kans op fragmentatie: de 2 blokken zouden verspreid kunnen liggen. Nu is het 1 datablok, dus geen kans meer op fragmentatie voor dat bestand/blok (in dit geval hetzelfde).
Ik denk dat als we spreken over bestanden van > 100MB dat de kans op fragmentatie ook minder is, aangezien er minder datablokken benodigd zijn.
Heb je nu een bestand van 513 bytes, dan had je in het verleden kans op fragmentatie: de 2 blokken zouden verspreid kunnen liggen. Nu is het 1 datablok, dus geen kans meer op fragmentatie voor dat bestand/blok (in dit geval hetzelfde).
Ik denk dat als we spreken over bestanden van > 100MB dat de kans op fragmentatie ook minder is, aangezien er minder datablokken benodigd zijn.
Ik heb het over de interne fragmentatie van een cluster. Als je nu een bestand maakt van één enkel karakter dan zal deze 512bytes groot worden, terwijl het in principe in 1byte zou passen als de cluster die grootte was geweest. Nu heb je dus het probleem dat 4096bytes gebruikt wordt in dat geval.Enigszins verkeerd, fragmentatie houdt in dat de datablokken die door een bestand gebruikt worden, verspreid over de schijf liggen....
Ja, als je het hebt over sub-sector fragmentatie van ongebruikte ruimte, dan wel.Maar dit betekent wel dat de interne fragmentatie een stuk groter wordt?
De ongebruikte ruimte in sectoren waar kleine bestanden in staan kan niet voor andere bestanden gebruikt worden. Dat betekent dus dat er hele kleine stukjes lege ruimte gefragmenteerd worden, maar dit veroorzaakt in de praktijk enkel een verlies/verspilling van vrije ruimte. Het is niet zo dat door de vrije ruimte in sectoren, er veel meer zoek-acties gedaan moeten worden door de leeskoppen, dus er is praktisch geen prestatieverlies hierdoor.
[Reactie gewijzigd door Aham brahmasmi op vrijdag 11 december 2009 17:02]
Ja, ik had het interne fragmentatie genoemd, omdat de defrag van windows dat ook zo aangeeft gewoonlijk. Zelf had ik het niet over snelheidsverlies, maar het artikel had het over 7%-10% capaciteitswinst, dus vroeg het me af of dat in de praktijk ook snel zou zijn.
Ik vraag me af of HDD hierdoor sneller worden, naast dat de capaciteit wordt vergroot.
Nee, een OS stuurt in principe een batch opdrachten naar de controller, die die batch doorgeeft aan de schijf. Het is niet zo dat het efficiënter is om 1 keer 4kb door te geven, dan 8 keer 512b, als je dat bedoeld. Die 8 opdrachten worden ook in 1 keer naar de controller gestuurd.
De harde schijf kan effectief wel meer data kwijt op een spoor dus er zal een vergelijkbare toename in sequentiële transferrate zijn als in opslagcapaciteit.
begrijp ik dan goed dat een schijf die nu als 1TB wordt vekocht ,over de toonbank gaat voor 1,5TB.
Eigenlijk is dat wel raar,immers het aantal magnetische velden blijft het zelfde
Eigenlijk is dat wel raar,immers het aantal magnetische velden blijft het zelfde
7-11 procent, dus laten we zeggen max 1.1TB.
Als je het artikel leest niet, 7 tot 11% is geen 0,5TB, dat is namelijk 50% van 1TB.
Op dit item kan niet meer gereageerd worden.
Populair: Android Tablets Samsung Websites en communities Mobiele telefoons Google Microsoft Sony Games Politiek en recht
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
