Intels nästa prestandaprocessor testad

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av gosh
när det diskuterats fps och hur många ögat klarar av och observera så har en del påstått att de kan se skillnad på 50 fps eller mer.
enligt mig så kan man inte det. även att det skiljer en del från spel till spel hur många fps som det fungerar och spela i.
det kan ju faktiskt vara så att 50 fps inte är 50 frames jämnt fördelade under sekunderna och därför så uppfattar man att det går och se skillnader på 50 fps.
även att spel som går jämnt men som kräver mindre fps kanske inte har flaskhalsar utan grafiken är relativt jämn. då blir det spelet eventuellt spelbart på mycket lägre fps.
en del påstår till och med att de kan se skillnader på långt över 100 fps. men om ett spel har en dipp någon gång under spelet och "hoppar över" 5-6 frames så borde det gå och uppfatta.

fps är inte antal bilder för just den sekunden utan hastigheten just då, det är inte så att 50 fps är 46 fps halva sekunden och 4 fps andra halvan , ifall det hoppar ner till 4 kommer det stå 4 fps .

Mvh

Visa signatur

Meshilicious, Amd 7950X3D, Asus X670E-I ,96 GB DDR5 6000,RTX4090 FE, Corsair 2TB m.2 / 4TB, Samsung 57" G9

Permalänk
Avstängd
Citat:

Ursprungligen inskrivet av gosh
Jag gör ett sedan i C++, ingen VB här inte
bra att veta assemblerkoden för att förstå vad som händer

Du sa att du var programmerare och ser inte att detta inte är Visual Basic

Permalänk
Avstängd
Citat:

Ursprungligen inskrivet av dundermuppen
Du sa att du var programmerare och ser inte att detta inte är Visual Basic

såg bara .bas

basic är inget språk, det är ett skämt

Citat:

Ursprungligen inskrivet av Palme_570
fps är inte antal bilder för just den sekunden utan hastigheten just då

Jo men du måste ändå alltid ta ut någon form av genomsnitt. nu använder man sekunder för att få ett genomsnitt. skulle du ta tidsinvervallet som är så extremt litet att det endast får plats några klockcykler så blir det 0 F/X ns (X = någon siffra), med litet tur så får man 1 F/X ns

Visa signatur

Programmerare med C++ som huvudspråk.

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av gosh
Jo men du måste ändå alltid a ut någon form av genomsnitt. nu använder man sekunder för att få ett genomsnitt. skulle du ta tidsinvervallet som är så extremt litet att det endast får plats några klockcykler så blir det 0 F/X ns (X = någon siffra), med litet tur så får man 1 F/X ns

Skulle kalla det hastighet inte genomsnitt 100 km/h är inte direkt ett genomsnitt utan en hastighet om hastigheten skjunker på mätarn då ser man det samma sak med fps om det får för sig att skjunka 0.1 fps så syns de på mätaren.

Visa signatur

Meshilicious, Amd 7950X3D, Asus X670E-I ,96 GB DDR5 6000,RTX4090 FE, Corsair 2TB m.2 / 4TB, Samsung 57" G9

Permalänk
Avstängd
Citat:

Ursprungligen inskrivet av gosh

basic är inget språk, det är ett skämt

Verktyget är väl mindre intressant än resultatet. Jag kunde skrivit programmet i ett flertal andra språk, men jag valde powerbasic eftersom det går snabbt och livslängden på projektet kunde räknas i timmar.

Din inställning ger ett något onyanserat intryck.

Du noterade väl förresten att tiden det tog att göra körningarna inte ökade med antalet trådar? Jag ändrade förresten kopieringsrutinen så att den kopierade slumpmässigt istället för linjärt, den uppförde sig likadant som innan.

Nästa test så ska jag ta ett litet minnesblock på kanske 2 MB och låta alla trådar läsa och skriva i det samtidigt, men det får bli imorgon. Då borde det få plats i cachen och framtvinga synkroniseringar över fsb.

Permalänk
Medlem

Ska bli intressant att se resultaten, jobba på dundermuppen.

Permalänk

Är det ingen som reagerat på att snubben i forumet som klagar på att FSB flaskar sitter på en Q6600, som har original FSB på 266MHz och att han kör med de kraftigaste grafikkorten som finns att köpa just nu, GTX 280, i SLI.

När han märker skillnad går han från 266MHz till 333MHz (vilket de nyare processorerna kör på default) på FSB. I och med att han ökar FSB ökar han ju även processorns klockfrekvens (om han inte samtidigt sänker multipeln, vilket inte framgår att han gör).

Det är lite svårt att utläsa om hans resultat beror på överklockning av processorns klockfrekvens, eller om 266MHz i FSB flaskar 2st GTX 280 i SLI.

Om det beror på överklockning, så är det förmodligen inte FSB som är boven. Om det är FSB som faktiskt drar ned prestandan, så bör man ha lite mer test för att se om även en processor med FSB på 333MHz flaskas av FSB och i så fall kolla om det krävs två GTX 280 i SLI innan effekten är märkbar.

Jag menar, om det krävs 2 GTX 280 i SLI innan FSB är en begränsning, så känns det rätt grönt för en vanlig gamer, för det tar ett tag innan gemene man sitter på den grafikprestandan och när folk gör det, så är det förmodligen ändå dags att köpa ny processor.
Det framgår ju inte heller om det finns någon annan processor som i dagsläget levererar bättre prestanda och om denna processor i så fall är en Intel- eller AMD-processor. Det känns helt enkelt som om det behövs rejäla tester innan man kan bekräfta eller förkasta teorin med FSB-begränsning.

Om FSB är en begränsning, skulle det vara trevligt med lite mer fakta som säger i vilka sammanhang detta kan märkas, så att man vet om detta kommer vara något som behöver påverka ens köpval. Dvs om man skall vänta med nya processorinköp tills det finns kraftfullare processorer att tillgå (Nehalem och bulldozer), eller om prestandan räcker till ett tag till med det processorutbud som finns i dagsläget.

PS. om någon känner för att diskutera detta resonemang, så citera gärna hela inlägget, inte bara en mening eller två. Det blir så tråkigt om man hakar upp sig på en enskild formulering och inte hela resonemanget. Tack DS.

Edit: såg just att trådskaparen och testkillen inte var en och samma person. Testkillen satt på 8800GTX OC och om den begränsas av FSB, så är det värre. Ja, ja time and test will tell...

Visa signatur

~Pelle~

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av WrongTarget
Är det ingen som reagerat på att snubben i forumet som klagar på att FSB flaskar sitter på en Q6600, som har original FSB på 266MHz och att han kör med de kraftigaste grafikkorten som finns att köpa just nu, GTX 280, i SLI.

När han märker skillnad går han från 266MHz till 333MHz (vilket de nyare processorerna kör på default) på FSB. I och med att han ökar FSB ökar han ju även processorns klockfrekvens (om han inte samtidigt sänker multipeln, vilket inte framgår att han gör).

Det är lite svårt att utläsa om hans resultat beror på överklockning av processorns klockfrekvens, eller om 266MHz i FSB flaskar 2st GTX 280 i SLI.

Om det beror på överklockning, så är det förmodligen inte FSB som är boven. Om det är FSB som faktiskt drar ned prestandan, så bör man ha lite mer test för att se om även en processor med FSB på 333MHz flaskas av FSB och i så fall kolla om det krävs två GTX 280 i SLI innan effekten är märkbar.

Jag menar, om det krävs 2 GTX 280 i SLI innan FSB är en begränsning, så känns det rätt grönt för en vanlig gamer, för det tar ett tag innan gemene man sitter på den grafikprestandan och när folk gör det, så är det förmodligen ändå dags att köpa ny processor.
Det framgår ju inte heller om det finns någon annan processor som i dagsläget levererar bättre prestanda och om denna processor i så fall är en Intel- eller AMD-processor. Det känns helt enkelt som om det behövs rejäla tester innan man kan bekräfta eller förkasta teorin med FSB-begränsning.

Om FSB är en begränsning, skulle det vara trevligt med lite mer fakta som säger i vilka sammanhang detta kan märkas, så att man vet om detta kommer vara något som behöver påverka ens köpval. Dvs om man skall vänta med nya processorinköp tills det finns kraftfullare processorer att tillgå (Nehalem och bulldozer), eller om prestandan räcker till ett tag till med det processorutbud som finns i dagsläget.

PS. om någon känner för att diskutera detta resonemang, så citera gärna hela inlägget, inte bara en mening eller två. Det blir så tråkigt om man hakar upp sig på en enskild formulering och inte hela resonemanget. Tack DS.

Edit: såg just att trådskaparen och testkillen inte var en och samma person. Testkillen satt på 8800GTX OC och om den begränsas av FSB, så är det värre. Ja, ja time and test will tell...

Citerar mig själv ur en annan tråd med fsb tjafset

Tog mig nu lite tid att lite upp crossfire test med phenom

Mother Board Asus M3A32-MVP Deluxe Wi-Fi, Asus Crosshair II Formula
CPU AMD Phenom X4 9850 Black Edition
Video Card Various
Memory Corsair XMS Dominator 2GB
Hard Drive Western Digital Raptor
Case Tsunami Thermaltake
Display Samsung 20" LCD Westinghouse W4207

resultatet

bättre skalning än intel ? nej . Hade vi därimot höjt cpu frekvensen hade vi sett bättre skalning så fsb är inte flaskhals

svaret på frågan när han höjer cpu frekvensen då kan processorn driva gpusen bättre.

om vi säger att tex man går 12000p i 3dmark 06 med standard frekvens och 14000 med två kort om man höjer fsb sänker multi kanske 300 poäng i ökning max pga minnes bandbredd , höjer han frekvensen till 3,6 - 4ghz på en quad får han 20k
För att utnyttja två gpus till fullo KRÄVS en clockad cpu det är bland annat därför det sälj fabriks clockade datorer typ alienware / hp mm.

Det finns fullt med AMD vs INTEL tester och faktum står sig fsb falskar inte så core2 kör över dem.

FSB är alltså INGEN Falskhals. Jag kan ta prints 333 fsb x 9 vs 500 fsb x 6 om de ska vara så dock så kan jag inte visa med två kort atm då jag sålt ett men ska snart handla 1 eller 2 4870

mvh

Visa signatur

Meshilicious, Amd 7950X3D, Asus X670E-I ,96 GB DDR5 6000,RTX4090 FE, Corsair 2TB m.2 / 4TB, Samsung 57" G9

Permalänk
Avstängd

Har nu testat med att köra slumpvisa kopieringar inom ett två megabyte stort minnesblock med 2 till 64 trådar. Testade på min Q9450 både med två kärnor med samma cache och två kärnor som inte delar cache.

http://www.dynga.com/memorycopy/memorycopy2.png

Verkar inte vara något problem alls med cachesynkronisering. Kanske det skulle kunna bli det om man samtidigt kopierade oförskämda mängder data från primärminnet via processorn till grafikkortet? Jag har inte kunskapen att testa det så någon annan kanske kan?
Inte för att det skulle kunna inträffa i verkligheten, men det skulle vara kul att se hur det uppför sig. I verkligheten lägger man ju in datat i kortets minne och sen sker merparten av jobbet där.

Jag kan bara göra detta virtuellt så mindre variationer är oundvikliga.

Observera också att inget på den servern är överklockat då jag värderar stabilitet före prestanda.

Permalänk
Avstängd
Citat:

Ursprungligen inskrivet av dundermuppen
Verkar inte vara något problem alls med cachesynkronisering. Kanske det skulle kunna bli det om man samtidigt kopierade oförskämda mängder data från primärminnet via processorn till grafikkortet? Jag har inte kunskapen att testa det så någon annan kanske kan?

Skall skriva ett test snart.

Tittade en snabbis på ditt och det ser ut som varje tråd allokerar sitt eget minne. För att det skall ske synkronisering så måste varje tråd jobba mot samma minnesarea.

Visa signatur

Programmerare med C++ som huvudspråk.

Permalänk
Avstängd
Citat:

Ursprungligen inskrivet av gosh
Skall skriva ett test snart.

Tittade en snabbis på ditt och det ser ut som varje tråd allokerar sitt eget minne. För att det skall ske synkronisering så måste varje tråd jobba mot samma minnesarea.

Ja, första programmet gör så. Program nummer två jobbar mot samma minne. Kan lägga upp det och källkoden också om du vill?

Permalänk
Medlem

Litet förslag, kanske kan vara värt en egen tråd att visa testresultaten i. Visserligen är det väl nyhetskommentarerna som folk läser mest men det känns lite avigt att behöva hoppa till en post någonstans på 4:e eller 5:e sidan för att få intressanta testresultat.

Permalänk
Avstängd
Citat:

Ursprungligen inskrivet av dundermuppen
Har nu testat med att köra slumpvisa kopieringar inom ett två megabyte stort minnesblock med 2 till 64 trådar. Testade på min Q9450 både med två kärnor med samma cache och två kärnor som inte delar cache.

http://www.dynga.com/memorycopy/memorycopy2.png

Verkar inte vara något problem alls med cachesynkronisering. Kanske det skulle kunna bli det om man samtidigt kopierade oförskämda mängder data från primärminnet via processorn till grafikkortet? Jag har inte kunskapen att testa det så någon annan kanske kan?

Kollade på bilden (vet inte hur ditt andra program är nu) men jag tror man måste veta hur den basic tolken du använder fungerar internt. det ser lite konstigt ut eftersom tiden i princip är proportionell mot antalet trådar. körs flera kärnor så borde inte det inträffa då trådar kan köras parallellt.
Om en tråd tar 10 sekunder så skall inte två trådar ta 20 sekunder.
Känner till att (ursäkta uttrycket) en del sånna här kalleanka språk har egna lösningar på diverse tekniker. Orsaken är att deras metoder internt inte är trådsäkra och då är det omöjligt och hantera trådar på ett riktigt sätt. Python som är väldigt vanligt är ett exempel på det.

Visa signatur

Programmerare med C++ som huvudspråk.

Permalänk
Avstängd
Citat:

Ursprungligen inskrivet av H_Celine
Litet förslag, kanske kan vara värt en egen tråd att visa testresultaten i. Visserligen är det väl nyhetskommentarerna som folk läser mest men det känns lite avigt att behöva hoppa till en post någonstans på 4:e eller 5:e sidan för att få intressanta testresultat.

Nu är du aningens negativ

Citat:

Ursprungligen inskrivet av gosh
Kollade på bilden (vet inte hur ditt andra program är nu) men jag tror man måste veta hur den basic tolken du använder fungerar internt. det ser lite konstigt ut eftersom tiden i princip är proportionell mot antalet trådar. körs flera kärnor så borde inte det inträffa då trådar kan köras parallellt.
Om en tråd tar 10 sekunder så skall inte två trådar ta 20 sekunder.
Känner till att (ursäkta uttrycket) en del sånna här kalleanka språk har egna lösningar på diverse tekniker. Orsaken är att deras metoder internt inte är trådsäkra och då är det omöjligt och hantera trådar på ett riktigt sätt. Python som är väldigt vanligt är ett exempel på det.

Det är ju därför jag börjar med två trådar och inte en. Gjorde en tankevurpa och började med en tråd och fick inte ihop tiderna jag fick ut.
Programmet gör en specifik mängd arbete/tråd så om man dubblar antalet trådar så ska det i en perfekt och harmonisk värld ta dubbelt så lång tid. I verkligheten kanske det dessutom skulle gå aningens snabbare ju fler trådar man kör eftersom flödet borde kunna bli effektivare. Å andra sidan får man mer overhead med fler trådar så det kanske tar ut varandra.

Förra gången jag testade på min amdburk så såg jag en vag tendens till att det gick något snabbare/tråd när antalet trådar ökades. Det var en trött X2a så möjligen kan vi se på din phenom om det inte kan bli resultatet, dvs att det blir aningens effektivare med ökat antal trådar.

Nu kan jag inte assembler på x86, bara 680xx. Annars tillåter denna kompilator även att man skriver sådant.

Kanske skulle skriva det i Ada

Permalänk
Medlem
Citat:

Ursprungligen inskrivet av dundermuppen

Nu kan jag inte assembler på x86, bara 680xx.

Skönt att det finns fler som tycker att man flyttar saker från ett ställe till ett annat ställe, inte till ett annat ställe från en ställe!