- Android alkalmazások - szoftver kibeszélő topik
- Honor 200 Pro - mobilportré
- Redmi Watch 5 - formás, de egyszerű
- Déjà vu érzés a Z Flip FE specifikációját nézve.
- Samsung Galaxy S22 és S22+ - a kis vagány meg a bátyja
- Xiaomi 15 - kicsi telefon nagy energiával
- Motorola Edge 40 - jó bőr
- Milyen okostelefont vegyek?
- Google Pixel topik
- Fotók, videók mobillal
Új hozzászólás Aktív témák
-
P.H.
senior tag
válasz
#95904256
#3705
üzenetére
Page Fault azt jelenti, hogy a lapozófile-hoz kell nyúlni, mert a virtuális->lineáris címhez tartozó lap nincs a fizikai memóriában. Vagy akkor jelentkezik, ha a process inaktív volt egy ideje, és lapjainak többsége kiíródott pagefile-ba (ez nem lehet itt értelemszerűen), vagy nincs annyi fizikai memória, amennyi kellene egyszerre, és cserélődnek a lapok folyamatosan (ez sem lehet, mert 1.5GB-om van, több, mint 1GB-os a system cache).
Marad az, hogy folyamatosan új, ideiglenesen használt memóriaterületeket foglal a process, vagy folyamatosan növel valamilyen lefoglalt dinamikus memóriaterületet, esetleg GMEM_MOVABLE-ként foglal le, amit minden hozzáférés előtt lock-olni kell, hogy a kézben legyen a virtuális cím, ez, mivel movable, akár mindig más lapokra mutathat. Akármelyik is, ezeket az új lapokat első használatkor ''be kell lapozni'', hiszen allokálásnál kapott virtuális cím általában a pagefile-ra mutat, ezeket NT alatt a nullázás, átméretezésnél/reallokálásnál/lockoláskor pedig a másolás lapozza be automatice. Ezzel elég sok idő is elmegy, és a memória-sebességre is elég érzékeny lesz a process. Plusz minden lapozás/pagefault egy OS-szintű megszakítás-beolvasás(-esetleg kiírás-), és általában 4 KB-onként (gondolom, nem 4 MB-osak ezek a lapok Einstein esetében).
[Szerkesztve] -
P.H.
senior tag
válasz
#95904256
#3702
üzenetére
Nálam is már S5R2-csomagok futnak. Látom, Te is csak azt a két workunit-ot küldted vissza hajnal óta. Nálam most 7:38:50 után 31,4%, illetve 6:23:40 után 25,6%, mindezek mellett mindnél 12 millió feletti page fault-nál tartok - 4 másodpercenként 2300 körüli növekmény -, ez elég ''dinamikus'' memóriafoglalást jelenthet, S5R1 és S5RI mellett indulás után nem volt page fault). A Tieiden kívül nem láttam még S5R2-es visszaküldött csomagokat, most még nem tudom elképzelni sem a napi 2 WU utáni credit-értéket.
Mindenesetre érdekes lesz.
[Szerkesztve] -
-
válasz
#95904256
#3691
üzenetére
Most felraktam ide: [link]. Akinek még nincs meg, de szeretné, az töltheti. Ez csak az exe file, ha kell a pdb is, akkor szóljon valaki (mondjuk Ákos
), és azt is hozzácsapom.
Egyébként ez már az 'átnevezett' file, amit elég csak bemásolni a projects/einstein.phys.uwm.edu könyvtárba (a korábbi ilyen nevű file-t felülírva).
[Szerkesztve] -
#3683
concret_hp
addikt
#95904256
#3681
concret_hp
addikt
válasz
#95904256
#3681
üzenetére
nah azért a végére 4-4 óra lett 1-1 csomag, a régivel meg 4,5-5 volt azért.
de vmi van a géppel még, mert pl. superpi 3,1-re húzva 47sec az 1M, egy 1,73-on ketyegő core duo-n meg vmi 37 sec. és azért annyival nem jobb az, sőt az enyémnek sztem jobbnak kéne lennie. (viszont a gép atomgyors, csak az ilyenekkel van para)
SSE3 kliensről bővebben? (honnan kell leszedni)
jameg látom új dizájnja lett a boincnak, mondjuk nemtom mér jó, én egyből átállítóttam a régi fajta nézetre
-
válasz
#95904256
#3647
üzenetére
Amikor leírtad a teljesítményadatokat, én azt gondoltam elsőre, hogy az a procihoz tartozik, mivel nagyjából ennyit szoktak átlagos tdp-nek megadni egy-egy asztali procihoz (a max. meg még ennél is több, hiszen a BOINC maximális terhelésen használja); és nem egy komplett géphez (amiben van VGA, meg egyéb apróság; valamint egy nem épp tökéletes táp, aminek meg vesztesége is adódik). Ha ennek ellenére neked ilyen keveset esznek a gépeid (azaz, ahogy xtech2 felvetette: pl. laptopjaid vannak), akkor én tippeltem rosszul ezekről.
[Szerkesztve] -
válasz
#95904256
#3641
üzenetére
xtech2 előző hozzászólása egy kicsit elgondolkodtatott, és arra megállapításra jutottam, hogy a ''ha már számolunk, akkor számoljunk jól'' elv alapján a fenti számolásod nem igazán jó. Hiszen az egy dolog, hogy a proci teljesítménye alapján mennyi a teljesítmény, de ha pl. egy gépet összeraksz csak BOINC-ra, akkor annak nem csak a procija eszik áramot, hanem a teljes gép is. Ezért - szerintem - inkább a teljes gép felvett teljesítményével kellene számolni, hiszen a BOINC futtatásához nem elég a proci, ahhoz a teljes gép kell. Így pedig mindjárt drágább lesz egy WU...
[Szerkesztve] -
xtech2
tag
válasz
#95904256
#3643
üzenetére
helló,
nekem van itthon teljesítménymérőm, már több gépet figyeltünk, setivel és nélküle...
Pl P4 3,0Ghz @ 3,6Ghz-en +ATI 9800PRO kártyával (szerintem ez fogyaszt még sokat) 19'' TFT monitorral 300WATT, játék közben 320-330Watt... Ha üresben kikapcsoltuk a setit, akkor 190-200Wattot kapott be.
Most egy Core2Duo 6600-am van, 3,5Ghz-en, ez így 240Wattot kajál terhelve, terhelés nélkül meg 200-at. -
P.H.
senior tag
válasz
#95904256
#3641
üzenetére
Egy kicsit tovább számolva:
-a Core2 konfigod (laptop?) ma eddig 22 WU-t csinált meg, eszerint 2,86*22*30=1887 Ft lenne havonta.
- a 3600+ X2 konfigod tegnap 18 WU-t csinált meg, ez 1544 Ft lenne, /hó.
Nem tudom, melyikből számoltad, (AM2 3600+ TDP-je 65W, Core2 talán valamivel kevesebb max-on), teljes konfigot hozzávéve nem olcsó mulatság, ha komolyan csinálja valaki. ...ha nem számoltam el. És kevésbé új technológiákon előfordulhat ennél jócskán magasabb /WU-költség is.
[Szerkesztve] -
P.H.
senior tag
válasz
#95904256
#3620
üzenetére
No, most van időm válaszolni, és korábban talán szűkszavúan fogalmaztam. Ami bántotta a szemem, és most is bántja, az a ''Egy jól megírt 64 bites kódnak kb. 2-szer gyorsabbnak kell lennie mint egy jól megírt 32 bitesnek.'', illetve ''max. 64 / 32 = 2-szeres gyorsulást feltételez az ember''
Az eredmények nem lepnek meg. Közben megnéztem, mi is az ABC@Home lényege, és t''udom, hogy Te 64 bit-nél is sokkal nagyobb adatokon dolgozol általában'' (a prímkeresés miatt, teszem hozzá). Mindkét témára azt kell mondanom (megint), ezt nem SIMD, ahol ténylegesen kimondható a x-szeres gyorsulás várható.
Registerszélesség-növelés akkor hoz a konyhára, ha általa sokkal kevesebb »utasításra«, mint elemi egységre van szükség (itt most darabszámra gondolok,) az eredmény kiszámításához. 16->32 váltásnál ez mindennapi probléma lett akkoriban, mert pl. egy 65535 byte-nál nagyobb tömb megfelelő elemének címzésekor már további shift és and utasításokra volt szükség a címzésnél, amik között ráadásul erőteljes függőség is fennállt, tehát a váltás a ''napi életre'' (=szinte minden programra) hatással volt. 32 biten ez (továbbra is fenntartom) egyedi esetekben jön elő, a hétköznapi életben alig van 32 bitnél (pl. 4 GB-nél) nagyobb számítási érték, amit egész értékben számít. (FPU-ra, SSEx-re nincs hatással a 64 bites architecture - hacsak abban nem, hogy az AMD már megszellőztette, hogy nem biztos, hogy az FPU-műveleteknek nincs jövője: ''In general, 64-bit operating systems support the x87 and 3DNow! instructions in 32-bit threads; however, 64-bit operating systems may not support x87 and 3DNow!
instructions in 64-bit threads. To make it easier to later migrate from 32-bit to 64-bit code, you may want to avoid x87 and 3DNow! instructions altogether and use only SSE and SSE2 instructions when writing new 32-bit code'' Ami pedig ''may'', az a közeljövőben ''must'' szokott lenni.
Az általad használt alkalmazásokban (ABC@Home-ban és feltételezem, a Te prím-projectedben is) ''valóban 64-es adatokra van szükség'', mert annál is sokkal nagyobb egész adatokon dolgoznak. Ezesetben tartom, hogy ''viszont több, mint kétszeresen''gyorsul a feldolgozás, de nézzük részletesebben:
- add, sub esetében igaz, hogy feleannyi add és adc kell (''a plusz köztes átvitelek kezelése miatt''), de ha nem volt nagyon nyomorult a kód, akkor az adc az add után már egy másik utasítással párhuzamosan futott le, tehát itt a gyorsulás pár százalákos.
- 64 bites szorzás 32 bitben: gyors közelítésben (ESI és EDI, illetve RSI és RDI mutat a szorzóra és szorzandóra):
..mov edx,[esi+04h]
..mov ecx,[edi+04h]
..or edx,ecx
..mov edx,[edi+00h]
..mov eax,[esi+00h]
..jnz twomul
..mul edx
..jmp @continue
@twomul:
..imul edx,[esi+04h]
..imul ecx,eax
..add ecx,edx
..mul dword ptr [edi+04h]
..add edx,ecx
@continue:
- 64 bites szorzás 64 bitben:
..mov rax,[rsi]
..imul qword ptr [rdi]
Ez nem feleannyi múvelet (még ha a felső, 32 bites teszteléstől el is tekintünk), és figyelembe véve, hogy a 64 bites szorzás latency-je több, mint a 32 bitesé, akkor is több, mint háromszoros gyorsulás számítható. AMD reference szerint két 1024 bites szám szorzásához negyedannyi utasításra van szükség (256 mul, 509 adc, 255 add vs 64 mul,125 adc, 63 add), a négyszeres érték ilyen nagyságrendben konkrétan realizálható). Osztásról ne is beszéljünk.
- hozzá kell tenni, orthogonális művelet esetén 64 bites cím +4 byte, 64 bites azonnali érték +5 byte növekményt jelent az utasítás hosszában, ez itt viszont már erőteljes szávszél-csökkenést jelenthet.
''erre a Microsoft is rádobott egy lapáttal 64 biten'' Ez mit takar?
[Szerkesztve] -
P.H.
senior tag
válasz
#95904256
#3616
üzenetére
A legfrissebbre/legújabbra nem pályázok sosem, ez is nagyjából másfél éve lett összerakva, amikor a lap+2CPU+másfél kiló réz (hűtés gyanánt) kevesebben volt, mint egy 3800+ X2 önmagában.
A CPU-k így sincsenek messze a fejenkénti 100W-tól (vcore: 1.78V), és a monitorom se keveset fogyaszt napi 16-18 óra használattal, de a lélektani havi 10K áramszámlát én sem szeretném túllépni.
[Szerkesztve] -
P.H.
senior tag
válasz
#95904256
#3614
üzenetére
Én erősen gondolkodok egy 2x dualcore Opteron konfigon, a memóriák már majdnem megvannak (eddig 3 db 512-es 400 MHz regECC Corsair sorakozik a gépben, ebből kettő egyforma), ''matched pair Opteron 275'' kb. 50K Ft+posta lenne tengerentúli ebay-ről, a lap kérdéses még.
Illetve inkább az kérdéses, hogy normális dolog-e itthon ilyen gépet nevelni, ezen filozofálok már egy ideje, meg azon, hogy ez a mostani gépem annyira unikum, és annyira megszerettem, hogy nem tudok megválni tőle. Pedig a 64 bit terjedése miatt pár éven belül kevés dologra lesz jó. . -
P.H.
senior tag
válasz
#95904256
#3611
üzenetére
Csak én szoktam napi rendszerességgel nézni, hogy a csapat és a tagok hogy állnak (results, géppark, aktivitás, stb)?
Van még előnyöd bőven, majd ősszel visszatérünk a témára. (Ha most megállnál, kb. 120 nap alatt ledolgoznám, 24/7 miatt.) Amúgy megint bejöttek olyan grid-ek, amik csomagjainak végrehajtása 8-10%-kal gyorsabb, azonos creditérték mellett (10K vs 8x00 másodperc)).
[Szerkesztve] -
P.H.
senior tag
válasz
#95904256
#3608
üzenetére
Ez ''remek''
Jelenlegi pending credit-em pontosan 7000, ebből kb. 6700 vár csak validate-ra, naponta csordogál 200-300 credit nagy nehezen, már két hete.
Nem gondoltam volna, hogy a 200K creditet úgy fogom elérni (már csak 220 hiányzik), hogy ''elméletben'' már 210K meglesz... -
róland
veterán
válasz
#95904256
#3602
üzenetére
Azért gondoltam a SETI-Einstein névpárra, mert vannak más BOINC projektekkel foglalkozó topicok is, míg ezt a kettőt nagyjából egy felhasználói tábor futtatja. S eddig jól megfértek egymás mellett mindkét projekt hozzászólásai, ezért nem lenen érdemes új topicot nyitni.
-
P.H.
senior tag
válasz
#95904256
#3593
üzenetére
Ha jól sejtem, ez csak 32 biten el nem férő egészaritmetikánál érdekes. (Ezzel eddig, megvallom, lemezterület-számításnál találkoztam, de persze nem magamból kell kiindulni.) Általános felhasználásban ha egy adott eredmény tudottan 32 bit-en elfér, akkor a 64 bit nem gyorsít (persze nem is lassít), ez pedig még ma is ritka. Tudom, hogy Te 64 bit-nél is sokkal nagyobb adatokon dolgozol általában, de ismereteim szerint a 64 bit akkor tud gyorsítani, ha valóban 64-es adatokra van szükség (akkor viszont több, mint kétszeresen), illetve a kétszer több (közvetlenül nevezhető) register miatt a registernyomás csökkenése által (JPEG, movie-decoding, hasonlók esetén) monduk 1x %-kal (mivel az adat már az L1-ben van amúgy is).
(Ez a ''kétszeres gyorsulás'' mindig emlékeztet az Intel Pentium 4 doksi HT&MP fejezetére, amiben aztán a bevezetőben kimutatja, hogy ha az eljárás félig párhuzamosítható, akkor a gyorsulás 33%-os lesz)
[Szerkesztve] -
SYB
csendes tag
válasz
#95904256
#3585
üzenetére
Hi!
64 bites linux desktopra igazi szopóka, szívás van a bináris cuccokkal (Flash etc.). Mérések alapján szinte semmivel sem gyorsabb, 4GB+-nál ajánlott a használata egyébként is. Ha mégis megpróbálod, Ubuntut elég könnyű bekonfigolni. 64 bites kliensekről sajnos nem tudok semmit. -
#95904256
törölt tag
válasz
#95904256
#3544
üzenetére
Nah, az összes Einstein csomag elkészült a gépemen. Valamint sikerült is kapcsolatba lépni a szerverrel mert minden csomag ''Ready to report'' állapotba került. Ha jól tudom ilyenkor az eredményeket már feltöltötte a gép, csak valami visszaigozálsra vár. Hol lehet erről többet megtudni? ( Az eredmény fájlok eltűntek a BOINC könyvtáramból. )
-
válasz
#95904256
#3496
üzenetére
Kicsit korábbi problémára reagálok, de hát most jut rá időm, és energiám...
A felvetődött hosszabb idő netezés alatt nálam is megy, ráadásul SETI alatt is (Win XP, 3700+ proci 2750MHz-en, IE és FF alatt is); de ez nem mai dolog, hiszen régebben is így volt. Egy ~1 óra 41 perces csomagot böngészéssel, egyéb hálózati tevékenységek futtatásával (pl.: letöltés) 11-12 perccel több számolási idővel végez el (ugyanolyan csomagok net nélküli ideje 3-4 másodperces különbséggel azonosak voltak, míg a hálózathasználat alatti csomagok ekkora különbséggel végeznek). -
P.H.
senior tag
válasz
#95904256
#3508
üzenetére
Hát igen, mióta ráállítottam a teljes gépet, pörög rendesen...
Az idei két leállás ellenére eddig 7000 credit összejött a 9 nap alatt, a BOINCStats szerint. Vajon a S5R1 vége előtt bekerülök a top10K-ba? Most 13232. vagyok.
A jelenlegi server status szerint még 18.8 nap van (8,3xx%) hátra.
[mod]: ha már a KB/MB/GB -> KiB/MiB/GiB hülyeséget átvitte valaki, akkor a legkevesebb ez a megegyezés...
[Szerkesztve] -
#3507
concret_hp
addikt
#95904256
#3506
concret_hp
addikt
válasz
#95904256
#3506
üzenetére
apám régi fizkaikönyvével találkoztam nemrég (60as évek közepén nyomtatták) hát abban is volt 1-2 elég érdekes mértékegység
nyomás kilopond vagy vlaami ilyesmi pl.
1-2 éve láttam 1 tv műsort arról h a britek hogy ragaszkodnak a hülyeségeikhez, pl. a piacon simán csak fontban van kiírva. (mármint h 1 font tömegű árú mennyibe (hány fontba) kerül)
de valóban 1 fokkal jobbak mint az amcsik. -
-
P.H.
senior tag
válasz
#95904256
#3491
üzenetére
Tudom, hogy a csomagok között vannak eltérések, egy grid-en belül is.
Én erre céloztam: [link]. Biztos vagyok benne, hogy azonos kredit fog járni a megjelölt csomagokra (majd meglátjuk, ha végre...). És ezt bármikor meg tudom ismételni (pontosabban jelen pillanatban sajnos nem, érthető okok miatt ), kis és nagy csomagokkal egyaránt, egy tizenegynéhány tab-es Opera mellett mindig megnő a feldolgozáshoz szükséges idő, konstans kreditszám mellett.
Más programnál még nem vettem észre ilyen mértékű növekedést, pedig az Opera is úgy van beállítva, hogy csak olyan oldalon legyen mozgó/aminált elem, ahol én akarom.
''a cache memória tartalmának változása alig zavarja''
Az elmélet és a gyakorlat elméletileg nem különbözik. Gyakorlatban viszont igen. -
-
#3483
concret_hp
addikt
#95904256
#3482
-
-
-
-
-
róland
veterán
válasz
#95904256
#3401
üzenetére
Kissé cinikusan ezen hozzászólásodra kérdeztem rá: ''Az számelméleti projektek nagyrésze is ''lóg levegőben'', mert többnyire elméleti problémákkal és nem gyakorlati dolgokkal foglalkoznak. Persze ha sikerül felállítani egy elméletet, akkor lehet keresni hozzá valami haszontalan gyakorlati alkalmazást. Ami pedig alapkutatás azt nem brute-force eljárásokkal kellene kutatni. Ez olyan mint amikor az embernek elfogyott az ötlete és arra pályázik hogy majd csak lesz valami...''
-
-
P.H.
senior tag
válasz
#95904256
#3277
üzenetére
Disassemblernek a PE Explorer a legjobb választás szerintem is, bár most agyalok egy saját fejlesztésen, ami jobban megfelel az igényeimnek, esetlegesen kibővítve a későbbiekben egy (vissza)fordítóval. A másik két felsoroltat nem ismerem. Én visszafordításra egy (nem vicces
) Delphi (prancssoros) fordítóval számolnék: bár nem láttam még olyan gépet, amin az IDE-t ne fogná meg már egy 20 000 soros assembly+comment project, de kevesebb, mint egy másodperc alatt fordítja, látható erőlködés nélkül (erre utalt a fenti ''kis bevezető munka'' kifejezés is, kivenni a visszafajtett startup kódot, a resource-kat, stb).
A Einsteni így, csak kívülről nézve azért tűnt összeszedettebbnek, mert
- kisebb a memóriahasználata, sokkal
- nincs folyamatos memória-újrafoglalás (512 MB RAM mellett sem használtam swap-et, és ha lement 50-60 körülire a szabad méret, azonnal leállt, hogy nincs elég memória, Einstein 1 MB szabad RAM-mal is futott tovább)
- az Einstein-t futtató procim mindig 1-2 fokkal melegebb, mint a Seti-t futtató (utóbbi eléggé szenved 133+ FSB-n). Itt azért már elképzelhető egy valamelyest optimális L2-cache-kihasználtság is. -
P.H.
senior tag
válasz
#95904256
#3275
üzenetére
Valamikor anno, amikor elkezdtem Seti-zni, akkor nekem is volt ilyen gondolatom, hogy rászánok valamennyi időt, és átírogatom assembly-be (végülis majdnem ezt csinálom főállásban is), bele is néztem a C forrásba, de kilátástalannak tűnt erre elindulni, a forrás miatt is, és amiatt is, hogy a kliensek változnak időnként, és akkor elölről kell kezdeni az egészet.
Ha nekifognék, és lenne rá időm, én disassembly felé indulnék el, assembly -> assembly lényegesen egyszerűbb (szinte gépiesen optimalizálhatók kisebb kódrészek, egyszerűbb, mint először felfogni a teljes kód értelmét; nem kell a spec. VC++ rutinokhoz kapcsolódni, stb.), és a kliens-változások is jobban következők lennének ilyen szinten (pl. írni egy kis progit, ami két disass' kódból kijelöli a változatlan kódrészeket), és egy kis bevezető munka után a teljes átírás bármikor fordítható lesz, nem kell megvárni a teszteléssel az első teljes átírást. Mindemellett egy ilyen magas szintű fordítóval fordított kódból (ha külön nem figyelnek oda erre) egy jó disass'-szel szinte csak a kommenteket nem tudod visszaszedni.
[mod]: ezért kértem fentebb az Einstein-forrást is, hogy belenézzek, bár az jóval összeszedettebbnek tűnik, a program teljesítménye alapján. Azt nem tudtam, hogy az nem nyilvános. De egyszer, ha lesz valamennyi szabadidőm (bár lenne...), egy disass'-nyi időt rászánok.
[Szerkesztve] -
P.H.
senior tag
-
Starsky72
addikt
válasz
#95904256
#3252
üzenetére
Remélem, én is ebben bízom
egy-két példa, amit ezekszerint nem jól értelmezek:
CPU Time sec:10010 - Granted Credit:60.91
CPU TIme sec:5724 - Granted Credit:32.77
CPU TIme sec:2400 - Granted Credit:15,09
Akkor most, hogy van ez? A 4x gyorsabban elkészült csomagért, negyed annyit kaptam. Vagy lehet, hogy a csomagtól is függ és ha ugyanazt megcsináltatnám alapon, ill húzva, akkor mást tapasztalnék?
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
- FSP RAIDER S 750W 80 PLUS Silver táp
- ÁRGARANCIA!Épített KomPhone Ryzen 7 5800X 16/32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- LG 48C3 - 48" OLED evo - 4K 120Hz 1ms - NVIDIA G-Sync - FreeSync Premium - HDMI 2.1 - A9 Gen6 CPU
- ÁRGARANCIA! Épített KomPhone i5 14400F 32/64GB RAM RTX 5060Ti 8GB GAMER PC termékbeszámítással
- Microsoft Windows, Office & Vírusirtók: Akciók, Azonnali Szállítás, Garantált Minőség, Garancia!
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest