Aktív témák
-
BRinyo
aktív tag
Hali!
Emvy (és aki még érdemben hozzá tud szólni)! Egy ideje, több általunk összeállított gépen futtattam le ezt a kis twinbench progit. A legutóbbi alkalommal egy IC7-ben lévő, P4-2600C procival, dualDDR400 (CL2) RAM-okkal megalapozott rendszeren futtattam le és a végén 47 mp-nek írta ki a 4ALU+4FPU művelet hosszát. A saját gépem egy ABIT KX7-es(KT333), egy RAM csatornás, 400-as CL2-es RAM-okkal és egy xp2500+(barton) procival szerelt konfig. 2200MHz körüli órajelen járva ez a gép viszont 44 mp-et írt a 4ALU+4FPU művelet hosszára. Most akkor ez miért is van és van-e még valami, amit figyelembe kellene vennem a teszt futtatása során?
thx!
K3l -
#46
Don Kartacs
csendes tag
Don Kartacs
csendes tag
Valaki okosílyon már ki, hogy a hyper trading segít e azon a problémán,
hogy baromi lassú a másolás LAN-on!!! , ha közben játszódom vmivel vagy fímet nézek -
-
Szalma
őstag
Ha valaki számításigényes és jól párhuzamosítható feladatot végez, akkor a dual jobb. De ha kell szép grafika a felhasználó arca elé, meg valami lebegőpontos effektet is rakni kéne rá, akkor egy Beowulf-al nem sokra megy az ember...
Amin otthon fejlesztek: egy BP6 két 550-es celeronnal, és az a tapasztalatom, hogy ugyan játékokban esélytelen mostanában, de fejlesztésben és fotosopban 8) csak nemrég tudták lelépni az egyprocis gépek. (Hogy milyen érzés: a 2 celeronon nem tétovázik a vindóz, egyprocison néha megakadni látszik, ezt gondolom Te is tapasztaltad már. Szóval ha fordítok több cuccot egybe, attól még könnyen dolgozhatok a grafikán, mert bírja. Mindezt a másik gépemen (1400AMD) nem tudom megtenni. Ami érzésben közel van hozzá az a kollégám 1800+AMD-je, de ott is előjön néha a megakad érzés... Ha csak ezt a feelinet csökkenti a HT, már akkor megérte, annyit dob a használati értéken.)
Egy looser kérdés: ezeket a HT-s procikat hogyan láttatja az alaplap? 2 procinak? Kell az oprendszernek támogatnia a többprocesszoros rendszereket a HT használatához?
Szeretettel:
Szalma
ui.: A HT szerintem jó, inkább az a probléma, hogy a gyártók a fejlesztéseiket szépen lassan csöpögtetik a piacra. Nem tetszik ez az anyagias világ, ami körbevesz. Ha nincs pénzem, senki vagyok. Ahhoz hogy pénzem legyen valamilyen szinten át kell vernem embereket... Brrrr.... Inkább az őskor... -
Nekem pont az derült ki a tesztből - ez volt az egyik dolog, amire nagyon kíváncsi voltam - hogy a HT nem lassít akkor, amikor több szál ugyanazt az erőforrást használja. Ez persze nagyon logikus, hiszen minden P4-ben benne van a HT, csak nincs aktiválva, tehát a csővezeték tele van a támogatáshoz szükséges elemekkel, és ahogy írtam is, nem tudhatjuk, hogy ezek mennyit lassítanak a procin, de a HT bekapcsolt állapota NEM lassít akkor, ha két processz egyszerre használ (szeretne használni) egy erőforrást.
Tehát megírod a programot párhuzamosra, és ha ugyanolyan műveleteket használ egyszerre, akkor dualon gyorsul, HT-n ugyanaz, ha pedig különbözőeket, akkor dualon gyorsul, HT-n dettó.
Tehát nem kell másfajta optimalizálás.
Legalábbis szerintem, cáfolj meg.
(de kalkuláld, hogy NEM lassít a HT bekapcsolt állapota a kikapcsolthoz képest, mondjuk nem megfelelően fordított programoknál az optimalizáció érdekes eredményeket hozhat...amikor nem megfelelő könyvtárakat használtam, HT nélkül szépen futott, HT-vel pedig felborultak a végrehajtási sorrendek...) -
shtml
őstag
Pl. azért, mert kétprocesszoros rendszerrel azonos típusú műveleteket is párhuzamosíthatsz, HT-gel viszont nem (érdemes), hiszen a HT-ben ugyanazokért a végrehajtó egységekért versenyzik a két szál.
Ha pl. főleg lebegőpontos műveleteket futtatsz egy duál gépen mindkét szálon, akkor jelentős a gyorsulás. HT esetén viszont egyenesen lassulni fog. A tesztekből is látható, hogy a HT több esetben lassít.
Vagyis másféle optimalizálás kell HT-re és megint másféle egy kétprocesszoros gépre. -
esteban
senior tag
akkor most a multitasking (skizofrenia :))
-----
Szerintem az AMD (IBM :) ) megoldasa lesz celravezetobb ... tobbet erove: pufff bele meg 1 procit a tokba azt hagy szojjon ... a gyartasi koltsegek nem olyan egetveroen kulonboznek, hogy ennyi szoszmoszt megerjen a HT ...
Meg ugy e itt jonnek megint az alkalmazasok > egy valos 2 procis rendszereket mar tudnak hasznalni , mar vannak ... de egy ilyen 1.5 os procihoz ujra kell gondolni, irni etc. .. mindent ...
persze csak szerintem ....
----- -
Mondjuk, hogy a fork ( fv ) utasítás elindít egy független szálat az fv fügyvénnyel. Ekkor leszalad a ciklus és elindít n darab print_cos() függvényt 0-n-ig paraméterezve. Azok meg futnak, ahogy tudnak.
Jójó, azt hiszem, másról beszéltünk, mert a jelen esetben semmit nem gyorsít és gyorsíthat amit írtál, ott tudna gyorsítani, ahol
fork(fv1)
fork(fv2)
lenne, és az fv1 és fv2 párhuzamosan hajtódna végre.
Ez azt hiszem világos, egy kicsit mást mondtál te és mást én. Tehát abban az esetben érdemes párhuzamos folyamatokat indítani, ahol nincs adat egymásrahatás, mivel nyilván csak sorosan lehet majd őket végrehajtani. A cikk is azt akarta mondani, hogy ahol lehet párhuzamosítani, ott érdemes lesz, legalábbis HTvel rendelkező processzoroknál. Viszont ehhez logikai blokkokra érdemes bontani a programot, mert túl kis részek párhuzamosításánál a taszkkezelés egyensúlyi állapota felborulhat.
OCCAMról elég annyi, amit tudok:).
Nem vagyok jó C programozó, sőt, programozó sem, sőt, informatikus sem.:D -
Szalma
őstag
Mondjuk, hogy a fork ( fv ) utasítás elindít egy független szálat az fv fügyvénnyel. Ekkor leszalad a ciklus és elindít n darab print_cos() függvényt 0-n-ig paraméterezve. Azok meg futnak, ahogy tudnak.
Ha komolyabban érdekel a párhuzamosítás problémája, akkor javaslom, hogy nézegess Modula-2 programokat és irodalmat. Ennek a nyelve elég egyszrű (Wirth prof. készítette, Pascal szerű), de nyelvi szintek képes párhuzamosításra. Rendkívül jól lehet vele szórakozni. DOS alá van egy nagyon jó fejlesztőkörnyezet, TopSpeed Modula-2. Lehet hogy megvan valahol a neten.
Ha esetleg harcore paralell programming érdekel, akkor google és CAR Hoare nevére keresve van egy-két érdekesség. Sajnos az elte OCCAM leírását már csak a google tárolójában találtam meg:
[L]http://216.239.39.100/search?q=cache:F3RnBP-Wp-4C:www.inf.elte.hu/targyak/progterv/p-ny4/Occam/occam.html+Hoare+paralell+csp&hl=hu&ie=UTF-8[/L]
Szeretettel:
Szalma
ui.: És ne feledd: egy jó C programozó BÁRMILYEN nyelven képes C programot írni... 8) -
-
Szalma
őstag
Hihi...
Nem akarok rosszat senkinek, mindöszesen azt állítottam, hogy Hoare és Dijkstra óta tudjuk, hogy minden Turing-gépre implementálható feladatnak van párhuzamos implementációjú megoldása IS. Nem feltétlenül a legjobb, de van.
Szóval még csak annyit szeretnék hozzátenni, hogy igen-igen nehéz feladat eldönteni egy nem általunk kontrollált párhuzamosításnál, hogy mely struktúra az, amelyet nem oszt szét a felsőbb hatalom. Valamint, ha felkészülünk a párhuzamosításra (ugye a tesztből is ez derült ki!!!!), akkor egy fejlettebben párhuzamosító achitektúrán jobban/gyorsabban működünk...
(SzemiC, paralell megoldás:
calc ( n ) {
for ( i = 0; i < n; i++ )
fork ( print_cos ( i ));
}
print_cos ( i ) {
printf ( ''%f'', cos ( i ));
}
For jú. 8)
Tippként: ha a koszinusz eredményeit összeadnád, akkor nehezebb feladatom lett volna... (De nem reménytelen...)
Szeretettel:
Szalma -
#19
peace&love
aktív tag
peace&love
#18
peace&love
aktív tag
válasz
peace&love
#18
üzenetére
Bocs, nem tudom miért vagyok állandóan lemaradva...
-
#18
peace&love
aktív tag
peace&love
#14
peace&love
aktív tag
válasz
peace&love
#14
üzenetére
Ne kezdjétek, hogy a memóriától is függ, azt tudom. Tételezzük fel, hogy abból van elegendő...
-
Naszóval.
Az N darab konstans kiíratását nem fogod tudni megcsinálni, mert ahhoz előre tudnod kellene a műveletek végeredményét, és függvény lévén, ezt nem fogja neked megcsinálni a compiler, meg a futás közben sem létezik olyan optimalizáció, ami gyorsabban végrehajtja neked ezt a műveletet, mintha inkrementálnád i-t, pakolgatnád a stackbe a paramétereket, és hívogatnád a cos fv-t.Nyilván itt lehetne külön formázni a floatot és előkészíteni az stdoutot, de pl. egy printf esetén ennek nem sok értelme van, mert threadot kreálni jóval több idő, mint floatot formázni.
Másik dolog: NE keverjük össze az utasításszintű párhuzamosságot a szálakkal! Csővezeték már a 386-osban is volt, az utasításátlapolás teljesen más tészta, mint a többszálú működés. A többszálú működés lényege, hogy olyan utasításokat hajtasz végre párhuzamosan (akár virtuális, akár valós párhuzamosítással), amelyeknek semmi közük egymáshoz (alacsony szinten legalábbis), de itt a legkisebb értelmezett egység az utasítás, a legnagyobb pedig a taszk vagy a processz, az utasításszintű párhuzamosítás legnagyobb egysége az utasítás, a legkisebb pedig az utasítás feldolgozásának lépései.
Satöbbi, satöbbi, satöbbi, ha nem oké, akkor szólj hozzá. :) -
#16
marcee
addikt
peace&love
#14
marcee
addikt
válasz
peace&love
#14
üzenetére
azé' lassan csak kihúzod belőlük, hogy a paraszt is érccse :))
-
#15
rog
addikt
peace&love
#14
rog
addikt
válasz
peace&love
#14
üzenetére
segit.
gyak az oprencer azt hiszi hogy ket proci van a gepben. sot mar a bios is. ezert valszeg a chipset is. na jo o esetleg sejti, hogy itt valami turpissag van. :)
szoval igen, ha az opr. kepes ra es jol ossza be az eroforrasokat (jelen esetben a procikat is), akkor elvileg simabban fut a mediaplayer, amig te a hatterben fajlokat tomoritgetsz .
vagy nem. de akkor ne nalam reklamaljon senki! :) -
#14
peace&love
aktív tag
emvy
#11
peace&love
aktív tag
Hát az már megéri...
Csak, hogy fordítsuk le nekem magyarra: ez a HT működés segít abban, hogy a win háttérben futó 80 processze és esetleg több egyidejűleg futtatott alkalmazás OutlookExp., Int.Explorer, Photoshop, Illustrator, Acrobat, víruskereső, stb, esetén kevesebb homokórával találkozzunk? Vagy csak a külön erre írt programok teljesítményét növeli, és nem segít a fent említett dologban...? -
Szalma
őstag
Ööööö...
Ez pl. teljesen ekvivalens n darab cos(konstans) végrehajtásával és kiírásával. Persze lehet, hogy az output keveredni fog, de akkor is... 8)
Szóval MINDENT lehet párhuzamosan csinálni (különösen, ha nem a proci assembly-jében készül a program), de nem feltétlenül érdemes!!!
(A példádban a printf egy elég jól párhuzamosítható dolog: 1. thread felkészül a file kezelésre, mert az a leglassabb művelet egy oprendszerben (jelen esetben stdout), 2. thread addig formázza a float-ot. És ezt még akár C-ben is meg lehet valósítani. Ha lejjebb megyünk az absztrakciós szinteken, akkor még több párhuzamos feladat adódik. A procik pl. teljesen jól párhuzamosítanak: miközben instruction fetch megy, azonközben van branch jóslás, ALU művelet, stb. EGY időben, EGY órajel-élre. És erre minimális ráhatása van az embernek. Különösen egy ''magasszintű'' nyelvből...)
De csak kötözködöm...
Szeretettel:
Szalma -
#11
emvy
félisten
peace&love
#9
válasz
peace&love
#9
üzenetére
Saccra 20% körüli teljesítménynövekedést okozhat.
-
#9
peace&love
aktív tag
peace&love
aktív tag
Akkor a gyakorlatra lefordítva az olyan alkalmazásoknál, mint pl. Photoshop, ami a programozás szintjén is támogatja a duál-processzoros működést, okoz-e valós teljesítmény növekedést, ill. ha okoz, akkor mekkorát? Pl. egy valódi fizikailag két processzorral működő géphez képest.
Tudom, lámer vagyok, de számomra ez nem világos. -
pk
csendes tag
Az érdekesség kedvéért nem ártana összehasonlítani a HT-t egy valódi 2 processzoros rendszerrel. Megtettem, és érdekes eredmények születtek, bár az eredményeimet a cikkben írt futási időkkel számszerűen összehasonlítani nem lehet, mert a gép, amin teszteltem egy dual PIII-800. Ami tanulságos, és összehasonlítható, az a futási idők aránya.
A teszt eredménye:
1 integer running time:13.684966 secs.
1 floating point running time:13.579376 secs.
2 integer running time:13.995302 secs,
2 floating point running time:13.743130 secs,
1 integer and 1 floating point running time:13.762499 secs,
4 integer running time:19.967405 secs,
4 floating point running time:20.414578 secs,
4 integer and 4 floating point running time:33.857547 sec,
Ami kiolvasható a számokból: itt a HT-vel ellentétben a két proci nem hat egymásra. (legfeljebb a pénztárcánkra ;-) ). Ez persze várható is volt.
Már látom a jövőt: dual processzoros rendszer, mindkét proci HT-vel :-) -
Szalma
őstag
HI!
Nagyon jó! Szerintem korrekt.
Viszont: bármilyen programot végre lehet hajtani párhuzamosan (legyen az akármilyen ciklus), legfeljebb nem érdemes. A HT, úgy tűnik, jól válogat.
És egy programozástechnikai megjegyzés: egy bizonyos bonyolultság feletti felhasználói interfész korrekt kezelése sokkal egyszerűbb threadekben futtatott állapotgépekkel, mint lineáris programozással. (Nem kell 1000 flag, szét lehet dobni az állapotgépek implementálását több programozónak, UML interfész készítése is megoldható, stb.)
De a cikk, az nagyon jó!!!
És talán a HT-s procik árai is gyorsan csökkennek... 8)
Szeretettel:
Szalma
Aktív témák
- Kínai és egyéb olcsó órák topikja
- Google Pixel topik
- PlayStation 5
- Elektromos autók - motorok
- Telekom T Phone 3 5G – modern tudakozó
- Nem okoz az adattárolón hibát a Windows 11 augusztusi frissítése
- Háztartási gépek
- CADA, Polymobil, és más építőkockák
- Xbox Series X|S
- Milyen autót vegyek?
- További aktív témák...
- HP ZBook Firefly 14 i7-1165G7 32GB 1000GB 14" FHD 1 év garancia
- KIÁRUSÍTÁS - egybe 4db RTX 4070-es Legion Pro 5 gép eladó - 2M Ft
- HP 14 Elitebook 840 G10 FHD+ IPS i5-1335U 10mag 32GB RAM 512GB SSD Intel Iris XE Win11 Pro Garancia
- Bomba ár! Dell Latitude 5400 - i7-8GEN I 8GB I 256SSD I 14" FHD I HDMI I Cam I W11 I Gari!
- Felsőkategóriás Gamer PC-Számítógép! Csere-Beszámítás! R7 9800X3D / RTX 5070Ti / 32GB DDR5 /1TB SSD
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest