Reacties (67)
:strip_exif()/u/26632/dosprompt2.gif?f=community){kind=small}
Als fervent SMPer zal het mensen wellicht verbazen dat ik nog steeds met slechts 2 cores werk (ook al is het nep SMP, want ik heb maar 1 echte proc 
), maar moet zeggen dat de snelheid van huidige dualcores vrij lekker werkt. Ik heb hier een Quadcore liggen (QX6850 ES), maar die heb ik tot op heden nog niet echt gebruikt, misschien toch eens doen om te kijken of het nou verschil maakt of niet.
Ik denk eerlijk gezegd dat we over een aantal jaren wel massaal software gaan zien die schaalbaar wordt over meerdere cores, dan zul je ook zien dat dual quadcore systemen interessanter gaan worden voor de thuismarkt en ik zie in de verre toekomst nog wel een multichip systeem, waarbij je een groot aantal cores hebt (128 of meer) die niet alleen de taken van de cpu op zich nemen, maar ook die van de gpu, de geluidskaart, netwerkkaart, physicskaart, raidcontroller etc door een core dedicated toe te wijzen. Door de hoeveelheid cores kun je hier erg flexibel in zijn, een nadeel zal wel weer zijn dat je hiermee niet de max snelheid kunt halen voor iets (een cpu is niet zo goed in gpu berekeningen bijvoorbeeld).
Een Hybride systeem zie ik ook nog wel ontstaan. Waarbij je een aantal dedicated cpu cores hebt, een aantal dedicated gpu cores en wat cores die bij kunnen springen bij de cpu of gpu, afhankelijk van waar het nodig is.
), maar moet zeggen dat de snelheid van huidige dualcores vrij lekker werkt. Ik heb hier een Quadcore liggen (QX6850 ES), maar die heb ik tot op heden nog niet echt gebruikt, misschien toch eens doen om te kijken of het nou verschil maakt of niet.Ik denk eerlijk gezegd dat we over een aantal jaren wel massaal software gaan zien die schaalbaar wordt over meerdere cores, dan zul je ook zien dat dual quadcore systemen interessanter gaan worden voor de thuismarkt en ik zie in de verre toekomst nog wel een multichip systeem, waarbij je een groot aantal cores hebt (128 of meer) die niet alleen de taken van de cpu op zich nemen, maar ook die van de gpu, de geluidskaart, netwerkkaart, physicskaart, raidcontroller etc door een core dedicated toe te wijzen. Door de hoeveelheid cores kun je hier erg flexibel in zijn, een nadeel zal wel weer zijn dat je hiermee niet de max snelheid kunt halen voor iets (een cpu is niet zo goed in gpu berekeningen bijvoorbeeld).
Een Hybride systeem zie ik ook nog wel ontstaan. Waarbij je een aantal dedicated cpu cores hebt, een aantal dedicated gpu cores en wat cores die bij kunnen springen bij de cpu of gpu, afhankelijk van waar het nodig is.
:strip_icc():strip_exif()/u/173551/crop5db8c76d03a24_cropped.jpeg?f=community){kind=small}
Zover in de toekomst moet je niet zoeken voor dat hybridesysteem. Zowel Intel als AMD willen in 2009 al iets dergelijks lanceren (respectievelijk Larrabee en Fusion), hoewel AMD de enige is die echt iets plant zoals jij noemt. Intel bouwt eerder een GPU die opgebouwd is uit getweakte "normale" CPU's.
Ik heb gestemd dat mijn volgende zeker een Quadcore wordt, maar zeg daarbij dat ik met mijn X2 6000+ toch echt wel nog een jaar of twee voort kan. Tegen dan is het wellicht al betaalbaar om een octacore te halen, maar ik wacht dus niet per se op octacores
.
Mijn mening is twee jaar geleden serieus veranderd op dit vlak. Ik had voordien een XP 2000+ en ik vond de sprong van de Ghz-race naar de multicore-race nogal bizar. Toendertijd dacht ik nog iets van "Wat maakt het nou uit dat je meerdere cores hebt? Als ze niet sneller worden, gaat het ook niet sneller!" maar mijn ogen zijn nogal abrupt opengevallen (zeg maar opengeblazen) toen ik merkte hoeveel responsiever mijn systeem werd met een dualcore (WinXP Pro SP2). Dus ik ben ervan overtuigd dat er een tijd komt dat je echt wel het verschil merkt tussen een dual of een quad in gewone gebruikersapplicaties.
Ik heb gestemd dat mijn volgende zeker een Quadcore wordt, maar zeg daarbij dat ik met mijn X2 6000+ toch echt wel nog een jaar of twee voort kan. Tegen dan is het wellicht al betaalbaar om een octacore te halen, maar ik wacht dus niet per se op octacores
.Mijn mening is twee jaar geleden serieus veranderd op dit vlak. Ik had voordien een XP 2000+ en ik vond de sprong van de Ghz-race naar de multicore-race nogal bizar. Toendertijd dacht ik nog iets van "Wat maakt het nou uit dat je meerdere cores hebt? Als ze niet sneller worden, gaat het ook niet sneller!" maar mijn ogen zijn nogal abrupt opengevallen (zeg maar opengeblazen) toen ik merkte hoeveel responsiever mijn systeem werd met een dualcore (WinXP Pro SP2). Dus ik ben ervan overtuigd dat er een tijd komt dat je echt wel het verschil merkt tussen een dual of een quad in gewone gebruikersapplicaties.
/u/200133/artemis_square_e_60-60.png?f=community){kind=small}
Totdat je merkt dat een singleThreaded taak op een Athlon64 X2 4200+ @ 2.2Ghz toch 20% sneller gaat dan op een Athlon64 3400+ @2.2Ghz... Zo af en toe is efficientie toch ook nog een belangrijke factor. (Zet een Athlon XP eens tegenover een destijds vergelijkbare P IV, dat zegt wel genoeg)"Wat maakt het nou uit dat je meerdere cores hebt? Als ze niet sneller worden, gaat het ook niet sneller!"
Het hoge percentage "Nee, software ondersteunt het toch niet" baart toch wel een beetje zorgen. Ik zie om me heen dat programmeurs nog steeds denken dat voor meerdere cores software bouwen onzin is of dat er geen vraag naar is. Blijkbaar is die vraag er toch wel, dus ik denk dat de programmeurs eens wakker moeten worden.
/u/220490/bombcut.png?f=community){kind=small}
Voor een hele zwik software maakt het ook helemaal niet uit of iets meerdere cores ondersteunt of niet en kan je er nauwelijks voordeel uit halen om iets te parallelliseren. De complexiteit kan er trouwens door toenemen wat weer andere problemen met zich meebrengt.
Een andere probleem is dat meerdere cores ook niet noodzakelijk altijd helpen bij het versnellen van bepaalde processen, je kan ook maar x MB per seconde lezen van je harde schijf, een extra core helpt daar helemaal niet.
Een veel belangrijker voordeel van multicore architecturen is dat verschillende applicaties echt in parallel kunnen lopen zonder elkaar te hinderen.
Tot slot zijn er ook al heel veel applicaties wel geschikt voor meerdere cores (vooral aan de serverzijde)
De software architecturen die daar gebruikt worden komen ook meer en meer naar de desktop. Denk aan allerhande applicatieservers die een doorgedreven thread model aanbieden. De microkernels die in deze applicatieservers zitten komen ook naar de desktop. Samen met een trend naar event en message gebaseerde architecturen die het multithreaden voor de applicatieprogrammeur vereenvoudigen. Het moeilijke multithreaden wordt immers onder de motorkap verstopt.
Eindgebruikers hebben ook niet altijd een correct beeld van hoe en welk voordeel meerdere cores hebben en kunnen hebben. En dat lijdt tot heel wat misvattingen met als gevolg statements dat programmeurs te dom zijn om goed voor meerdere cores te kunnen programmeren...
Een andere probleem is dat meerdere cores ook niet noodzakelijk altijd helpen bij het versnellen van bepaalde processen, je kan ook maar x MB per seconde lezen van je harde schijf, een extra core helpt daar helemaal niet.
Een veel belangrijker voordeel van multicore architecturen is dat verschillende applicaties echt in parallel kunnen lopen zonder elkaar te hinderen.
Tot slot zijn er ook al heel veel applicaties wel geschikt voor meerdere cores (vooral aan de serverzijde)
De software architecturen die daar gebruikt worden komen ook meer en meer naar de desktop. Denk aan allerhande applicatieservers die een doorgedreven thread model aanbieden. De microkernels die in deze applicatieservers zitten komen ook naar de desktop. Samen met een trend naar event en message gebaseerde architecturen die het multithreaden voor de applicatieprogrammeur vereenvoudigen. Het moeilijke multithreaden wordt immers onder de motorkap verstopt.
Eindgebruikers hebben ook niet altijd een correct beeld van hoe en welk voordeel meerdere cores hebben en kunnen hebben. En dat lijdt tot heel wat misvattingen met als gevolg statements dat programmeurs te dom zijn om goed voor meerdere cores te kunnen programmeren...
Dat klopt, maar vaak kun je een programma toch wel opsplitsen in zaken die op de voorgrond gebeuren en taken die op de achtergrond uitgevoerd worden. Zolang er nog geen multi-core processors in een computer zaten was het echter helemaal niet interessant om hier op te gaan laten.Voor een hele zwik software maakt het ook helemaal niet uit of iets meerdere cores ondersteunt of niet en kan je er nauwelijks voordeel uit halen om iets te parallelliseren.
Nu er meer en meer computers met meerdere cores komen wordt het een andere zaak en zal meer en meer software aangepast worden (bijvoorbeeld de spellingscontrole als een achtergrond taak).
Verder kan ik mij ook voorstellen dat bijvoorbeeld browsers uitstekend gebruik zouden kunnen maken van de extra cores die aanwezig zijn, zodat de ene webapplicatie de andere website/applicatie niet in de web zal zitten. Vooralsnog zijn de meeste browsers volgens mijn nog erg op slechts 1 core gericht...
Die splitsing tussen voorgrond taken en achtergrondtaken gebeurt al heel lang hoor. De GUI van een applicatie loopt altijd in een andere thread(meestal met hogere prioriteit) dan de eigenlijke logica. Indien dit niet zo zou zijn dan hangt je keihard vast iedere keer je op een knop klikt tot de actie geassocieerd met die knop helemaal uitgevoerd is.
Iets als een spellingscontrole gebeurt, vermoed ik, al helemaal op de achtergrond in een ander thread. Het zou zelfs moeilijker programmeren zijn om dat niet in een aparte thread te doen.
Ook browsers kunnen zonder problemen meerdere threads gebruiken om meerdere pagina's tegelijk te renderen. Maar heel veel voordeel merk je daar niet van.
De bottleneck is veel vaker iets anders, het netwerk bijvoorbeeld bij een browser.
En iets hierarchisch als een html-pagina in meerdere threads renderen is niet echt triviaal en de winst die je haalt echt minimaal (i.e. 50ms naar 30ms brengen levert je niet veel op naar gebruikerservaring)
Iets als een spellingscontrole gebeurt, vermoed ik, al helemaal op de achtergrond in een ander thread. Het zou zelfs moeilijker programmeren zijn om dat niet in een aparte thread te doen.
Ook browsers kunnen zonder problemen meerdere threads gebruiken om meerdere pagina's tegelijk te renderen. Maar heel veel voordeel merk je daar niet van.
De bottleneck is veel vaker iets anders, het netwerk bijvoorbeeld bij een browser.
En iets hierarchisch als een html-pagina in meerdere threads renderen is niet echt triviaal en de winst die je haalt echt minimaal (i.e. 50ms naar 30ms brengen levert je niet veel op naar gebruikerservaring)
Je zult nog verbaast staan bij de hoeveelheid single-threading applicaties die je gebruikt. Dat je dit niet merkt, dat komt omdat de uitgevoerde taken vaak erg klein zijn.Die splitsing tussen voorgrond taken en achtergrondtaken gebeurt al heel lang hoor. De GUI van een applicatie loopt altijd in een andere thread(meestal met hogere prioriteit) dan de eigenlijke logica. Indien dit niet zo zou zijn dan hangt je keihard vast iedere keer je op een knop klikt tot de actie geassocieerd met die knop helemaal uitgevoerd is.
Zolang je nog maar zorgt dat de taak die je uitvoer minder dan 250msec duurt (oid, soms kun je 'm zelfs wel 1 seconde of meer laten duren), zal de gebruiker er niets van merken.
Ik denk dat je je niet beseft hoe lastig het is om een multithreaded applicatie te programmeren. Het lijkt misschien erg gemakkelijk, maar ik kan je zeggen dat het lastiger is dan je op het eerste gezicht zou zeggen.Iets als een spellingscontrole gebeurt, vermoed ik, al helemaal op de achtergrond in een ander thread. Het zou zelfs moeilijker programmeren zijn om dat niet in een aparte thread te doen.
De browser wordt meer en meer als applicatieplatform gebruikt met client-side JavaScript, het opdelen van de taken die de browser uitvoert is dus wel degelijk lonend. Als zou je de applicatie al zodanig opdelen dat iedere tab/venster een eigen thread krijgt, voor zover ik weet is dat nu namelijk nog niet zo.Ook browsers kunnen zonder problemen meerdere threads gebruiken om meerdere pagina's tegelijk te renderen. Maar heel veel voordeel merk je daar niet van.
De bottleneck is veel vaker iets anders, het netwerk bijvoorbeeld bij een browser.
En iets hierarchisch als een html-pagina in meerdere threads renderen is niet echt triviaal en de winst die je haalt echt minimaal (i.e. 50ms naar 30ms brengen levert je niet veel op naar gebruikerservaring)
Je hebt overigens wel gelijk dat het parsen van HTML niet iets is dat je over meerdere threads moet gaan verdelen, maar dat heb ik ook helemaal niet voorgesteld
/u/92525/me.png?f=community){kind=small}
Aan de andere kant valt het ook wel weer mee. Zodra je een beetje gevoel begint te krijgen voor alle moderne threading primitieven die een moderne concurrency library je biedt EN je niet al te gekken dingen doet dan valt het echt best mee.Ik denk dat je je niet beseft hoe lastig het is om een multithreaded applicatie te programmeren. Het lijkt misschien erg gemakkelijk, maar ik kan je zeggen dat het lastiger is dan je op het eerste gezicht zou zeggen.
Je moet niet enkel met een Process of Thread werken en lukraak al je data sharen en dat op een lukrake en chaotische manier. Maak je echter slim gebruik van dingen als barriers, blocking queue's, (timed) reentrant locks EN laat je je threads eenvoudige goed gedefinieerde taken uitvoeren met het liefst een sporadische communicatie dan is het echt niet zo moeilijk.
De grap is dat veel van de principes die je gebruikt om parallel te programmeren dezelfde zijn die je ook al zou moeten toe passen bij sequentieel programmeren. De OO principes low coupling, high cohesion zijn hier uit stekend van toepassing.
:strip_exif()/u/114480/flatter.gif?f=community){kind=small}
Volgens mij gebruikt IE7 iets wat wel redelijk op 1-thread-per-tab lijkt, alleen je merkt gelijk dat IE7 sloom is met het openen van een tab. Firefox en Opera gebruiken voor zover ik weet verschillende threads per onderdeel (ie: thread userinterface, thread netwerk, thread javascript etc). Overigens zijn de threads van IE7 waarschijnlijk vooral informatiecontainers als het ware, waarbij vervolgens het renderen etc weer word doorgegeven aan een centrale renderthread. Hierdoor zou IE7 minder crashgevoelig moeten zijn (als 1 tab crashed zou de rest moeten blijven bestaan), maar ik merk persoonlijk nogal duidelijk dat het extra tijd kost om een tab te openen.
Is misschien nogal taalafhankelijk, maar in Delphi kan ik gewoon code aan een knop hangen die behoorlijk lang duurt. Zolang ik zo af en toe maar application.processMessages uitvoer om de GUI even te updaten merkt de gebruiker daar echt niets van.De GUI van een applicatie loopt altijd in een andere thread(meestal met hogere prioriteit) dan de eigenlijke logica. Indien dit niet zo zou zijn dan hangt je keihard vast iedere keer je op een knop klikt tot de actie geassocieerd met die knop helemaal uitgevoerd is.
1985: Voor een hele zwik software maakt het ook helemaal niet uit of iets meer dan 512k ondersteunt of niet en kan je er nauwelijks voordeel uit halen om iets meer geheugen te geven.Voor een hele zwik software maakt het ook helemaal niet uit of iets meerdere cores ondersteunt of niet en kan je er nauwelijks voordeel uit halen om iets te parallelliseren
1990: Voor een hele zwik software maakt het ook helemaal niet uit of iets OO geschreven is of niet en kan je er nauwelijks voordeel uit halen om iets in objecten te definiëren.
1995: Voor een hele zwik software maakt het ook helemaal niet uit of iets een GPU ondersteunt of niet en kan je er nauwelijks voordeel uit halen om iets door de grafische kaart af te laten handelen.
2000: Voor een hele zwik software maakt het ook helemaal niet uit of iets meerdere resoluties ondersteunt of niet en kan je er nauwelijks voordeel uit halen om iets op een hogere resolutie dan 1024x768 te draaien.
...
Als het aan jou lag zaten we nog op een 7Mhz 68000 te werken...
:strip_exif()/u/1658/elmuerte-avatar60.gif?f=community){kind=avatar}
Die hoort niet in het rijtje thuis, win ik nu iets?1990: Voor een hele zwik software maakt het ook helemaal niet uit of iets OO geschreven is of niet en kan je er nauwelijks voordeel uit halen om iets in objecten te definiëren.
Alle andere hebben namelijk iets met technische beperkingen te maken.
Het heeft er losjes mee te maken, maar vanaf de andere kant gezien, namelijk vanaf de programmeur. In 1990 was er een vrij grote groep programmeurs die vond dat OO niet nodig was voor 'gewone' programma's en dat alleen hele grote enorm gecompliceerde applicaties er voordeel uit zouden kunnen halen. Men dacht dat OO alleen maar nodeloze complexiteit zou brengen en de kans op fouten zou verhogen.Die hoort niet in het rijtje thuis, win ik nu iets?
Ondertussen weten we natuurlijk wel beter. Zelfs voor de meest eenvoudige programma's is dikwijls OO de default methode.
Je ziet dat nu weer (vanaf de programmeurs kant) het zelfde argument wordt gebruikt. Parallel programmeren is niet nodig. Alleen hele complexe apps hebben het nodig etc.
Ik ben professioneel bezig met onderzoek naar gedistribueerde software, dus ik zal de laatste zijn om te beweren dat parallelisatietechnieken en optimalisaties voor multicore systemen niet nodig zijn.Je ziet dat nu weer (vanaf de programmeurs kant) het zelfde argument wordt gebruikt. Parallel programmeren is niet nodig. Alleen hele complexe apps hebben het nodig etc.
Waar ik echter vooral op wou reageren is dat niet alles zomaar te paralleliseren is, en het ook niet altijd nuttig is om dat te doen. Echter, de support voor multicore of gedistribueerde systemen wil je transparant maken voor de applicatieprogrammeur. denk maar aan JEE en andere applicatieservers.
Persoonlijk denk ik ook dat er weer een nieuw ontwikkelmodel moet opgebouwd worden om het gebruik van meerdere cores te vereenvoudigen, en moet die taak niet bij de applicatieprogrameur gelegd worden. Ik denk dan vooral aan een asynchroon applicatiemodel (vb. zoals een JAIN SLEE applicatie server)
Heel rekenintensieve taken (bv. encoderen van video, renderen van 3d modellen, statistische analyse van data, bepaalde simulaties...) hebben vermoedelijk meer baat bij specifiek ontwikkelde algoritmen. Maar die komen dan in allerhande bibliotheken terecht en blijven verborgen voor applicatieprogrammeurs.
Waar ik me soms alleen aan stoor (en vandaar mijn eerste reactie) zijn kreten dat programmeurs maar eens rekening moeten houden met meerdere cores. Vroeger gingen de discussies over een beter sorteer algoritme, nu over het gebruik van meerdere cores. Dit waar in 99% van de gevallen de sorteerfunctie van de standaard bibliotheek die je gebruikt al meer dan voldoende is. Hetzelfde bij huidige software met ondersteuning van meerdere cores. Iedereen zijn eigen oplossing laten maken is geen goede taktiek naar mijn gevoel. De oplossing in bibliotheken of allerhande applicatieservers te stoppen wel. En afgeslankte vormen van zo'n applicatieservers komen ook steeds meer naar de desktop. (bv. OSGi)
Inderdaad, maar dat geldt natuurlijk voor heel veel dingen.Waar ik echter vooral op wou reageren is dat niet alles zomaar te paralleliseren is, en het ook niet altijd nuttig is om dat te doen.
Als we alleen even kijken naar threads als organisatie unit in je software en daarna de vergelijking maken met organisatie units in het algemeen, dan zie je dat dat statement voor elke unit geldt. Het begint al bij het concept statement. Een statement kun je soms apart opdelen in meerdere statements, maar dat is niet altijd zinvol. Zelfde voor het concept functie. Heel handig, maar je gaat niet elke lijn code in een aparte functie zetten. Deze lijn gaat door naar classes, packages en jars/dlls/libs etc.
Specifiek voor threads geldt dat niet elk algoritme (zinvol) te paralleliseren is. Er is niet voor niets onderzoek naar welke algorithmen wel goed te paralleliseren zijn
Maargoed, hele simpele programma's kunnen nou eenmaal niet multthreaded gebeuren. Het gebeurd vaak genoeg dat als je een lijstje doorloopt dat je de al verwerkte informatie nodig hebt. Het zou sowieso nogal belachelijk zijn om dat soort dingen op te delen in verschillende threads, de overhead die bij die thread komt kijken is vele malen hoger dan het voordeel dat je haalt doordat je 2 threads hebt die allebei maar de helft hoeven. Alleen bij grotere databrokken of stappen in een programma die niet op elkaar hoeven te wachten loont het om te gaan splitsen in threads, dat kan nog best vaak zijn. Zo heeft over het algemeen de grafische interface weinig aan wachten op berekeningen, een vastlopende interface heeft immers niemand wat aan. Maar wat bijvoorbeeld een commando als 'ls' of 'man' (unix) met threads zou moeten is mij een raadsel.
Over het algemeen kun je wel stellen dat OO een veel breder inzetbaar concept is dan het idee van meerdere paralelle berekeningen.
Over het algemeen kun je wel stellen dat OO een veel breder inzetbaar concept is dan het idee van meerdere paralelle berekeningen.
Ach... ik vermaak me nog steeds als ik mijn Sega Megadrive weer eens aansluitAls het aan jou lag zaten we nog op een 7Mhz 68000 te werken...
Ik vind het altijd zo grappig dat iedereen altijd alleen maar kijkt naar het verdelen van de werklast van 1 programma over meerdere cores. Voor een consument als ik is het juist interessant als verschillende programma's op verschillende cores (threads) draaien zodat alles gewoon lekker snel blijft lopen.
Bv. ik ben momenteel wat video aan het coderen, Warcraft, outlook, word, powerpoint, Itunes en virusscanner staat open. Een aantal van deze apps vraagt vrij veel bronnen, dan vind ik het erg prettig dat je overal snel tussen kan schakelen en dat je geen noemenswaardige vertraging tegenkomt.
Mijn quadcore + 4gb + vista 64 zorgen er voor dat ik dit alles gewoon zonder problemen kan doen. Als ik ook even naar de CPU load kijk, dan zie ik 1 core voor 70% vol, 2 voor ongeveer 50% en 1 op 20%. Dus kom niet aan met het verhaal dat het nu nog geen zin heeft of dat de programmeurs wakker moeten worden. Ik ben wel van mening dat het verspreiden van 1 enkele huis-tuin-en-keuken applicatie over meerdere cores vrij nutteloos is.
Bv. ik ben momenteel wat video aan het coderen, Warcraft, outlook, word, powerpoint, Itunes en virusscanner staat open. Een aantal van deze apps vraagt vrij veel bronnen, dan vind ik het erg prettig dat je overal snel tussen kan schakelen en dat je geen noemenswaardige vertraging tegenkomt.
Mijn quadcore + 4gb + vista 64 zorgen er voor dat ik dit alles gewoon zonder problemen kan doen. Als ik ook even naar de CPU load kijk, dan zie ik 1 core voor 70% vol, 2 voor ongeveer 50% en 1 op 20%. Dus kom niet aan met het verhaal dat het nu nog geen zin heeft of dat de programmeurs wakker moeten worden. Ik ben wel van mening dat het verspreiden van 1 enkele huis-tuin-en-keuken applicatie over meerdere cores vrij nutteloos is.
/u/100974/SunbeamTech%2520logo%2520avatar.png?f=community){kind=avatar}
Ik heb een Dual core E8400 om de volgende reden.
De huidige games gebruiken hooguit 2 cores en 4 cores worden nog in geen enkel spel goed benut.
Mischien in Crysis een quadcore support maar om nou voor één spel een quadcore te kopen...
Volgens The Inquirer (oké ik weet het roddel website ) is er voorlopig ook geen quadcore game op de markt.
Quadcore is denk ik meer geschikt voor als je gaat Fotoshoppen of 3D design software gaat gebruiken zoals 3DsMax of Maya.
De huidige games gebruiken hooguit 2 cores en 4 cores worden nog in geen enkel spel goed benut.
Mischien in Crysis een quadcore support maar om nou voor één spel een quadcore te kopen...
Volgens The Inquirer (oké ik weet het roddel website
) is er voorlopig ook geen quadcore game op de markt.Quadcore is denk ik meer geschikt voor als je gaat Fotoshoppen of 3D design software gaat gebruiken zoals 3DsMax of Maya.
[Reactie gewijzigd door Sunbeam-tech op 2 augustus 2024 18:57]
:strip_icc():strip_exif()/u/18339/rem.jpg?f=community){kind=small}
Er draait altijd vanalles op een PC. Al ondersteunt het spel maar twee cores, dan zijn er nog altijd twee cores over die beschikbaar zijn voor andere taken. Je hebt een virusscanner/firewall/messenger, misschien ben je nog iets aan het downloaden.
Beter verlegen met, dan verlegen om vind ik zelf.
Beter verlegen met, dan verlegen om vind ik zelf.
Grid gebruikt mij toch regelmatig alle cores, dat zie ik tenminste op mijn g15 toetsenbord, maar supreme commander gebruikt ze allemaal evenveel, bij grid wisselt het gebruik tussen de cores maar het is toch te zien dat het gebeurt.
Lol "volgens de Inquirer" ...eh had je gezien dat dat bericht alweer 2 jaar oud is? 
Dalijk met FarCry 2 en de nwe C&C heb je op zeker meer aan Quadcore and zo is het ook al met de A.I. core van Crysis.
Dalijk met FarCry 2 en de nwe C&C heb je op zeker meer aan Quadcore and zo is het ook al met de A.I. core van Crysis.
Wederom blijft mijn stem hier blanco?.
Waar is de optie: Nee ik heb het niet nodig?
Ik stress mijn pc alleen met af en toe encoden en decoden(ik doe veel met anime), daar heb ik echt geen quadcore voor nodig. Dat beetje wachten kan best.
@redactie: Wanneer komen er nou eens redelijke polls(NIET "op welke game wacht jij" er komen er namelijk honderden), Maar polls als deze, maar dan die rekening houden met het feit dat er ook mensen zijn die niet altijd het nieuwste willen. Dat is vermoed ik nog steeds een grote groep hier.
Door fouten als deze zijn jullie polls op geen enkele manier representatief voor de tweakers-gemeenschap. Ik stem niet, maar heb wel een stem. Die wordt gewoon gemist. Waardoor toch zeker minimaal 20% afwijking zit in de resultaten van de poll. Als iedereen voor dezelfde keuze kiest als ik, die mijn mening deelt.
Waar is de optie: Nee ik heb het niet nodig?
Ik stress mijn pc alleen met af en toe encoden en decoden(ik doe veel met anime), daar heb ik echt geen quadcore voor nodig. Dat beetje wachten kan best.
@redactie: Wanneer komen er nou eens redelijke polls(NIET "op welke game wacht jij" er komen er namelijk honderden), Maar polls als deze, maar dan die rekening houden met het feit dat er ook mensen zijn die niet altijd het nieuwste willen. Dat is vermoed ik nog steeds een grote groep hier.
Door fouten als deze zijn jullie polls op geen enkele manier representatief voor de tweakers-gemeenschap. Ik stem niet, maar heb wel een stem. Die wordt gewoon gemist. Waardoor toch zeker minimaal 20% afwijking zit in de resultaten van de poll. Als iedereen voor dezelfde keuze kiest als ik, die mijn mening deelt.
[Reactie gewijzigd door Verwijderd op 25 juli 2024 14:18]
Tsja, om Slashdot.org aan te halen: "Don't complain about lack of options. You've got to pick a few when you do multiple choice. Those are the breaks."
Dat is nu eenmaal het nadeel van meerkeuze. Via het commentaar kun je altijd nog je ei kwijt...
Nu is een 'Anders dan hierboven' misschien een optie, maar aan de andere kant is zo'n pool slechts indicatief en is het geen opiniepeiling of dergelijke - uitslagen van dit soort pools moet je denk ik altijd met een korreltje zout nemen.
Je werkt ten slotte toch ook niet meer op een Pentium 1 op 133Mhz toch? Heel lang was de vooruitgang een snellere CPU, maar dat is niet meer te behalen en nu wordt de load over meerdere cores verspreid...
Dat is nu eenmaal het nadeel van meerkeuze. Via het commentaar kun je altijd nog je ei kwijt...
Nu is een 'Anders dan hierboven' misschien een optie, maar aan de andere kant is zo'n pool slechts indicatief en is het geen opiniepeiling of dergelijke - uitslagen van dit soort pools moet je denk ik altijd met een korreltje zout nemen.
Ik neem aan dat je gebruik maakt van Windows of een ander multi-tasking besturingssysteem. In dat geval is het altijd handig om meerdere cores te hebben, de diverse taken hoeven dan niet allemaal dezelfde core te delen.Waar is de optie: Nee ik heb het niet nodig?
Je werkt ten slotte toch ook niet meer op een Pentium 1 op 133Mhz toch? Heel lang was de vooruitgang een snellere CPU, maar dat is niet meer te behalen en nu wordt de load over meerdere cores verspreid...
Maar dit is een zeer logische optie lijkt mij.
Daarbij is een dualcore meer dan genoeg zolang je geen hardcore encoder, photoshopper(en zulks) of gamer bent.
Daarbij is een dualcore meer dan genoeg zolang je geen hardcore encoder, photoshopper(en zulks) of gamer bent.
/u/117288/crop571551e420663.png?f=community){kind=small}
Je hoeft niet te stemmen als je vindt dat jouw mening er niet tussen staat.
Je loopt de dure computerzaak toch ook gewoon voorbij richting de goedkope of ga je binnen klagen over de prijzen?
Je loopt de dure computerzaak toch ook gewoon voorbij richting de goedkope of ga je binnen klagen over de prijzen?
/u/167420/glimlach.png?f=community){kind=small}
Ik heb gestemd op "Ik wacht liever op acht of meer cores". Ik heb sinds ongeveer anderhalf jaar een dual core (Core 2 Duo E6400 niet overgeklokt) en vind hem nog voldoen voor mijn wensen. Denk dan ook niet dat ik binnenkort een nieuwe processor zal aanschaffen. Anderhalf jaar geleden werd dual core ook niet zo goed ondersteund, maar meer cores is momenteel wel de toekomst. Wat ik dus gewoon aanneem is dat de software wel komt. Zo wordt dual core nu al aardig ondersteund. Ik verwacht dat dat ook bij quad core zal zijn. Of mijn volgende cpu ook echt een CPU met 8 cores wordt of meer wordt zou ik niet zo kunnen zeggen, wellicht komen er namelijk ook CPU's met 5, 6 of 7 cores. Dat klikt misschien gek, maar kijk maar naar de triple cores van AMD. Ik heb dus niet echt behoefte aan een nieuwe CPU en zal dus wel even kunnen wachten.
[Reactie gewijzigd door Regeneration op 2 augustus 2024 18:57]
:strip_icc():strip_exif()/u/193469/Popcorn1.jpg?f=community){kind=small}
Zelfde verhaal hier, ook een E6400 1.5 jaar geleden aangeschaft.. Hij is wel overclockt (3Ghz) en klokt alles naar wens. Ik heb geen behoefte nog niet om geld uit te geven aan een nieuwe processor, dual-core does the job.
:strip_exif()/u/1165/thunk.gif?f=community){kind=small}
Daarbij komt nog, er bestaan daadwerkelijk maar vier corrs!
:strip_exif()/u/91615/hann1bal.gif?f=community){kind=small}
Ik ben het met je eens dat een gemiddelde consument net als jij (en ik) eigenlijk voorlopig niet meer nodig heeft dan een dualcore CPU. Het is echter niet zo dat je anderhalf jaar geleden weinig aan je dualcore had omdat het niet werd ondersteund. Windows (bijv.) ondersteunt het al meerdere versies en met dual core heb je altijd het voordeel dat je 1 core compleet kunt gebruiken voor een programma en daarnaast nog allerlei andere zaken kunt draaien zonder dat je het als traag ervaart.
Zo heb ik vaker video gecodeerd met software wat maar op 1 core draaide. Het zorgde er wel voor dat ik op geen enkele wijze het gevoel had dat mijn pc ook maar iets trager werd tjdens die uren, toen ik er office applicaties op draaide en aan het internetten was. Dat is toch wel echt een groot voordeel. Dat voordeel is niet meer zo groot als het aantal cores nog meer toeneemt en daar maak je een goed punt zolang de ondersteuning bij software nog niet altijd even goed doordringt.
Zo heb ik vaker video gecodeerd met software wat maar op 1 core draaide. Het zorgde er wel voor dat ik op geen enkele wijze het gevoel had dat mijn pc ook maar iets trager werd tjdens die uren, toen ik er office applicaties op draaide en aan het internetten was. Dat is toch wel echt een groot voordeel. Dat voordeel is niet meer zo groot als het aantal cores nog meer toeneemt en daar maak je een goed punt zolang de ondersteuning bij software nog niet altijd even goed doordringt.
Heb het waarschijnlijk niet helemaal goed verwoord, maar waarop ik eigenlijk doelde was de optie "Nee, software ondersteunt het toch niet". Dat kan namelijk wel zo zijn maar op een gegeven moment komt de software ondersteuning ook wel, zo is mijn gedachte in ieder geval. Ik koop een PC met als voor meerdere jaren en als daarvan het eerste jaar niet helemaal optimaal van je nieuwe hardware kan gebruiken dan neem ik dan voor lief. Zo bedoelde ik het meer.
5,6 en 7 cores lijken me wel erg sterk. Dat wordt een gekkenhuis voor de consument... Denk dat ze het dat eerder doen zoals dat bij een octocore een core kapot is ze er zescore van makken dan krijg je dus single, duo, quad, zes en octo's. Denk dat tegen die tijd de single ook wel gaat verdwijnen en je in het vervolg alles in machten van 2 krijgt en telkens eventueel de helft die er tussenin zit.
en de amd tripple-core dan
:strip_icc():strip_exif()/u/85308/mirko.jpg?f=community){kind=small}
Dat is een defecte quadcore. Of deze nou slecht uit de produktie is gekomen of express kapot gemaakt, doet er even niet toe.
/u/145971/logotnet.png?f=community){kind=small}
Zowel AMD als Intel zijn bezig met 6-core CPU's.
/u/136818/2dt252w.png?f=community){kind=small}
Mijn volgende PC wordt een notebook, en daarin zitten helaas nog geen quadcores. Ik overweeg er wel eentje voor mijn server, maar ik heb momenteel in verband met drukte daar nog geen tijd voor 
Als je op korte termijn (bijna een jaar of zo) een laptop koopt, dan is de kans klerin dat je er 1 met een quadcore CPU kan kiezen.Mijn volgende PC wordt een notebook, en daarin zitten helaas nog geen quadcores.
Over een jaar of 2 verwacht ik die keus wel (betaalbaar), ik denk dat het nog te energieintentsief is om nu al een quadcore in te bouwen in een laptop - maar als je geduld hebt...
Ik denk vooral dat warmte productie in combinatie met energieverbruik het grootste probleem is, ook zullen ontwikkelkosten en een kleine afzet markt hun aandeel hebben.
Waarom zou je dan een quad core willen aanschaffen? Omdat het meer preformance geeft!. Maar aangezien dit ten kosten gaat van de batterij duur, het maar door een paar applicaties goed ondersteunt word en het stukken duurder is zou niemand het aanschaffen.
Conclusie: Quad core word te weinig ondersteunt, daarom is het niet nog net rendabele om het te ontwikkelen voor notebooks. Ook al zou het Technisch mogelijk zijn.
Waarom zou je dan een quad core willen aanschaffen? Omdat het meer preformance geeft!. Maar aangezien dit ten kosten gaat van de batterij duur, het maar door een paar applicaties goed ondersteunt word en het stukken duurder is zou niemand het aanschaffen.
Conclusie: Quad core word te weinig ondersteunt, daarom is het niet nog net rendabele om het te ontwikkelen voor notebooks. Ook al zou het Technisch mogelijk zijn.
:strip_exif()/u/37551/tonque.gif?f=community){kind=small}
Ik zit er inderdaad aan te denken. Ik heb nu een AMD 3700+ en haal 1,8 Fps met het encoderen van h.264 720p video's. Met een huidige intel quadcore haal je ruim 8 Fps, dat noem ik het overwegen zeker waard
Ik heb Nee, de software ondersteund het toch niet gestemd maar voor mij zou: Nee, want ik heb het niet nodig beter zijn. Ik kan met een beetje passen en meten nog op een Pentium 3 kunnen werken, dus met mijn E2180 ben ik wel tevreden. Misschien nog een overklokje, en dan is het wel goed. En de meeste software die ik gebruik ondersteund het ook niet, dus het is ook niet zo nuttig. Maar mijn volgende PC wordt wel een quadcore waarschijnlijk, of eentje met meer cores, ligt aan de prijs, energieverbruik en wanneer ik een nieuwe bouw.
[Reactie gewijzigd door Facepalm op 2 augustus 2024 18:57]
/u/9258/killbill.png?f=community){kind=small}
Software ondersteunt het misschien niet maar windows ondersteunt het wél en die kan heel mooi applicaties toewijzen aan cores waardoor je het dus wel merkt. Zeker met veel programma's tegelijk open.
Ik heb dus gestemd voor hoe meer hoe beter.
Ik heb dus gestemd voor hoe meer hoe beter.
:strip_exif()/u/10069/neutron1.gif?f=community){kind=small}
Ik heb al een quadcore, een Core 2 Extreme QX6850. Destijds gekocht, mede om gewoon op de toekomst te zijn voorbereid. Momenteel beginnen steeds meer games multicore te ondersteunen, daarnaast encode ik regelmatig DVD9 naar DVD5 met CCE en dan is het ook erg handig
WinRAR is tegenwoordig ook leuk als ik iets eens echt wil inpakken: multicore support
En voor de Nederlandse Kracht Koeien is quadpower ook handig: mijn SETI@Home graast op vier weides tegelijkertijd
WinRAR is tegenwoordig ook leuk als ik iets eens echt wil inpakken: multicore support
En voor de Nederlandse Kracht Koeien is quadpower ook handig: mijn SETI@Home graast op vier weides tegelijkertijd
[Reactie gewijzigd door Wildfire op 2 augustus 2024 18:57]
Op dit item kan niet meer gereageerd worden.