68
-
BiroAndras #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. -
#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 :DDD -
dez #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). -
dez #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.) -
dez #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.
-
BiroAndras #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? -
BiroAndras #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. -
BiroAndras #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. -
kandeláber #59 Ha 64 bites OS alatt egy program eléri a 64 bites regisztereket, akkor az már 64 bites program, nem? -
slackface #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. -
Caro #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 :) -
dez #56 (Már úgy értve, azért nem futhatnak a 32 bites programok megkülönböztetés nélkül.) -
dez #55 Talán benne volt az NDA-ban, hogy nem mondhatnak rosszat róla. :) -
dez #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 [v. statusz bitek], mint kellene, stb.) -
kandeláber #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... -
kandeláber #52 Nincs olyna nagyon sok. kb. 1% -
kandeláber #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. -
dez #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. -
dez #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.) -
blackeagle #48 Más dolog tudom ,de a prg-k kihasználása/optimlizálása szempontjából hasonló lehet. -
dez #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". -
Caro #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. -
dez #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.) -
tehen_m #44 Igen.
És elvileg ez lenne az előnye a IA-64el szemben. -
tehen_m #43 65nm +SOI és a legkisebb QC talán 100W alatt lesz. -
dez #42 Dehogynem. Csak a driverekkel van gond. (De javítsatok ki, ha rosszul tudom, nem sokat foglalkoztam ezzel.) -
dez #41 Hamarabb lesz 100W alatti 4 magos, mint hogy te a Holdon sétálnál. :) -
Caro #40 Nem.
Tud 32 bites módban futni, de 32 bites szoftver nem fut el 64 bites procin, ha 64 bites módban van. -
dez #39 Teljesen más dolog a kettő. -
blackeagle #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. -
#36
Te magadnál vagy? Én meg szeretnék a Holdon sétálni... -
Smithy87 #35 Hogy lehet megnézni, hogy hány szálon fut egy folyamat? :$ -
RpPRO #34 Kedves AMD!
Lecci csinaljatok 100W alatti fogyasztasu negymagos chipeket.
-
dez #33 De hogy jön a 32 vs 64 bit a többszálúsághoz? -
dez #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! -
blackeagle #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. -
slackface #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