Őszinte elismerésem.Útálom az elfogult cikkeket,de most le a kalapot előttetek.Remélem még sok ilyen cikk következik.

Ahonnan én nézem,elég ocsmánynak tűnik a világ

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

Egy Linux kernelfordítást lenyomhattál volna rajta még! :)

ldm start-reconf primary

Hogyan hajtasz végre párhuzamosan pl. egy ilyen ciklust:

int calc(int n)
{
int i;

for (i=0;i<n;i++)
{
printf(''%f'',(float)(cos(i)));
}
}

Én úgy tudtam hogy az egymásrahatások miatt ez nem megy, de cáfolj meg.

while (!sleep) sheep++;

Gratula, még emésztenem kell, mit is olvastam...

kérdéseim:
1. Oprendszert nem émlékszem hogy láttam volna leírva, azt talán érdemes jelölni.
2. Win2k-n és Linuxon is érdemes lenne 1 teszt, hátha mutat valami különbséget.
3. FOrrást nem kapunk?

Köszi

-bocs a hardwerláma-

1. Nézd meg mégegyszer. :)
2. Nem igazán vágom, hogy kellene ugyanezt Linuxra megírni, tekintve, hogy ez volt az első windowsra írt programom...
3. Majd megbeszéljük.
:)

while (!sleep) sheep++;

Hogy érted azt, hogy ''utálod az elfogult cikkeket, DE most le a kalapot...''? A többi cikkünket elfogultnak tartod?

dicranum scoparium + genista pilosa = :)

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 :-)

PK

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.

Ha rám hallgatsz, azt csinálsz amit akarsz!

Megelőztél.
Akkor tőled kérdem!
Ne csak számokkal válaszolj, ha lehet! :))

Ha rám hallgatsz, azt csinálsz amit akarsz!

Saccra 20% körüli teljesítménynövekedést okozhat.

while (!sleep) sheep++;

''Már látom a jövőt: dual processzoros rendszer, mindkét proci HT-vel :-)''

Ez már a jelen. Akár 8 processzorig is... :)
[L]http://www.intel.com/products/server/processors/server/xeon_mp/index.htm?iid=ipp_browse+srvrprocess_xeonmp&[/L]

Ööööö...

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

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...?

Ha rám hallgatsz, azt csinálsz amit akarsz!

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! :)

azé' lassan csak kihúzod belőlük, hogy a paraszt is érccse :))

\m/

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á. :)

while (!sleep) sheep++;

Ne kezdjétek, hogy a memóriától is függ, azt tudom. Tételezzük fel, hogy abból van elegendő...

Ha rám hallgatsz, azt csinálsz amit akarsz!

Bocs, nem tudom miért vagyok állandóan lemaradva...

Ha rám hallgatsz, azt csinálsz amit akarsz!

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

Mi az, ami a fenti programodban párhuzamosan történik???

while (!sleep) sheep++;

Hát a print_cos...

... kell pár száz proci, amit egy hiperkockában összekötögetünk, oszt fityisz a HT-nek :D :D :D

nem tudom mirol van itt szo most.
nekem meg van egy korai forrasa, es szerintem korrekt a tesztprogi.

Mivel párhuzamosan hajtódik végre a print_cos????

(Ugyebár 1 db valami nem tud párhuzamosan történni :D )

while (!sleep) sheep++;

Azt szerette volna mondani, hogy minden fork után létrejön egy szál az aktuális print_cos-nak az aktuális i-re, ahol is persze ki lesz számolva - párhuzamosan (a kiírás már más tészta, de ez úgyis csak pszeudokód). Meg persze nem 2 processzorra...

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.

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)

... a lényeg, hogy a Te programod jól működik a gyakorlatban. A többi csak kötekedés :D

Nna... akkor csak nem vagyok hülye.. nemhiába ebből (is) szakdolgoztam...

udv! 3D Mark 2002 SE-t honnan lehet leszedni? :)) najo nem kotozkodoK, cikk ütött! :)

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

while (!sleep) sheep++;

Hát akkor rendben volnánk nagyjából... 8) Örülök. Az utolsó sör csak vicc volt. Nincs jó C programozó Ritchie óta...

Szeretettel:
Szalma

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 ....


-----

iBook + RedBull :)

Hú vazz... először azt hittem valami kínai oldalra tévedtem :DDD

www.simson4t.hu

A cikk kitűnő! :D

''Attól, hogy valaki paranoiás, még üldözhetik...''

Miért kellene megkülönböztetni egy HT-s és egy kétprocesszoros rendszert?
Megírod a progit szépen többszálasra, aztán a dual gépen gyorsul 70%-ot, a HT-sen meg mondjuk 25-öt. A programozástechnika ugyanaz.

while (!sleep) sheep++;

JÓ CIKK
/csak a garfikonok tetejére oda kellett volna írni a számadatokat/

"... Feltalálom a hidegfúziót oszt reszeltek az amcsiknak...":)))

ez félreérthetó. Szal a szalmával folytatott vitátokra gondoltam. A cikk király, és érthető.

www.simson4t.hu

:))

Ha rám hallgatsz, azt csinálsz amit akarsz!

Én is nagyokat pislogtam erre vitára :P

Az érdeklődőknek küldhetek esetleg forráskódot.

while (!sleep) sheep++;

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.

A szak­ember olyan barbár, akinek tudatlansága nem terjed ki min­denre. (Stanislaw Lem: Az Úr hangja)

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...)

while (!sleep) sheep++;

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...

''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?''

Igen, két procit lát az oprendszer, két CPU használat grafikonnal stb. Támogatni a kell a többprocis üzemmódot.

while (!sleep) sheep++;

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

The turn of the tide i will come back

AMD XP 1800+-on jobb eredményeket kaptam (majdnem 10% - szemre), mint amit HT nélkül mértetek...

Egyszerűen király.
Csak így tovább.

Acer Predator Helios 500 Ryzen, Samsung 960 Pro NVMe + GeChic 15.6" kulso monitor a mobil irodahoz

Szia
occam:
http://www.inf.elte.hu/targyak/progterv/p-ny4/Occam/occam.html

bye,
EmZe Per Iksz XIII.

kapcs.ford.

Uj otlet! (Legalabbis nekem.) Probalta-e mar valaki java-bol a hatast? Ugy tudom a java virtalis gepben minden thread. Tehat egy java alkalmazas mit profitalhat a HT-bol? Szerintetek?