Hoofdcategorieën

[RSS] Index » Nieuws » Core » Software » 'Software maakt onvoldoende gebruik van multicore-cpu'

'Software maakt onvoldoende gebruik van multicore-cpu'

Door René Wichers, donderdag 27 oktober 2005 18:36
Bron: InfoWorld, views: 19.275

De hardwarewereld heeft de cpu met twee of meer cores ontdekt, observeert InfoWorld; alle fabrikanten hebben tegenwoordig multicorechips in hun assortiment. De software-industrie heeft echter flink wat moeite om zich aan de veranderende omgeving aan te passen, zei Herb Sutter, softwarearchitect van Microsoft, op het Fall Processor Forum in Californië. Omdat multithreading al een paar jaar tot de mainstream-technologie op de servermarkt behoort, maken serverapplicaties ondertussen redelijk goed gebruik van het vermogen een aantal taken parallel uit te voeren. Servertaken laten zich vaak ook makkelijker tot concurrency verleiden: een webserver die twee bezoekers tegelijk bedient, kan die twee taken zonder problemen tegelijk afhandelen.

Microsoft Research-logo Voor clientside toepassingen is er echter nog niet veel meer gedaan dan de meest rendabele tweaks. De meeste software voor end users wordt nog steeds sequentieel verwerkt: één instructie tegelijk. Hoewel processorbouwers daarop inspeelden met technieken als branch prediction - waarbij de cpu in zijn 'vrije tijd' alvast een aantal verschillende uitkomsten uitrekent, en daaruit kiest als duidelijk is wat de precieze input voor een stuk code wordt, moeten softwarebouwers beter rekening met de multithreaded cpu's gaan houden. Net als object-geörienteerd programmeren vergt het maken van multithreaded software een nieuwe benadering van de softwareontwikkeling, waarbij in dit geval steeds in het achterhoofd moet worden gehouden dat een applicatie in een aantal kleine stukjes moet kunnen worden verdeeld. Alleen dan kan software optimaal van de nieuwe hardwaretechnologie gebruik maken.

Deze nieuwe benadering vraagt veel, wellicht zelfs te veel, van de ontwikkelaars. De multicore-technologie zal weinig nut hebben als de hardwaremakers daarom niet beter op de programmeerbaarheid van hun systemen gaan letten, zei Sutter: 'Snelheid komt pas op de tweede plaats; chipfabrikanten moeten vooral niet aannemen dat de ontwerpers van besturingssytemen en software wel raad met dergelijke problemen weten.' Microsoft werkt onder zijn leiding aan het Concur-project, dat programmeurs helpt om eenvoudiger parallellisme in software te bouwen, maar een dergelijke inspanning heeft wel hulp van de hardwarebouwers nodig. Nu de kloksnelheden van processors zo'n beetje tegen het plafond zitten, zou verdere snelheidswinst van computers in de praktijk wel eens kunnen afhangen van hoe succesvol de samenwerking tussen hardware- en softwaremakers wordt.

Athlon small > large > many-progressieplaatje

Volgende 20:39
Vorige 16:16

Categorieën

Gerelateerde artikelen

Reacties

Flat modeFlat mode Sorteer aflopendSorteer aflopend Moderatie FAQModfaq
Niveaufilter: -1 Ongewenst: 72 reacties zichtbaar720 Neutraal: 69 reacties zichtbaar69+1 Meerwaarde: 21 reacties zichtbaar21+2 Verplicht leesvoer: 9 reacties zichtbaar9
«  1  2  »

Door Laagvliegerke, donderdag 27 oktober 2005 18:42

Score: 0
Hieruit begrijp ik dus dat een multicore CPU voorlopig nog weggegooid geld is.

Door 3gel, donderdag 27 oktober 2005 18:46

Score: 2
Niet helemaal. Wanneer je namelijk meerdere applicaties draait, worden de taken volgens mij WEL verdeeld over de cores. Zo kun je dus rustig gamen terwijl er geleeched wordt :Y)

Waar het hier om draait is dat de applicaties zelf nog niet met meerdere cores werken.

Door Laagvliegerke, donderdag 27 oktober 2005 19:06

Score: 0
Doet Windows 2K/XP dit automatisch? Of moet je zelf de taken toewijzen aan een core?
Zelfs al gebeurt de toewijzing automatisch, dan nog is dit niet voor iedere gebruiker interessant. Niet iedereen draait meerdere CPU-intensieve taken tegelijkertijd. Veel gamers doen enkel maar aan gamen en tegelijkertijd niks anders. Dan is zo'n multicore cpu voorlopig niet interessant. Dan betaald hij beter wat meer voor een snellere videokaart :)
Voor bepaalde ontwikkelaars, kan het misschien wel interessanter zijn. Op mijn stageplaats (enkele jaren geleden) had iedereen twee PC's. Terwijl de ene druk bezig was met compileren, kon men verder werken met de andere. En omgekeerd. Met een multicore CPU zou dat ook met 1 PC kunnen.

Door _Pussycat_, donderdag 27 oktober 2005 19:31

Score: 1
Ja, dat doet je OS zelfstandig.

Door mr._Anderson, donderdag 27 oktober 2005 19:31

Score: 0
Windows XP doet dit automatisch. (2000 vanaf SP x ?)

Zoals uit alle reviews en testen naar voren komt is het voor gamers ook niet interessant.

Maar er zijn heel veel toepassingen te vinden waarbij het wel interessant kan zijn.

Ik denk bijv. aan designers welke photoshop open hebben staan en andere programma's, 3D design..
zoals jij al aangaf: compileren en programmeren tegelijk.

Wanneer je ook maar twee of meerdere zware programma's naast elkaar draaid krijg je enorm veel winst. Wanneer je alleen maar spellen draaid, dan houd het op. Wanneer je dan weer een server direct meedraaid kan het weer wel handig zijn :)

Door mjtdevries, vrijdag 28 oktober 2005 13:17

Score: 1
Wat nou 2000 vanaf SPx???

ELKE NT versie (incl 2000) heeft dat altijd al automatisch gedaan.
ELK OS dat met meerdere cpu's om kan gaan doet dat automatisch!

Door bjorntje424, donderdag 27 oktober 2005 19:34

Score: 0
Zo kun je dus rustig gamen terwijl er geleeched wordt
Welke p2p gebruik je dan wel niet wat zoveel cpu kracht gebruikt?

Door jiriw, donderdag 27 oktober 2005 19:50

Score: 1
Ach ... als je je data met een paar kbyte per seconde binnenkrijgt zal ik me niet zo druk maken nee. Echter als het een paar megabyte per seconde is... Neem bijvoorbeeld bittorrent. Je bittorrentclient moet veel verschillende kleine stukjes data in hoog tempo naar je hardeschijf wegschrijven en er van ophalen, hij moet een x aantal verschillende cachesystemen bijhouden en checksums controleren, 100+ TCP connecties openhouden (als je flink wat seeds/leeches hebt). Als ik mijn lijn 'dichttrek' (10mbit, half-duplex) met een paar torrents en met zo ong. 300 andere computers een verbinding onderhoud (hoe gefragmenteerder hoe zwaarder) dan begint mijn AthlonXP 2400+ aardig te zweten hoor... CPU usages van gemiddeld 50% zijn echt geen uitzondering. En dan wordt het grootste deel van mijn HDD werk nog door de SCSI controller gedaan. Als ik naar een van mijn USB schijven wegschrijf wil je helemaal niet weten wat mijn CPU belasting is....

Door Depress, donderdag 27 oktober 2005 18:46

Score: 2
Nee, je gebruikt hem nu niet, maar als je een pc met multi core koopt dan koop je een pc die wel wat meer als 3 jaar mee kan. Tegen die tijd zullen toch wel al wat applicaties zijn die gebruik maken van deze techniek.

Door Laagvliegerke, donderdag 27 oktober 2005 19:01

Score: 0
Tegen die tijd
Dus voorlopig weggegooid geld want "tegen die tijd" zullen die CPU's ook wel goedkoper zijn ;)

Door DikkeDouwe, vrijdag 28 oktober 2005 11:21

Score: 0
PCs die langer als 3 jaar meegaan bestaan niet :+

Door franswilco384, vrijdag 28 oktober 2005 12:52

Score: 0
Ooit van een Mac gehoord? :)

Door ThunderNet, donderdag 27 oktober 2005 18:46

Score: 1
Tuurlijk niet... je draait namelijk meer dan 1 proces tegelijk ?

As we speak draai ik 42 processen en 522 Threads. Waarvan een groot deel gewoon processortijd wil :)

Door SG, donderdag 27 oktober 2005 19:00

Score: 1
Naast SMP kan je ook Multitasken daar heb je geen SMP support voor nodig :)

Maar ja de software migratie gaat volgens de hardware tak gewoon te langzaam. Maar wel zoals verwacht vind ik.

Je hebt dus 'n applicatie pobleem en daar voor kom je met 'n software oplossing. Normaal ging dat met één thread. Voor de desktop markt. Nu Moet je het probleem eerst analiseren voor opdeling in stukken die goed parralel en in afzonderlijke threads te doen zijn en dan dus voldoende parraleliserings winst opleveren.

Simpel voor beeld. je splitst de Game engine in 'n Server side en 'n client side module en elk met hun eigen tread. Ook voor 'n Single player game.
De meeste games hebben kwa OOP design al zo'n opdeling. dus de volgende stap is dus Die modules in een apparte thread te zetten. Maar hier bij kom met thread synchonisate en Save multithreading toch mee rbij kijken dan 'n create_thread() ergen in poten.

Dit kan verder doorgevoerd worden door nog mee rmodules in een eigen thread te zetten.
Het delen is niet het grootste probleem. Maar de thread shynchronisatie en thread save coden en interfacen is een must en veel meer werk dan gedacht.

Tja en nu is nog Single thread design de routine is. Is het in het begin dus pioneers werk. En de afweging of de rendement ervan het waard is voor die extra inspanning van dev resources maakt dus elk game engine team dus uit.

Dingen die performance hongerig zijn makkelijk te splitsen relatief eenvoudig tread save te maken door minimale afhankelijk heden die worden al snel SMP enable. Zoals video encoders. Games o.a lijkt mij 'n ander verhaal.

Aangezien de next gen console multi core platformen zijn kan het niet anders. Ze moeten 'n keer die stap toch doen ivm concurentie. Voor alle andere apps buiten games geld het zelfde. De deelbaarheid en de afhankelijk heden van die modules. bepalen de complexiteit en of het de moeite wel waard is naar SMP te stappen.

Door pinockio, vrijdag 28 oktober 2005 03:11

Score: 0
Dual core is absoluut geen weggegooid geld. Voor ca. 100-200 euro meer heb je een veel soepeler werkend systeem en bij ondersteunde software (bijv. Pinnacle Studio) ook een bijna 2x zo grote snelheid.

Waarom is je systeem soepeler? Omdat je ene core je hoofdproces kan afhandelen, en de andere alle bijprocessen (zoals: Windows services, virusscanners, firewalls, P2P programma's, etc., etc.)

Ik heb hier op mijn pc ca. 50 processen tegelijk draaien...

Juist het switchen tussen processen zorgt voor veel vertraging (let maar eens op hoe traag je programma's worden op het moment dat je een nieuw programma erbij opent).

Door Meneer Dik, vrijdag 28 oktober 2005 11:53

Score: 0
Onder Linux kan je heel makkelijk gebruik maken van multicore processoren. Als je bijvoorbeeld een AVI filmpje op DVD wil zetten knoop je gewoon een AVI decoder programma, video filter programma's en een MPEG2 encoder aan elkaar via UNIX pipes:

<decoder> | <filter1> | <filter2> | ... | <encoder>

Al deze programma's worden parallel uitgevoerd en automatisch over alle processoren en cores verdeeld, hoef je niks voor te doen. Je kan ze zelfs via een netwerk over meerdere computers laten verdelen, maar dat is ietsje ingewikkelder.

Verder zijn multicores natuurlijk erg leuk als je met meerdere mensen regelijk op 1 Linux machine werkt in een server / thin client configuratie.

Door toermalijn, donderdag 27 oktober 2005 19:00

Score: 1
Denk aan servers en professionele toepassingen. Ook photoshop, 3d paketten e.d. maken nu al gebruik van multi-core of multiprocessoren! Reken maar dat het scheelt of je dan 1 of 2 gebruikt. Ook kun je meer threads tegelijk draaien; dus meer apps tegelijk open!

Het heeft weldegelijk veel voordelen, alleen NIET voor gamers!

Door Murcielago, donderdag 27 oktober 2005 19:10

Score: 1
misschien ook wel, ik draai bijvoorbeeld standaard best wat applicaties die allemaal draaien. een aantal daarvan zijn beste grootverbruikers. zoals grabit, decoden kost veel processorkracht, vaak wel 20%, die kan die dus niet uitvoeren als ik aan het gamen ben. met multicore kan dat dus wel

Door SG, donderdag 27 oktober 2005 19:06

Score: 2
Het gaat hier om de Desktop markt. Daar is dit SMP loos probleem.

Onbetaalbaar DC zijn al vanaf ¤250 te krijgen.
'n X2 4200+ is 'n beetje meerprijs voor die tweede core inbegrepen en iNTel heeft 'n twee tal instappers. De P D 820 en P D 830.

en daarnaast voor Xbox 360 en PS3 moeten ze de SMP weg in om het onderste uit de kan te halen voor die game console platformen. En door cross platform development profiteerd hier de PC gamer tak ook van.

Unreal3 engine gaat SMP supporten duurt nog wel even eer de eerste game uitkomt.

Door MAX3400, donderdag 27 oktober 2005 19:03

Score: 2
Het nut van multi-cores bewijst zich wel degelijk ondanks dat huidige software niet altijd geschreven is daarvoor. Onder Windows (sinds NT, maar meer vanaf 2000) kan je processen aan cores toewijzen en daarmee de andere cores ontlasten. Verder zijn er wel al een aantal applicaties, voornamelijk CAD/CAM en video-editing, die wel degelijk gebruik maken van multi-cores en daar relatief gezien ook veel beter mee presteren t.o.v. single-cores.

Wat men wel even over het hoofd ziet (zie ook recentelijk de nieuwe lijsten van AMD), is dat je met een dualcore CPU met bijvoorbeeld 2x 2GHz veel meer rekenkracht hebt dan 1x 4GHz. Zo draai ikzelf bijvoorbeeld VMWare op mijn 2e core, de processen voor FireFox, Outlook en dergelijke draaien ook op core2 en daardoor heb ik ongeveer 95% van mijn eerste core beschikbaar voor makkelijk & snel een game spelen.

Door n4m3l355, donderdag 27 oktober 2005 19:49

Score: 2
echter dual cores zijn sterk teruggeklokt tov single core. met andere woorden als een process die je eerst op een 3.6ghz zou draaien amd of een 3600+ amd en die stop je nu in een 3600x2 of welke Intel variant die daaraan gelijk is zal er onder de meeste omstandigheden verlies optreden. die single thread die essentieel is naast de standaard threads gaat er dus op teruguit. met andere woorden deze schrijver heeft zeker gelijk in de zin van als jij specifiek 1 soort software gebruikt naast de rest. inderdaad wanneer jij en browsed, en photoshoppped en dan nog wat text zit te editen dan zul je met de dual core winst boeken maar de meeste mensen zijn in tegenstelling tot hun software niet multi-tasking

Door k1n8fisher, donderdag 27 oktober 2005 20:19

Score: 0
Maar als je dus zelf de instellingen aanpast kan je wel optimaal gebruik maken een dual core CPU. Dit lijkt mij namelijk de oplossing voor een "onbruikbare" PC die een paar uur staat te rekenen voor 1 DVD project dat ik wil wegbranden in Pinnacle Studio!
Als ik dat namelijk doe reageert de rest van de PC niet meer door de hoge core belasting en hier zou een 2e core er mooi voor kunnen zorgen dat ik mooi door kan gaan met andere dingen ipv dit soort taken voor 's nachts te bewaren!

Door RuL0R, donderdag 27 oktober 2005 20:44

Score: 0
echter dual cores zijn sterk teruggeklokt tov single core.
Ja toch wel zeker 200Mhz...

Door RedLizard, donderdag 27 oktober 2005 21:37

Score: 1
@HighwayDevil: 2 CPUs van 2 GHz per stuk zijn zeker niet sneller dan 1 van 4 GHz. Als je applicaties er - hypothetisch - perfect op gebouwd zijn, en je hebt - ook in je OS - nul overhead, dan kan je evenveel rekenkracht halen als bij single CPU, maar meer zit er echt niet in.

@k1n8fisher:
Als ik dat namelijk doe reageert de rest van de PC niet meer door de hoge core belasting
Daar hebben ze prioriteitenlevels en CPU quanta voor. Zet Pinnacle maar eens op prioriteit 0, dan zal dat best meevallen.

Door KnetterGek, zaterdag 29 oktober 2005 20:21

Score: 0
Vind je zelf wel dat je clientside software noemt als je met VMWare aan het spelen bent? Men doelt hier op de modale JBL thuis, die de snelheid van een extra core in Doom, FEAR en Outlook Express dus totally niet ziet.
En dat je kan multitasken is ook al geen goeie, want dat doen thuisgebruikers ook al zelden.

Dat jij thuis op je werkstation server software draait is natuurlijk een mooie reden om een multicore CPU te nemen maar dan heb je wellicht ook al een hele tijd dual opteron of xeon systemen gebruikt. Check het verbazingwekkend lage aantal multi-cpu setups bij modale mensen thuis.

Door Luxx, donderdag 27 oktober 2005 19:09

Score: 1
En als je dan bedenkt dat dit nog 2 identieke cores zijn die 'alle soorten' instructies kunnen behandelen... Als het hier al zo enorm lastig is, en lang duurt, kan je nagaan hoe lang het nog gaat duren voor een CELL-achtige volledig benut wordt. Geen wonder ook dat de PS3 niet al te populair is onder softwaremakers.

Intel wil ook naar zo'n soort architectuur toe, dus dat zal in de toekomst nog veel meer problemen zorgen. Hopelijk komen ze nog met veel ontwikkel-tools, of brengt Intels eigen compiler weer eens een snelle oplossing.

Door koelpasta, vrijdag 28 oktober 2005 13:35

Score: 0
Cell is weer een apparte architectuur.,
Anders als bij de 360 zitten er in de Cell een soort co-processors.
Deze staan over het algemeen onder leiding van de hoofdprocessor.

Die hoofdprocessor geeft 'paketjes' van te berekenen data door naar de lokale geheugens van de SPU's (de subprocessortjes).
Deze draaien hun eigen programma code maar die is veel eenvoudiger omdat zo'n SPU zich vooral met zichzelf bezighoudt.
Deze code draait ook vanaf dat locale geheugen en is dus paralel aan de hoofdprocessor.
Dit betekent weer dat ze elkaar niet in de haren zitten, dus minder overhead.

Je bouwt in feite kleine OO progjes (code + data) die je uit gaat delen aan de SPUs

Die gaan gewoon lekker hun gang op de data en als ze klaar zijn dan schrijven ze de data weer terug.

Door deze manier van werken heb je veel minder last van synchroniciteitsproblemen dan met 3 all-purpose cores zoals op de 360.
Daar moet je namelijk elke core veel zinniger gebruiken door inderdaad bijvoorbeeld op de ene een client thread en de andere een server thread en de derde een gfx-engine thread te laten draaien.
Dit houdt in dat er 3 grote threads tegelijk draaien en dat die dus aan elkaar moeten syncen.
Zo'n grote thread heeft namelijk heel veel interne afhankelijkheden en kan niet makkelijk anticiperen op wat er op de andere cores gebeurt.

Bij de cell heb je een hogere 'resolutie' van cpu's met slechts 1 cpu die de hoofdthread draait.
Die enkele thread bepaalt wat en wanneer er dingen naar de SPU's gestuurd worden.
Die SPUs zijn een soort onafhankelijke slaafjes die opzich veel kunnen (volwaardige cpu's) maar vooral als number-crunchers zullen worden ingezet.
Omdat het meerdere (kleinere) cores zijn, zijn ze efficienter te schedulen door de hoofdthread.
Ze draaien dus niet non-stop een apparte hoofd-thread, ze zijn juist gemaakt voor het bulk-verwerken van data voor de hoofdthread op de main core.
Die is de baas en daarmee ben je van een groot deel van je sync problemen af.

De cell is dus een erg cool 'systeempje' :)

Door carpin, donderdag 27 oktober 2005 19:18

Score: 0
Word wat als AMD de X32 80000+ uitbrengt binnenkort.


:P

Door Johnny, donderdag 27 oktober 2005 19:24

Score: 2
Een bestaande applicatie multithreaded maken is ook niet echt makkelijk, dan kan je in de meeste gevallen het beste helemaal opnieuw beginnen, en daarnaaast is het ook nog een stuk ingewikkelder omdat er dan van alles gesynchromiseerd moet worden, en biedt het voor de meeste desktop-applicaties niet echt veel snelheidswinst.

Door Bobco, vrijdag 28 oktober 2005 09:04

Score: 0
Voor sommige applicaties is herschrijven misschien ook wel het beste. Zelf heb ik nog dagelijks de twijfelachtige eer om te mogen werken met Outlook2000. Deze mail client is niet in staat om tegelijkertijd mail op te halen en de gebruiker een nieuwe mailtje te laten maken.

Nu is dit niet zo'n heel nieuw stuk software, maar multi-threading is nu niet iets wat opeens in de afgelopen 2 jaar is uitgevonden. Ik begrijp de opmerkingen van Sutter dan ook niet zo goed, maar ik ben ook geen OS guru.

Het lijkt me dat een OS een runnable thread toch aan een willekeurige 'vrije' core moet kunnen toewijzen en aan het werk zetten. Op dit manier hoef je je applicatie alleen maar netjes multi-threaded te maken en het OS zorgt vervolgens voor de optimale benutting van je hardware.

Heeft iemand wat meer info over hoe de verschillende OS'en omgaan metCPU affinity van processen?

Door mjtdevries, vrijdag 28 oktober 2005 10:58

Score: 0
Ik denk dat die Sutter bedoeld dat programmeurs toch echt zelf bezig moeten gaan met multithreaded programmeren, en niet kunnen verwachten dat compilers dat automatisch voor hen gaan oplossen. (zoals sommigen lijken te denken)

Wat betreft het OS is het in wezen heel simpel.

Inderdaad kan het OS een thread aan een willekeurige vrije core/cpu toewijzen. Als je applicatie maar netjes multithreaded is dan werkt dat allemaal perfect.

Wat betreft affinity. Je ziet vaak dat die threads regelmatig van de ene core/cpu op de andere overgaan, maar i.t.t. wat veel mensen denken geeft dat geen performance issues. Daar hoef je je echt niet druk om te maken. (en programmeurs ook niet)
Zowiezo is dat al veel minder het geval als beide cores/cpu het al druk hebben.

En multithreading ook al nuttig is bij 1 core/cpu, omdat het dan ook de cpu efficienter benut, dus het is al jaren hoog tijd dat programmeurs multithreaded gaan werken.

[edit:] Het orginele artikel nog eens gelezen en volgens mij weet Sutter zelf niet wat ie bedoeld.
Aan de ene kant beseft ie dat de programmeurs van hun luie gat af komen en geen "free lunch" meer krijgen. Aan de andere kant roept ie hardware fabrikanten op, om die programmeurs toch hun "free lunch" geven.

Door Chris P, donderdag 27 oktober 2005 19:25

Score: 0
De toekomst van processors ligt volgens mij ook bij het ontwikkelen van cores die specifieke dingen kunnen samen te voegen. 1 core voor videobewerken, 1 voor spellen, 1 voor internet & office applicaties etc.

De software ontwikkelaars hebben dus ook geen keus en moeten echt hard aan de slag gaan willen beide partijen dit laten werken!

Door Mizitras, vrijdag 28 oktober 2005 00:03

Score: 0
Dat noemen ze een subjectieve visie geven. Oftewel zoals wij dat kennen op T.net, een zogenaamde m-e-n-i-n-g. Ja, voor mij is het ook nieuw :-)

Door SuperDre, donderdag 27 oktober 2005 19:51

Score: 2
Ze kunnen het beter wat algemener zeggen: 'De huidige software maakt gewoon helemaal geen nuttig gebruik meer van de processor'...

alles wordt steeds 'lomper' geprogrammeerd, waardoor je steeds een snellere pc nodig hebt om hetzelfde resultaat te behalen..

Door sirdupre, donderdag 27 oktober 2005 20:27

Score: 0
Wat stel je dan voor? Alle spellen maar weer in Assembly gaan maken?
Het is gewoon een logische afweging tussen wat developers en wat hardware kost.

Door mjtdevries, vrijdag 28 oktober 2005 13:26

Score: 0
Jaaa, da's een goed idee.

Laten we Quake5 in assembly maken. Dan weten we tenminste absoluut zeker dat het lompe code wordt, waar een developer veel langer mee bezig is en die veel langzamer is dan als je het gewoon in C maakt!

Door mike_mike, donderdag 27 oktober 2005 20:36

Score: 0
alles wordt steeds 'lomper' geprogrammeerd, waardoor je steeds een snellere pc nodig hebt om hetzelfde resultaat te behalen..
Dat heeft niets met multithreaded programmeren te maken. Integendeel, de broncode wordt alleen maar gecompliceerder, onoverzichtelijker en vaak lelijker (lees: meer moeilijk te vinden bugs) in een geforceerde multithread oplossing. Enkel om een beetje snelheidswinst te pakken, vaak dus alleen maar de moeite waard bij servertaken of ingewikkelde berekeningen.
Net als object-geörienteerd programmeren vergt het maken van multithreaded software een nieuwe benadering van de softwareontwikkeling
Deze vergelijking uit het artikel gaat niet op. Object georienteerd leidde tot nettere en overzichtelijkere, maar meestal langzamere code, multithreading tot ingewikkeldere maar snellere. Exact ook de doelen die OOP en multihreading natreven.

Door Skinkie, donderdag 27 oktober 2005 20:39

Score: 0
Grotere bedrijven willen makkelijker te maken code. Java perfect te onderhouden :r

SuperDre heeft gelijk, SSE, MMX, etc. worden allemaal niet ten volle gebruikt.

Door wimmi, donderdag 27 oktober 2005 23:22

Score: 1
Object georienteerd leidde tot nettere en overzichtelijkere, maar meestal langzamere code
Denk dan ook even aan de ondersteuning van multicore door de beschikbare compilers of erger: de bytecode interpreters van VB, Java of C#.

Het vak van CPU's programmeren (echt iets uit de jaren '80) en de kunst van grootschalige software programmeren is zover uit elkaar gegroeid dat goed doordachte programma-archtectuur moeilijk te realiseren is.

Waarom maakt Intel niet eens een Java-CPU? Iets wat de bytecode direct door de CPU laat verwerken?

Door RefriedNoodle, vrijdag 28 oktober 2005 09:11

Score: 0
Het vak van CPU's programmeren (echt iets uit de jaren '80) en de kunst van grootschalige software programmeren is zover uit elkaar gegroeid dat goed doordachte programma-archtectuur moeilijk te realiseren is.
Je doet alsof dat iets slechts is. Inderdaad, programmeurs van nu zitten geen assembler in te kloppen, maar dat kan in deze tijd van grafische interfaces en windows en widgets ook niet meer. Je gaat niet steeds opnieuw het wiel uitvinden, je bouwt op bestaande blokken.

Een architect (van gebouwen) tekent ook hele muren tegelijk, en niet elk steentje apart opnieuw. Als je een pc bouwt, koop je ook losse functionele blokken (psu, moederbord, cpu, harddisk) in plaats van losse ic'tjes en weerstandjes en een soldeerbout.

Noem het de vooruitgang...

Door jj71, vrijdag 28 oktober 2005 10:58

Score: 0
Waarom maakt Intel niet eens een Java-CPU? Iets wat de bytecode direct door de CPU laat verwerken?
Sun maakt de picoJava Core, een microprocessor core die Java bytecode als native instructieset heeft, maar voor zover ik weet is er geen toepassing voor PC's of servers die hiervan gebruik maakt.

Door mjtdevries, vrijdag 28 oktober 2005 13:23

Score: 0
Wat bedoel je met je opmerking over de ondersteuning van multicore door de beschikbare compilers of bytecode interpreters?

Java heeft namelijk uitstekende multithreading support, dus daar zit het probleem niet.

Door mieJas, donderdag 27 oktober 2005 22:37

Score: 0
Ligt dat niet gewoon aan de x86 architectuur? Die is ondertussen ook al opa geworden...

Door gmdehaas, vrijdag 28 oktober 2005 08:38

Score: 0
Dat is niet waar!
Relevante software wordt wel gebruik gemaakt van multi-threading en multi-processing:
- Alle databases
- Alle web servers (en dus web applicaties)
- veel business applicaties (n-tier model)
Het converteren van filmpjes en spelen van spelletjes wordt hier bij Tweakers een beetje onder een vergrootglas gelegd, maar is in mijn ogen minder relevant.
Daarnaast is voor 99% van de desktop-gebruikers de langzaamste singlecore Celeron al ruim snel genoeg.
Tenslotte: de die-hard gamer kan beter 100euro extra uitgeven aan een snellere GFX-kaart dan aan een extra core.

Door mvdlee, vrijdag 28 oktober 2005 10:20

Score: 1
Denk jij dat ASM nog realistisch is in een wereld waarin:

A. Complexiteit van de x86 architectuur zo groot is geworden dat er slechts weinigen meer zijn die grote stukken ASM kunnen schrijven die efficiënt werken.

B. Er sowieso enorme lappen ASM nodig zouden zijn om zelfs de meest triviale dingen te doen. In dat soort code bugs vinden is een crime, en een algorithme aanpassen betekent opnieuw beginnen.

C. Compilers tegenwoordig dusdanig goed optimaliseren dat er slechts weinig programmeurs zijn die béter ASM kunnen schrijven.

Dit tesamen maakt het eigenlijk vrij zinloos om nog direct op de CPU te programmeren tenzij je tijd te veel hebt.

Door peke, donderdag 27 oktober 2005 20:04

Score: 0
Maar dat komt nog wel, UT2007 gaat gebruik maken van meerdere cores.
Het zal wel jaren duren vooralleer alle nieuwe zware apps (vooral games) er gebruik van maken maar zodra de bal aan het rollen is kan de rest niet achterblijven.
Zeker is dat je met een dualcore een groot voordeel hebt naar de toekomst toe.

Door Green.Velvet|IA, donderdag 27 oktober 2005 20:20

Score: 2
Is toch niets nieuw ? Er is al jaren geen software meer die echt optimaal gebruik maakt van de beschikbare hardware.

Games komen nog een beetje in de buurt, maar bij office toestanden is het gewoon huilen met de pet op. Bloated unoptimized software die vaak op ultrasnelle hardware amper vooruit te branden is...

Door Pietje Puk, vrijdag 28 oktober 2005 00:12

Score: 0
Games komen absoluut niet in de buurt.
Games moeten allereerst op allerlei verschillende hardware werken en daarnaast zijn games allesbehalve geoptimaliseerd voor zaken als Hyperthreading, multicore, SSE enz enz. Nee, juist games zijn de meest lomp geprogrammeerde stukken software die er bestaan.
«  1  2  »

Op dit item kan niet meer gereageerd worden.

Volgende 20:39
Vorige 16:16
VNU Media logo Powered by True

© 1998 - 2008 Tweakers.net - Alle rechten voorbehouden

Uitgever van: