[muffello]

Ei osanud seda kuhughi mujale panna (algaja ikkagi ) ja kuna tegemist on protsessoriga, siis panin siia.

Lugu on siis selline:

Koolis (Mainor) on vaja teha töö. Teemaks on Pentium 4. Vaja oleks teha praktiline test Hyper-Threadingu (HT) kohta, kuid endal kodus AMD prose. Tähtaeg on 12. oktoober kell 23:59. Testi eesmärk oleks HT mõju protsessori jõudlusele ja HT'd peaks saama BIOS'ist välja lülitada, et teha testid koos HT'ga ja ilma HT'ta.

Kas keegi on saaks aidata? Soovitavalt Pärnust, kuna ise elan Pärnus. Kui kedagi Pärnust ei ole siis äkki oleks keegi nõus need testid ära tegema ja mulle tulemused saatma.

Testide all mõtlesin: PC Mark, 3DMark, Sisoft Sandra. Veel ettepanekuid?

Tänan tähelepanu eest.

NB! Asjaga on jube kiire!

[erick]

Pane siis juba üles, palju sa nõus maksma oled potentsiaalsele testijale

(hint: nett on täis neid HT teste, tõstad äkki sealt numbrid )

[Ho Ho]

Vihjeks võin nii palju öelda et ükski su poolt toodud testidest ei näita HT puhul erilist kasu
Parem proovi asju mis on suutelised mitut proset kasutama. Näiteks Cinebench
https://foorum.hinnavaatlus.ee/viewtopic.php?t=163416

Võid ka proovida näiteks povray'd kuid sellel vist häkiti mitme prose tugi juurde alles suhteliselt hiljuti ning see pole minu teada eriti efektiivne. Samuti võid proovida mingeid audio/video töötlus programme mis suudavad mitut proset ära kasutada.

Ma võiks ka ise abi pakkuda kuid mul on kaks probleemi:
1) ma olen tallinnas
2) mul puudub masinas windows.

[Cooler(-10)]

Blender3d (yafray) on võimeline kasutama ht-d. Netis peaks olema piisavalt tutooriale ja projekte, mida renderdada. Aja näitab ära valmis renderdatud pildi aknal ja konsoolis. Kui otsustad seda kasutada, siis võid teha erinevaid kombinatsioone nt. w/ht ja yafrayst 1 cpu, w/ht 2cpu, wo/ht 1cpu ja wo/ht 2 cpu. (w-with ja wo-without ) Siis veel peaks vaatama, et photoneid ei kasutataks, kuna footonite tulistamine (shooting photons) ajal ei kasutata kindlasti kohe 2 proset ehk HT-d. Enne pead muidugi ht toega prose leidma kusagilt. 8)

Aquamark miskisugusel oli ka võimalus kasutada ht-d.

PS. Kui vaja, siis võin saata ps-ga mõned blenderiga tehtud võrdlusajad.

[muffello]

Suured tänud vastajatele , eriti aga kasutajale pealuu, kes ei pidanud paljuks vaeva, et need testid ära teha. Muideks, Cinebench tehti ka ära.

To Cooler(-10):
Kui võimalik, siis saada ikka, ära ei ütle .

Veel kord tänud kõigele, kes võtsid vaevaks vastata .

[Ho Ho]

Oleks tore kui testide tulemused siin avaldaksid.
Pole ise eriti viitsinud HT'd spetsiaalselt testida, tahaks näha palju siis sellest kasu on

[v2hja]

[pealuu]

[Cooler(-10)]

Täna õhta panen siis siia üles mõned blenderi ajad. Praegu koolis ja eile pold enam eriti aega

Edit: Sain lõpuks oma arvuti taha ja tegin blenderiga mõned testid, tõsi, ega ma miskit 10mintsa renderit ette ei võtnud, aga vb aitab ka 1 minutilisest renderdusest, et miskit vahet leida.

HT-ga ja 2 threadi: 0:59.82
HT-ga ja 1 thread: 1:00.09
HT-ta ja 2 threadi: 1:12.54
HT-ta ja 1 thread: 1:13.09

Nagu näha, pole sellise aja jooksul erilist võitu 2 threadi kasutades, kuid HT-ga on asi hoopis teine.

[Ho Ho]

Hoopist teine andes peaaegu terve kolmandiku sekundit juurde võrrelduna ilma HT'ta kus sai üle poole sekundi?
Sa neid numbreid ise ka vaadanud oled mis sa siia kirjutasid
Nii väikese vahe võib vabalt ka lugemisveaks nimetada.

[edit]
See vahe HT vs no-HT tuli tõenäoliselt sellest et samal ajal jooksis taustal mingi teine protsess mis HT korral teisel virtuaalprosel töötas. Kui blender suudaks korralikult mitut proset kasutada siis peaks aeg nii HT'ga kui ilma HT'ta ühe threadiga sama olema ning HT'ga kahe threadiga umbes nii nagu sul oli nii HT'ga nii ühe kui kahe threadiga.
[/edit]

Samuti tundub mulle et blender pole just kõige paremini threade kasutav proge. Proovi parem povray'd. Sellele poogiti mõnda aega tagasi samuti HT tugi külge, ehk seal on asi optimaalsemalt tehtud.

Samuti võid proovida kasutada rohkem kui kaht threadi. Näiteks ühes enda tehtud threadide testis sain ma 16 threadiga kehvemaid tulemusi kui 64'ga

[heikis]

[Ho Ho]

Sel juhul selgita seda mida ma [edit] tagide vahele kirjutasin.

Antud hetkel on mul selle testi kohta kaks kahtlust:
1)taustal jooksis igasugu kama
2)testi numbrid on laest võetud

Ehk testija ütleks mida ta renderdamiseks kasutas, oleks tore kui saadaks tolle .blend faili


[edit]

Leidsin vist põhjuse miks threadide arv renderdamise kiirust ei mõjutanud. Cooler kasutas vist blenderi enda renderdajat mitte yafray'd kuid arvas et kui muudab yafray seadete alt et tal on kaks proset siis see mõjutab ka blenderi enda rasterdajat. Nii see aga ei ole.
Teeksin hea meelega blenderi ja yafray'ga paar testi kuid siiani pole veel aru saanud kust saaksin vaadata renderdamiseks kulunud aega. Blenderi enda renderdaja näitab seda ilusti konsoolis kuid yafray mitte.

[Cooler(-10)]

Eip, ma kasutasin yafrayd renderdajana ning taustal jooksis kõikide testidega sama palju pahna. Kes tahab blend faili, siis andke teada priva kaudu. Ajad ei ole mitte lambist võetud, vaid sealt akna ülevat, kus renderdamine ilusti näha on ruutude kaupa. Tiitelriba oli vist selle asja nimi kui mu mälu mind tillust ei tõmma.

[Ho Ho]

Jäin küll ~1.5h hiljaks kuid võibolla kellelegi pakub siiski huvi ka minu testi tulemused.

Ei hakanud blenderiga jamama sest tundub et yafray threadide majandamine pole just kõige paremini tehtud võtsin hoopis ühe teise ray traceri firmalt inView, täpsemalt demoprogrammi mille saab OpenRT'ga kaasa. Seal kasutasin default seadeid kuid resolutsiooni panin maksimumi peale (640x478) mida demo lubas.

Tegin nii HT'ga kui ilma HT'ta kolm testi:
multithreaded kaks threadi
multithreaded üks thread
singlethreaded üks thread
Rohkem kui kahe threadiga ei hakanud testima sest nagunii kulub väga suur enamus arvutusressursse SSE2 üksustes nign neid minu teada HT ei luba kahel threadil paralleelselt kasutada, kui ka lubaks siis tõenäoliselt ega seal eriti palju registreid vaba ei ole et kaks threadi korraga mahuksid arvutusi tegema.

Kuna seal otsest benchmarkimise võimalust ei olnud siis pidin lihtsalt vaatama titlebaril olevat FPS'i. Õnneks ei kõikunud see eriti palju jäädes valdavalt alla 1%.

Tegin ka igast katsest pildi kus on näha renderdatav kujutis, programmi seaded ning prosekasutus.
Suhteline kiirus näitab kui palju erineb FPS 2 threadiga renderdamise kiirusest

Piltide suurus on keskmiselt ~380kiB.
Testitulemused olid sellised:

HT biosist lubatud, OS'il kernelis kahe prose tugi lubatud
1)multithreaded, 2 threadi, keskmine kiirus ~4.10FPS suheline kiirus 1
2)multithreaded, 1 thread, keskmine kiirus ~3.95FPS suhteline kiirus 0.963
3)singlethreaded, 1 thread, keskmine kiirus ~3.93FPS suhteline kiirus 0.959

HT biosist keelatud, OS'il kernelis kahe prose tugi lubatud kuid kastutatakse ikkagi ainult üht(sest HT on ju keelatud)
4)multithreaded, 2 threadi, keskmine kiirus ~3.77FPS suheline kiirus 1
5)multithreaded, 1 thread, keskmine kiirus ~3.91FPS suhteline kiirus 1.037
6)singlethreaded, 1 thread, keskmine kiirus ~3.90FPS suhteline kiirus 1.034

Suhteline kiirus kahe prose ja kahe threadi suhtes:
4) 0.920
5) 0.954
6) 0.951

Esimeselt pildilt võib näha et prosekasutus on üsnagi stabiilselt paar protsenti alla 100. Teisel aga et thread vahetab pidevalt proset millel ta jookseb. Kolmandal aga jookseb thread pikalt ühel ja samal prosel ainult väga harva jooksutavat proset vahetades.
Samuti võib näha et nii singlethreaded kui ühe threadiga multithreaded testis ei anna kahe prose koormus kokku 100% vaid rohkem. Seda saab selgitada sellega et ka teised protsessid tahavad aeg-ajalt midagi teha, näiteks X uuendab ~4x sekundis ray traceri pilti ning veidi tihemini gkrellm'i.
4-6'l on näha et prosekasutus on pidevalt põhjas, vahet pole mis viisil ja kui palju threade kasutada. Eraldi ei hakanud vaatama mis thread kui palju proseaega kasutab. Samuti jääb igasuguste prose eventide lugemine mõneks teiseks korraks (context swich'id, cache miss'id, branch misprediction'id FLOPS'id jne).

Kokkuvõtteks ütleks et OpenRT's annab HT juurde keskmiselt 5% jõudlust võrreldes ima HT'ta prosega. HT puhul andis kaks threadi ühe asemel juurde umbes 4%. Kahe eraldi füüsilise prose puhul oleks tõenäoliselt multithreaded ühe threadiga asi olnud mõningal määral aeglasem kuna protsessi ühest prosest teise liigutamine ei ole päris tasuta.
Ilma HT'ta oli kõige aeglasem multithreaded ühe threadiga test. Selle põhjuseks pean ma seda et multithreaded lahenduses pakub arvutav protsess iga teatud aja tagant prosele võimaluse käivitada mõni teine protsess (ehk siis yeld'ib) ning context swiche on rohkem kui singlethreaded testis. Põhimõtteliselt peaks sellega saama threadide vahetamisega üsna hästi hakkama ka tavaline OS'i sisseehitatud plaanur kuid arvatavasti on manuaalne yeldimine tingitud sellest et tahetakse kindlad olla et juhtprogramm mis erinevatelt threadidelt infot kogub suudaks piisavalt tihti oma arvutusi teha.


Kui keegi väga tahab siis võin ma üles otsida ka paar programmi mis näitavad kui palju ideaalilähedastel tingimustel võib HT'st kasu olla. Üks neist oli Javas kirjutatud suurte arvude faktoriaalide leidja mis 100k faktoriaali arvutamisel kiirenes ühe threadi pealt kahe peale liikudes kuni 50%. See on arvatavasti tingitud sellest et kaks threadi suutsid mälu latentsust paremini varjata.
Teine programm on rekursiivne fibonacci arvude arvutaja. See käitus veidi reaalsemalt andes 1 threadi pealt 2 peale liikudes juurde ~10%, 1 pealt 4-32 peale liikudes ~15-18% ning üle selle ~12-14%. See programm oli piiratud väga sagedaste pipelinede tühjendamistega sest seal kutsuti üht funktsiooni välja väga tihti, arvutused olid aga äärmiselt lihtsad.



PS!
Kui kellelgi on kahe või rohkema protsessoriga(vahet pole kas dualcore või lihtsalt kaks proset) 32bit Linuxi ning X serveriga masin ning ta viitsib toda testi korrata siis palun saatke PS või võtke mingil muul moel ühendust. Test ise ning programmide installimine on äärmiselt lihtne, programmid võtavad kokku alla 50MiB ruumi, pakitult alla 29MiB. Testimine ei võta tõenäoliselt rohkem kui mõni minut, programmide install minu juhendamisel max 5 min. Maksimaalselt ei tohiks aega kuluda kui 1h kuid sinna sisse on arvestatud ka mitu kordustesti ning võimalikud installiprobleemid ning piltide tegemine ja võimalik töötlus.

[muffello]

Nii. Tehtud testide tulemused.

Testarvuti
Intel 865Perl
Pentium 4 2,8 GHz (Northwood) HT
PC 3200 2x512 MB

3DMark03
CPU Score, CPUMarks:
HT'ta 721
HT'ga 733
CPU Test 1, FPS
HT'ta 77,7
HT'ga 78,4
CPU Test 2, FPS
HT'ta 13,2
HT'ga 13,6

3DMark05
CPU Score, CPUMarks
HT'ta 3351
HT'ga 3549
CPU Test 1, FPS
HT'ta 1,7
HT'ga 1,8
CPU Test 2, FPS
HT'ta 2,9
HT'ga 3,1

Nagu näha, pole 3DMark prose testiks sobiv.

Cinebench 2003 v1
1)HT sekundid 2) CB CPU
Single CPU Render 1) 93,8 2) 280
Multiple CPU Render 1) 78,8 3) 334

CB CPU väärtus 100 vastab 1 GHz Pentium 4 jõudlusele. Sellest järeldub, et HT toega 2,8 GHz töötab nagu 3,34 ilma HT'ta prose. Jõudluse kasv 19%.

PCMark04
1) HT väljas; 2) HT sees; 3) Jõudluse kasv, %
CPU, üldskoor 1) 3693,0; 2) 4246,0; 3)15
Faili pakkimine 1) 3,4 MB/s; 2) 4,7 MB/s; 3) 38
Faili krüpteerimine 1) 39,8 MB/s; 2) 43,8 MB/s; 3) 10
Faili lahti pakkimine 1) 23,8 MB/s; 2) 33,1 MB/s ; 3) 39
Pildi töötlus 1) 11,4 MPixels/s; 2) 12,7 MPixels/s; 3) 11
Õigekirja kontroll 1) 4,0 KB/s; 2) 4,0 KB/s; 3) 0
Faili lahti krüpteerimine 1) 71,0 MB/s; 2) 80,2 MB/s; 3) 13
Heli konverteerimine 1) 2446,8 KB/s; 2) 2452,0 KB/s; 3) 0,2
WMV video pakkimine 1) 43,8 FPS; 2) 49,6 FPS: 3) 13
DivX Video pakkimine 1) 48,0 FPS; 2) 55,9 FPS; 3) 16

PCMark04 testidest parim tulemus failide pakkimisel - jõudluse kasvu 38-39%.

SiSoftware Sandra, aritmeetika test
1) HT väljas 2) HT sees 3) Jõudluse kasv, %
Dhrystone ALU, MIPS 1) 7407; 2) 8570; 3) 16
Whetstone FPU, MFLOPS 1) 2038; 2) 3486; 3) 71
Whetstone SSE2, MFLOPS 1) 3761; 2) 6128; 3) 63

SiSoftware Sandra, multimeedia test
1) HT väljas 2) HT sees 3) Jõudluse kasv, %
Integer1 x8 iSSE2, it/s 1) 17220 2) 21435 3) 24
Float2 x4 iSSE2, it/s 1) 21652 2) 30482 3) 40

Sandra testides on kasu HT'st, eriti SSE2 ja FPU ujukoma tehetel.