Idén mutatkoznak be a négymagos AMD chipek
Oldal 1 / 2Következő →
Jelentkezz be a hozzászóláshoz.
#68
Amikor swappel, akkor természetesen lassú. De nem errõl volt szó, mert ehhez semmi köze a for ciklusoknak.
Tapasztalatom szerint 1GB RAM mellett nem nagyon kell swappelni. Persze attól függ, hogy milyen progikat használsz. A céges gépemben 2 giga van, mert oda 1 már kevés.
De a swappolás sem 100%-ban a win hibája, hiszen a futtatott alkalmazások eszik meg a memória nagyobb részét.
Persze a win memória kezelésén is bõven van mit javítani.
Tapasztalatom szerint 1GB RAM mellett nem nagyon kell swappelni. Persze attól függ, hogy milyen progikat használsz. A céges gépemben 2 giga van, mert oda 1 már kevés.
De a swappolás sem 100%-ban a win hibája, hiszen a futtatott alkalmazások eszik meg a memória nagyobb részét.
Persze a win memória kezelésén is bõven van mit javítani.
#67
nekem kétmagos pocim van 2 hónapja, meg vagyok vele elégeve. Bár ez nem azt jelenti, hogy rögtön megveszem a 4 magosat, mert ez a proci marad 2-3 évig, mert azért pénzügyileg megzuhantja az embert 😄DD
HALA MADRID Real Madrid | Fifa Award - Best Club XX Century
#66
Tudható, hogy a kód nagy részét névtelen, nem túl motivált és lelkes, nem különösebben jól fizetett, átlagos programozók tömege csinálja, és normális optimizálásra idõ sem lenne (meg általában lehetõség sem, tekintve a felhasznált fejlesztõi környezeteket, amik nem optimális kód készítésre vannak kihegyezve).
#65
"Én nem tudom, nekem egyszerûen nem akar lassú lenni. Biztos rosszul csinálok valamit."
Hmm, és mondcsak, neked hány giga ramod van, 2-3? (Hogy kikapcsolhattad a swappolást, ami sok-sok ram esetén is bejátszik.) Vagy sosem használsz egyszerre 1 "komolyabb" programnál többet egyszerre? Valami szupervinyód van, esetleg 4x-es RAID konfigod (mind tükrözve...), ami többszáz MB-ot tölt mp-enként. Csak mert emberi számítás szerint 1GB memória lecserélése (ram-vinyó) 100MB/s-mal számolva is 20mp... Fél giga meg 10.
(Ez persze most csak a swap, és arról volt szó, hogy nem csak a swap miatt lassú, de én most csak a te hozzászólásodra reagáltam.)
Hmm, és mondcsak, neked hány giga ramod van, 2-3? (Hogy kikapcsolhattad a swappolást, ami sok-sok ram esetén is bejátszik.) Vagy sosem használsz egyszerre 1 "komolyabb" programnál többet egyszerre? Valami szupervinyód van, esetleg 4x-es RAID konfigod (mind tükrözve...), ami többszáz MB-ot tölt mp-enként. Csak mert emberi számítás szerint 1GB memória lecserélése (ram-vinyó) 100MB/s-mal számolva is 20mp... Fél giga meg 10.
(Ez persze most csak a swap, és arról volt szó, hogy nem csak a swap miatt lassú, de én most csak a te hozzászólásodra reagáltam.)
#64
Nem. 😊 Mivel az a program aktuális kódjától függ. Kivéve persze az olyan nyelveket, mint a Java, ami - hacsak nem bytecode-ban van - futás elõtt fordul le gépi kódra, és ha olyan a compiler, 64 bites (jobban mondva AMD64-es) kódot fordít, ha lehet.
#63
"Én nem tudom, nekem egyszerûen nem akar lassú lenni. Biztos rosszul csinálok valamit."
Hehe, öregem, ez ám a parasztvakítás! Biztos megzavart téged a for ciklus. Hehh. <#hehe>
Hehe, öregem, ez ám a parasztvakítás! Biztos megzavart téged a for ciklus. Hehh. <#hehe>
CPU Tuning Toplista http://cputuning.net
#62
"Hát ennyit érnek a M$ "szuper", nagyüzemi fejlesztési módszerei, hogy zöldfülû progizók hegyeit rakják a futószalag mellé!"
Te hány win programozót láttál már? Vagy hány sor win forráskódot?
Te hány win programozót láttál már? Vagy hány sor win forráskódot?
#61
"Alapvetõen tudjátok,hogy miért olyan kibaszottúl lassú az xp?"
Én nem tudom, nekem egyszerûen nem akar lassú lenni. Biztos rosszul csinálok valamit.
"Rengeteg egymásba ágyazott FOR ciklus van a forráskódba,ahelyett,hogy a pointerekkel dolgoznának ami valamivel több logikát feltételez a programozótól.."
Te láttad már az XP forráskódját?
"egy egyszerû for ciklussal indexel a memóriába pl:
for (int i=0; i<valami; i++)
for (int j= ...
for (..
for ... és így tovább közben meg vannak memória ugrások..és egy egyszerû indexelésnél is szépen átfutt a proci a memóriblokk elejétõl az indexelni kívánt elemig.."
Nem egészen értem, hogy ez mi akar lenni.
"A másik meg,hogy mi a faszomért van még mindig az XP-ben a már 15 éves kód ami a 21 szoftware megszakításon van.."
DOS Kompatibilitás?
Pontosan mit is csinál ez az int 21? Én nem találtam róla semmit a winnel kapcsolatban.
Én nem tudom, nekem egyszerûen nem akar lassú lenni. Biztos rosszul csinálok valamit.
"Rengeteg egymásba ágyazott FOR ciklus van a forráskódba,ahelyett,hogy a pointerekkel dolgoznának ami valamivel több logikát feltételez a programozótól.."
Te láttad már az XP forráskódját?
"egy egyszerû for ciklussal indexel a memóriába pl:
for (int i=0; i<valami; i++)
for (int j= ...
for (..
for ... és így tovább közben meg vannak memória ugrások..és egy egyszerû indexelésnél is szépen átfutt a proci a memóriblokk elejétõl az indexelni kívánt elemig.."
Nem egészen értem, hogy ez mi akar lenni.
"A másik meg,hogy mi a faszomért van még mindig az XP-ben a már 15 éves kód ami a 21 szoftware megszakításon van.."
DOS Kompatibilitás?
Pontosan mit is csinál ez az int 21? Én nem találtam róla semmit a winnel kapcsolatban.
#60
"Igazából az OS-be kéne beépíteni egy fix, vagy adaptív szálkezelést és meg lenne oldva a dolog. Szépen kiosztja a munkát a magok között."
Az NT kernel ezt a kezdetektõl fogva tudja.
Az NT kernel ezt a kezdetektõl fogva tudja.
#59
Ha 64 bites OS alatt egy program eléri a 64 bites regisztereket, akkor az már 64 bites program, nem?
#58
Ezt is azt is..multi opsys es vagyok. Mikor milyen kedvem van 😊)
Az ms szakemberei vagy a velük szimpatizáló és érdek társaságok biztos ,hogy mindent szépnek és jónak tartanak ami kijön az mstõl..vannak ms komponensek amiknek szabadon olvashatod a kódját..a teljes forráskódot nem könnyû beszerezni..még istennek sem..de most van valami hír itten egy gyerekrõl akit le is csuktatk érte.
Az ms szakemberei vagy a velük szimpatizáló és érdek társaságok biztos ,hogy mindent szépnek és jónak tartanak ami kijön az mstõl..vannak ms komponensek amiknek szabadon olvashatod a kódját..a teljes forráskódot nem könnyû beszerezni..még istennek sem..de most van valami hír itten egy gyerekrõl akit le is csuktatk érte.
#57
Akárhogyis van, hamarosan megtudjuk.
Ugyan a múltkor a monitoros topicban azt állítottam, hogy biztos hogy elõbb fogok venni alaplap+proci+ram-ot, mint moncsit, inkább mégis moncsit vettem 😊
De a következõ már alaplap+proci+ram lesz 😊
Remélhetõleg minimum egy x2-es athlon 64.
Bár most a kezem közé került egy 64 bites intel, majd kíváncsi leszek hogy fog menni, már oprencer is van hozzá, csak ki kell írni 😊
Ugyan a múltkor a monitoros topicban azt állítottam, hogy biztos hogy elõbb fogok venni alaplap+proci+ram-ot, mint moncsit, inkább mégis moncsit vettem 😊
De a következõ már alaplap+proci+ram lesz 😊
Remélhetõleg minimum egy x2-es athlon 64.
Bár most a kezem közé került egy 64 bites intel, majd kíváncsi leszek hogy fog menni, már oprencer is van hozzá, csak ki kell írni 😊
\"We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard\" - John F. Kennedy
#56
(Már úgy értve, azért nem futhatnak a 32 bites programok megkülönböztetés nélkül.)
#55
Talán benne volt az NDA-ban, hogy nem mondhatnak rosszat róla. 😊
#54
Õõõ, azért nem érhetik el 64 bites OS alatt a 32 bites programok a 64 bites kiterjesztéseket, mert egy 32 bites OS nem menti el a felsõ 32 bitet (+ az újabb regisztereket)? 😊 Egy 64 bites OS szépen elment mindent, ahogy kell... Így valami más oknak is kell lennie. (Szerintem egyszerûen zavart okozna a mûködésükben, egyes utasításoknak más lenne az eredménye
#53
Érdekes módon azok a szakemberek, akik betekinthettek az XP kódjába azt állították, hogy jó minõségû a kód. Gondolom Te Linuxot használsz, elvbõl...
#52
Nincs olyna nagyon sok. kb. 1%
#51
64 bites oprendszer tud futtatni 32 bites programot, de a 32 bites programok nem érhetik el a 64 bites kiterjesztéseket (mint ahogy a 16 bites programok elérhették a 32 bites kiterjesztéseket). Ennek az az oka, hogy multitask oprendszert használunk, tahát ha 32 bites oprendszerben elérhetõek volnának a 64 bites regiszterek, akkor taszkváltáskor a 32 bites oprendszer nem mentené el a 64 bites regiszterek tartalmát, mert nem tud róluk, tehát a futó szálak egymás regisztereit írnák teli. Emiatt csak 64 bites oprendszer alól érhetõ el a 64 bites mód.
#50
Ebben van némi hasonlóság, de az AMD64 arch. kihasználásához elég lehet egy recompile is, a többszálúság megoldása (mármint pl. egy adott számítási mûveleté) már alaposabb átgondolást és átírást igényelhet.
#49
Itt van egy ilyen mondat: "Under a 64-bit operating system, 64-bit, 32-bit and 16-bit (or 80286) protected mode applications may be supported."
Szerintem ez (+ a táblázat) azt jelenti, hogy egy megfelelõ 64 bites OS alatt a 64 bites programok full 64 bites módban futnak, a korábbi 32/16 bites (protected mode) programok meg compatibility módban, korlátozott lehetõségekkel (õk továbbra is úgy érzékelik, mintha 32 bites procin futnának).
Remélem, nem én értelmezem rosszul, mert így lenne - legalább valamennyire - ésszerû.
Természetesen érdemes a régebbi programokat is újrafordítani, hogy jobban kihasználják a proci képességeit.
Megjegyzem, pl. a Power CPU-knál kicsit ésszerûbben van megoldva ez a dolog. (Mint ahogy a 16/32 bites dolog is sokkal ésszerûbben volt megoldva.)
Szerintem ez (+ a táblázat) azt jelenti, hogy egy megfelelõ 64 bites OS alatt a 64 bites programok full 64 bites módban futnak, a korábbi 32/16 bites (protected mode) programok meg compatibility módban, korlátozott lehetõségekkel (õk továbbra is úgy érzékelik, mintha 32 bites procin futnának).
Remélem, nem én értelmezem rosszul, mert így lenne - legalább valamennyire - ésszerû.
Természetesen érdemes a régebbi programokat is újrafordítani, hogy jobban kihasználják a proci képességeit.
Megjegyzem, pl. a Power CPU-knál kicsit ésszerûbben van megoldva ez a dolog. (Mint ahogy a 16/32 bites dolog is sokkal ésszerûbben volt megoldva.)
#48
Más dolog tudom ,de a prg-k kihasználása/optimlizálása szempontjából hasonló lehet.
#47
Az újabb, 90nm-es (Venice-bõl butított) s.754-es Sempronokra már most is valami 35W van megadva. És ez még nem is "mobil grade".
#46
Rosszul tudod. Nézd meg a wikipediát.
http://en.wikipedia.org/wiki/AMD64
Egyedül a 64 bites windows és a linux tud futtatni 32 bitre fordított programokat 64 bites módban, de alapjában véve nincs bináris kompatibilitás.
http://en.wikipedia.org/wiki/AMD64
Egyedül a 64 bites windows és a linux tud futtatni 32 bitre fordított programokat 64 bites módban, de alapjában véve nincs bináris kompatibilitás.
\"We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard\" - John F. Kennedy
#45
Kicsit bõvebben: az utasítások 64 bites változatait csak néha használják, ennél talán fontosabb a 64 bites üzemmódban rendelkezésre álló több regiszter. Ezek a dolgok egy szálon belül hozhatnak több-kevesebb sebesség-növekedést. Max. 30%-ot szoktak írni. A több mag meg ugyebár több egyidejû szálat jelent, ami optimális esetben 2x-es, 4x-es, stb. gyorsulást jelent. (A gyakorlatban ez általában kevesebb. Fõleg most pl. Intelnél, ahol a két mag igencsak zavarja egymást a memória-hozzáférésben.)
#44
Igen.
És elvileg ez lenne az elõnye a IA-64el szemben.
És elvileg ez lenne az elõnye a IA-64el szemben.
#43
65nm +SOI és a legkisebb QC talán 100W alatt lesz.
#42
Dehogynem. Csak a driverekkel van gond. (De javítsatok ki, ha rosszul tudom, nem sokat foglalkoztam ezzel.)
#41
Hamarabb lesz 100W alatti 4 magos, mint hogy te a Holdon sétálnál. 😊
#40
Nem.
Tud 32 bites módban futni, de 32 bites szoftver nem fut el 64 bites procin, ha 64 bites módban van.
Tud 32 bites módban futni, de 32 bites szoftver nem fut el 64 bites procin, ha 64 bites módban van.
\"We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard\" - John F. Kennedy
#39
Teljesen más dolog a kettõ.
#38
Feltételezem a 64bitet az amd a 32-es kibõvitésébõl csinálta ,föleg mivel lefele konpatibilis. Igy ha az eredményeket nézzük a 32 és 64 között akkor nagyjából tudni lehet mennyi lesz 1 ,2 ,v. 4 mag esetén.
#37
Feladatkezelõnél a nézet menüben "oszlopok kiválasztása", s egy pipát tegyél be a "szálak száma" checkboxba.
/*WTF?!*/
#36
Te magadnál vagy? Én meg szeretnék a Holdon sétálni...
A történelem nagy tragédiája, hogy az Aurora helyett a Titanic süllyedt el. (Meg az, hogy a világot elárasztották a konteóhív?k...) i5-2400S 2.5GHz, HD7850 2GB, 8 GB RAM
#35
Hogy lehet megnézni, hogy hány szálon fut egy folyamat? :$
#34
Kedves AMD!
Lecci csinaljatok 100W alatti fogyasztasu negymagos chipeket. <#miaz>
Lecci csinaljatok 100W alatti fogyasztasu negymagos chipeket. <#miaz>
#33
De hogy jön a 32 vs 64 bit a többszálúsághoz?
#32
Ha ez igaz, igen szomorú. Hát igen, ilyenek (normális megoldása) miatt volt teljesen használható pl. egy AmigaOS akár egy 7MHz-es procin is.
#31
Hát ennyit érnek a M$ "szuper", nagyüzemi fejlesztési módszerei, hogy zöldfülû progizók hegyeit rakják a futószalag mellé!
Persze van egy rosszabb verzió is, hogy ezeket direkt rakják bele!
Persze van egy rosszabb verzió is, hogy ezeket direkt rakják bele!
Histeria est magistra vitae. Ez nem trollkodás, ez online graffiti! ;) https://suno.com/@nexus65ongs
#30
"Vagy 3d-s képet készítesz." blender alatt a 32 bit > 13p.32s. , 64 bit 9p.40s. renderidõ azonos képnél természetesen.
#29
Alapvetõen tudjátok,hogy miért olyan kibaszottúl lassú az xp? Rengeteg egymásba ágyazott FOR ciklus van a forráskódba,ahelyett,hogy a pointerekkel dolgoznának ami valamivel több logikát feltételez a programozótól..egy egyszerû for ciklussal indexel a memóriába pl:
for (int i=0; i<valami; i++)
for (int j= ...
for (..
for ... és így tovább közben meg vannak memória ugrások..és egy egyszerû indexelésnél is szépen átfutt a proci a memóriblokk elejétõl az indexelni kívánt elemig.. sok barom..így lassítják a gépet..és azért van ,hogy 4 giga ramnál is másodpercekig nyílik meg egy explorer vagy egy mappa..amit már igazán nem lehet a swappolásra fogni..szarul van megirva a forráskód. A másik meg,hogy mi a faszomért van még mindig az XP-ben a már 15 éves kód ami a 21 szoftware megszakításon van..
ez kezel le gyakorlatilag szinte minden rendszer hívást..ebbõl is látszik,hogy 15 éve csak toldozgatnak foldozgatnak ..és nem érdekli õket igazán a teljesítmény orientáltság sem..
de semmi más igazán..csak billt a számláján lévõ összeg.. mi meg mehetünk kapálni
for (int i=0; i<valami; i++)
for (int j= ...
for (..
for ... és így tovább közben meg vannak memória ugrások..és egy egyszerû indexelésnél is szépen átfutt a proci a memóriblokk elejétõl az indexelni kívánt elemig.. sok barom..így lassítják a gépet..és azért van ,hogy 4 giga ramnál is másodpercekig nyílik meg egy explorer vagy egy mappa..amit már igazán nem lehet a swappolásra fogni..szarul van megirva a forráskód. A másik meg,hogy mi a faszomért van még mindig az XP-ben a már 15 éves kód ami a 21 szoftware megszakításon van..
ez kezel le gyakorlatilag szinte minden rendszer hívást..ebbõl is látszik,hogy 15 éve csak toldozgatnak foldozgatnak ..és nem érdekli õket igazán a teljesítmény orientáltság sem..
de semmi más igazán..csak billt a számláján lévõ összeg.. mi meg mehetünk kapálni
#28
Viszont egy tömörítési algonál már lehet blokkonként lekezelni tömöríteni.Vagy 3d-s képet készítesz..traycinget is simán lehet párhuzamosítani..
meg egy szálat fel is lehet függeszteni ..amíg várakozik egy másik eredményére. Nálam most ebben a pillanatban is kb.: 480 szálat futtat a procim. De szar ez az XP..és tényleg szar..sok hülyeségre is annyi idõt elvesz a procitól,hogy az nem igaz
meg egy szálat fel is lehet függeszteni ..amíg várakozik egy másik eredményére. Nálam most ebben a pillanatban is kb.: 480 szálat futtat a procim. De szar ez az XP..és tényleg szar..sok hülyeségre is annyi idõt elvesz a procitól,hogy az nem igaz
#27
Attól függ.
Ha a következõ számítás eredménye függ az elõzõtõl, akkor nem.
És ilyen nagyon sok van.
Ha a következõ számítás eredménye függ az elõzõtõl, akkor nem.
És ilyen nagyon sok van.
\"We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard\" - John F. Kennedy
#26
Mit nevezel általános célú mûveletnek? Egy szövegszerkesztõ vagy böngészõ funkciói, klikkelgetés egy dialógusablakon stb., ezek valóban nem olyan könnyen párhuzamosíthatók, de ki akarná ezeket párhuzamosítani? Ezeknek még 1 proci is sok :-). A számításigényes feladatok 99%-a viszont párhuzamosítható, és úgyis az a lényeg.
#25
A Framework.NET már alapból ki tudja használni a többmagos procikat, valamint a HyperThreadinget is. A Win2K3 szerverekbe már telepítéskkor jelen van a .NET 1.1, a Vistaban már a 2.0 lesz benne alapból. Remélhetõleg egyre több .NET-es program lesz. Fejleszteni is hatékonyabb alá.
#24
Igazából az OS-be kéne beépíteni egy fix, vagy adaptív szálkezelést és meg lenne oldva a dolog. Szépen kiosztja a munkát a magok között. Most még 2-4 magnál szerintem még az adaptív is tökéletesen mûködne és ha megnézitek az éppen futó programok listáját tisztán látszik, hogy bizony egy MSN is megeszik 10 szálat egy irc kliens 5-öt egy firefox 9-et és akkor a rendszerrõl még nem is beszéltem ami jelen esetben nálam 81 szálat jelent 😊
Eladó tablet PC http://hardverapro.hu/apro/hp_tx2590eo_2/hsz_1-50.html
#23
Ott könnyû párhuzamosítani. Általános célú mûveleteknél azért nem annyira.
\"We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard\" - John F. Kennedy
#22
"AMD64-re nincs értelme cserélni, 3800+ sebesség miatt sem. " azért jó az ,csak program kell alá
#21
Mi van veled freddi?
Pont,hogy az a tendenci van,hogy több magot kell csinálni mert már korlátokba ütközik a kis tranyók kapcsolási sebessége. Ha nem lehet feljebb húzni..akkor 4X ezzük meg a teljesítményt ugyanazon frekvencián..
még eltelik egy pár év a teljes váltásig és komolyan fognak érvényesülni a sok multithreading alapon nyugvó programok.. ilyen alapon mûködnek a szuperszámítógépek programjai is.. Több szálon meg már most is lehet programozni.. c++ ban 5 perc alatt megkonfigolom..meg vannak elõre elkészített optimalizált sémák amiket csak be kell includolnom..a váltás meg csak annyit tesz,hogy a forráskódokat újból le kell forsítani kis változtatással. Probléma csak ott lehet ami eleve egy szálon fut. De ilyen programok a DOS ót nem nagyon jönnek ki.Gyakorlatilag ma már a lemezmûveletekre is külön szál jön létre de ezeket nem látod a taszk menedzserben..se a többit ami a programok hoznak létre..csak az execeket.
Pont,hogy az a tendenci van,hogy több magot kell csinálni mert már korlátokba ütközik a kis tranyók kapcsolási sebessége. Ha nem lehet feljebb húzni..akkor 4X ezzük meg a teljesítményt ugyanazon frekvencián..
még eltelik egy pár év a teljes váltásig és komolyan fognak érvényesülni a sok multithreading alapon nyugvó programok.. ilyen alapon mûködnek a szuperszámítógépek programjai is.. Több szálon meg már most is lehet programozni.. c++ ban 5 perc alatt megkonfigolom..meg vannak elõre elkészített optimalizált sémák amiket csak be kell includolnom..a váltás meg csak annyit tesz,hogy a forráskódokat újból le kell forsítani kis változtatással. Probléma csak ott lehet ami eleve egy szálon fut. De ilyen programok a DOS ót nem nagyon jönnek ki.Gyakorlatilag ma már a lemezmûveletekre is külön szál jön létre de ezeket nem látod a taszk menedzserben..se a többit ami a programok hoznak létre..csak az execeket.
#20
És videokártyáknál a 4-8-16-24 pájplájn? Az sem fejlõdés?
#19
A témához hozzáröffenve pedig :
Nem tartom valami nagy teljesítménynek 4 mag "összedrótozását" ez olyan Voodoo feeling-et ad a dolognak. Tudom nem a gigaherzt-ek számítanak,de végül is megtorpantak (Ghz- ügyben). Ez a több mag egylapon egy kicsit kapálózásnak tûnik. Igaz komoly teljesítményt kapunk így,de ez nem igazán fejlõdés.
Nem tartom valami nagy teljesítménynek 4 mag "összedrótozását" ez olyan Voodoo feeling-et ad a dolognak. Tudom nem a gigaherzt-ek számítanak,de végül is megtorpantak (Ghz- ügyben). Ez a több mag egylapon egy kicsit kapálózásnak tûnik. Igaz komoly teljesítményt kapunk így,de ez nem igazán fejlõdés.
Oldal 1 / 2Következő →