- Motorola Edge 60 és Edge 60 Pro - és a vas?
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Brutál akkuval érkeztek az Ulefone X16 modellek
- Betiltották a Pixel 7-et Japánban
- 200 megapixeles zoomkamerát sem kap az S26 Ultra?
- Android alkalmazások - szoftver kibeszélő topik
- Fotók, videók mobillal
- Magisk
- Xiaomi 13T és 13T Pro - nincs tétlenkedés
- Szinte csak formaság: bemutatkozott a Pixel 6 és Pixel 6 Pro
Új hozzászólás Aktív témák
-
Sotho
őstag
Aha, köszi!
Nem merek több brp5-öt futtatni egyszerre mert az utolsó stabil driverrel kékhalálozott most meg a legújabb béta van fent.
Egy wu-val 78% és még használható a gép szóval jó ez így. Arany középút hűtés szempontjából is. Ha nem kapna egyfolytába gammasugárplzárszörcsöt meglenne a 22k/ nap. De lehez találok egy pulzárt és rólam nevezik el YEEEEE
Az igen jól visszafogja a pci-e akkor a vgamat
Nem lehet valahogy tuningolni? 
-
DRB
senior tag
A 4xxx nem lekerült az OpenCL 1.2 támogatási listájáról, hanem sosem volt rajta, mivel csak az 1.0 támogatja, illetve az 1.1-ben van béta támogatás.
Ha a GPU-Z-ben nincs kipipálva az OpenCL akkor semmi más nincs, csak nincs feltelepítve. A januári Catalyst-ban még külön telepíthető formában benne van az OCL. Le kell tölteni a 13.1 Caralystot, ki kell csomagolni, a rendszernek megfelelő(32 vagy 64 bit) OCL telepítőt elindítani, majd ha feltelepült az egész pekvancot törölni, de az OpenCL telepítőjét érdemes megtartani. Nem tudom eldönteni, hogy most egy 4670-esről vagy egy 4870-esről van szó, de ha az elsőről van szó, akkor az a gáz, hogy az nem támogatja a dupla pontosságú lebegőpontos számítást, így a SETI-ben nem igen jöhet szóba(ha jól rémlik), a 4870-es nincs ilyen gond. Egyébként erről volt is szó itt korábban. -
Nálam is külön van a BOINC, mégis meg lehet csinálni. Csak OS vezió/hardver-csere előtt kell egy opti uninstall, és onnantól mindent megtehetsz, amit eddig is akartál.
Ha pedig kicsit jobban értesz hozzá, akkor pedig tudod, hogy mit lehet törölni, és mit nem - így pedig nem kell az egész BOINC mappát megtartani, csak a szükséges adatbázis fájlokat, illetve a projekt-fájlokat (de ha kifuttatod az összes csomagot (kiszámíttatod, és le is jelenteted), akkor még egy bitet sem kell megtartani (viszont akkor a projektekhez való csatlakozást meg kell ejteni a BOINC install után).
<<Illetve talán még opti uninstall sem kell; mert a lunatics-os install úgyis felülír minden olyan fájlt, ami neki kell - mást meg úgysem.>>#5061 coyote55: Több dolog alapján is teszi. A deadline csak az egyik, de nem a legfontosabb (az csak akkor lép előtérbe, ha valaminek közeledik a jelentési határideje; mert akkor azt előreveszi - ezt külön jelzi is a csomagnál). Belejátszik a sorrendiség is (ha kér a géped 5 csomagot, akkor azt egy bizonyos sorrendben kapja - ez alapján fogja kiszámítani is őket); illetve az erőforrás-megosztás is (ha valamire több pontot adsz, akkor az annak a projektnek a csomagjait többet fogja számolni). Ezen kívül pedig Te is tudod kézzel irányítani: letiltod azokat, amiket nem akarsz előrevenni, és a többit meg addig számolhatja a géped.
-
-
coyote55
őstag
-
coyote55
őstag
Igen, de az a válasz jön, hogy
2013.05.03. 21:01:11 | SETI@home | Requesting new tasks for CPU and ATI
2013.05.03. 21:01:14 | SETI@home | Scheduler request completed: got 0 new tasks
2013.05.03. 21:01:14 | SETI@home | Project has no tasks availableEz így jó? A másik magot is bekapcsolhatom?
Az átnevezett .xml fájlt nevezzem vissza, vagy hagyjam békén? -
coyote55
őstag
Eleinte sivalkodott a 6.03 applikáció hiánya miatt, aztán megunta és gőzerővel nekiállt letölteni a félbe maradt csomagokat. Most egy maggal számol szépen, de ATI nem jött még.
Kapcsoljam vissza a másik magot?
2013.05.03. 20:10:02 | SETI@home | [error] State file error: missing application file AK_v8b2_win_SSE3_AMD.exe
2013.05.03. 20:10:02 | SETI@home | [error] State file error: missing application file AK_v8b2_win_SSE3_AMD.exe
2013.05.03. 20:10:02 | SETI@home | [error] State file error: missing application file AP6_win_x86_SSE2_OpenCL_ATI_r555.exe
2013.05.03. 20:10:02 | SETI@home | [error] State file error: missing application file AP6_win_x86_SSE2_OpenCL_ATI_r555.exe
2013.05.03. 20:10:02 | SETI@home | [error] State file error: missing application file AP6_win_x86_SSE2_OpenCL_ATI_r555.exe
2013.05.03. 20:10:02 | SETI@home | [error] State file error: missing application file AP6_win_x86_SSE2_OpenCL_ATI_r555.exe
2013.05.03. 20:10:02 | SETI@home | [error] State file error: missing application file AP6_win_x86_SSE_CPU_r555.exe
2013.05.03. 20:10:02 | SETI@home | [error] State file error: missing application file AP6_win_x86_SSE_CPU_r555.exe
2013.05.03. 20:10:02 | SETI@home | [error] State file error: missing application file AP6_win_x86_SSE_CPU_r555.exe
2013.05.03. 20:10:02 | SETI@home | [error] State file error: missing application file AP6_win_x86_SSE_CPU_r555.exe
2013.05.03. 20:10:02 | SETI@home | [error] State file error: missing application file MB6_win_x86_SSE3_OpenCL_ATi_r390.exe
2013.05.03. 20:10:02 | SETI@home | [error] State file error: missing application file MB6_win_x86_SSE3_OpenCL_ATi_r390.exe
2013.05.03. 20:10:02 | SETI@home | [error] No application found for task: windows_intelx86 603 ; discarding -
#95904256
törölt tag
Jó cikk!
A legjobban ez a rész tetszett: "Azonban a csillagok fényváltozásának modelljét a Napból vették (amely, mint elhangzott, túl nyugodt, nem eléggé Nap-típusú csillag...), és így a csillagokból eredő zajt alulbecsülték egy kettes faktorral. Mivel tehát a valódi csillagok zajosabbak, a Föld-analóg bolygó detektálásához 7 tranzit, azaz 7-8 év megfigyelés szükséges."
-
-
Csak egy kérdés: az Astropulse is használ CUDA-s motort? Mert szerintem nem, így a CUDA-s gondok azt a projektet nem érinthetik.
Az Enhanced-es résznél meg a CUDA-s GPU számításos probléma meg már egész rég óta 'él' (igazán megcsinálhatnák már végre normálisra). Volt már sok olyan csomagom, ahol 2-3 CUDA-s számításos eredmény is volt, és mégsem lett konszenzus (mert a GPU-s motor szinte minden VGA-n más eredményt dobott ki).
Ettől függetlenül a letöltések (és ezzel együtt a próbák) most tényleg gondokba ütköznek (a munkahelyi gépeken még fel sem tölti az eredményeket; nemhogy új csomagokat kérne)... -
#95904256
törölt tag
1. A "h1" és "l1" fájlok az égbolt háromszögeléséhez szükséges Hanford-i és Livingston-i lézer interferometriás hullámdetektoroktól származó forrásadatok. Elvileg automatikus a kezelésük, törlésük. Bár egy jó fél évvel ezelőtt az "l1" fájlok még nem törlődtek automatikusan. Ha valamelyik fájl nincs benne a client_state.xml-ben, akkor nyugodtan lehet törölni. Ha benne van és mégis törlöd, akkor sincs baj, legfeljebb újra letölti a BOINC amint szüksége van rá.
2. Igen, a későbbiekből lehet ebből hátrány. Ugyanis a Berkley felől erőltetik hogy a BOINC által detektált processzor tulajdonságok alapján már csak a "legoptimálisabb" kliens töltődjön le. Ha jól tudom, egyelőre nincs olyan projekt ami a BOINC-ra bízná a dolgot.
3. A LIGO-k mérési adatai vannak feldarabolva a "h1" és "l1" fájlokban, ami a Föld különböző térbeli helyzetében lettek felvéve. Az Einstein@Home kliens egy, az égbolton kijelölt útvonalon keresi a pulzárok (és egyéb) források jeleit. Ha szükséges, akkor akár több fájlból, többszőr is tölt be adatot hogy az égboltról vett adatok folyamatosnak látszódjanak a memóriában.
-
#95904256
törölt tag
Még nincsenek lefixálva a dolgok, de az biztos hogy az átállás teljesen automatikus lesz. Az itt-ott elejtett mondatok alapján pedig az a kép állt össze hogy az S5R4 ugyanazt a kódot fogja használni mint az S5R3, de az SSE optimalizált kód is alapból a része lesz, így azt nem kell majd a Power User oldalról külön letölteni. Valamint az S5R4 párhuzamosan fog futni a S5R3 utolsó, lassan visszakerülő munkacsomagjaival. Egyébként eddig mindig az történt hogy az utolsó lassan visszakerülő csomagokat kiszámoltatták a belső hálózaton, de a pontokat megkapták az illetékes userek is, visszaküldés után.
-
#95904256
törölt tag
hali P.H.
Igyekeznek úgy fejleszteni a programot hogy lehetőleg minél egyszerűbben minél több platformra lehessen fordítani. Egyébként nem tudták hogy az Intel-től származó könyvtár amit használnak az azonosítja az AMD CPU-kat és azokon direkt lassabb kódot futtat. Az SSE2-es VIA és Transmeta processzorokon is a gyorsabb kód fut, ugyanis azokat nem ellenőrzi. Gondolom az Intel elfelejtette ezt az apróságot közölni. Egyébként nagy galádság hogy nem is azt csinálja hogy a ''GenuineIntel'' azonosítójú processzorokra engedélyezi a gyorsabb kódot, hanem az ''AuthenticAMD'' processzorokra tiltja. -
#95904256
törölt tag
Ugyanaz a kód fut ott is mint amit a Linux-os hostok is megkapnak.
Azon Linuxos emberkék akik kiiktatták ezt az Inteles trükköt, olyan 35% körüli gyorsulásról ( RAC emelkedésről ) számoltak be. Szerintem Windows alatt nem lesz ekkora gyorsulás tapasztalható, ugyanis nem ezek a rutinok viszik el a CPU idő nagyobb részét. -
P.H.
senior tag
Most ránéztem egy kicsit jobban, nálam 10 másodpercenként ugrik 0.01%-ot a feldolgozás, Feladatkezelő szerint 1,5-2 másodpercenként pontosan 3 MB-nyi laphibát generál (mindig pontosan ugyanannyit, 4KB-os lapokkal számolva), ekkor ebben a fél másodpercben pontosan 3 MB-tal megnő a memóriahasználat, majd visszaesik, ez egyértelmű memóriafoglalás.
Tehát egy ciklus lefutása alatt 15-20 MB-nyi új memóriát allokál (ez sok
). Lehetséges, hogy ide-oda ''másolgatja'' a 3 MB-nyi feldolgozott adatot, lehetséges, hogy a 3 MB-ok ideiglenes területek, de mindkét esetben sokkal jobb lett volna előre lefoglalt fix pufferelést használni. (Előbbi esetben, ha nem lehet helyben feldolgozni, akkor egy dual-buffer megoldás már elég lehet, utóbbi esetben egy quad- vagy nyolcas pufferrendszer non-temporal store-okkal. Legjobb persze a helyben feldolgozás lenne. Vagy az, hogy az egyszerre letöltött nagyméretű adatot - legalább részben - 512 KB cache-re optimalizálva 256 KB-os chunk-okban dolgozza fel, de ennek megoldhatósága algoritmusfüggő).
Kész lett az első két csomagom, 23 óra 4x perces feldolgozással, csomagonként 256.53 credit-ért... Egyelőre 200 MHz-es memóriák alatt reménytelen belekezdeni.
[Szerkesztve] -
#95904256
törölt tag
Az S5R2-es csomagok credit/óra értéke (ennek van valami neve?) olyan 20-30%-kal alacsonyabb mint az S5R1/S5RI esetén. Természetesen ahogy gyorsul majd a kód, ez majd változni fog.
Mit takar a ''page fault''?
Nálam nem jelentkezett még hiba.
szerk.: Megnéztem a ''Feladatkezelőben'', valóban rengeteg laphibát jelez a Windows!
Őszintén szólva nem tudom mit takar ez a jelenség...
[Szerkesztve] -
#95904256
törölt tag
Sajnálnám ha az FPU-val együtt megszűnne a 64 bites mantissza. Ráadásul jelenleg az SSE sokmindent nem tud az FPU-hoz képest. ( szögfüggvények, maradékos osztás, négyzetgyökvonás, szétbontás, logaritmus, stb. ) Illetve amit tud az lassabban tudja ha csak egy számról van szó. Itt érdekes lenne definiálni hogy mi az a ''hétköznapi életben használt'' dolog.
Az 64 bites egész osztáshoz annyit hozzátennék hogy 32 biten illetve 64 biten is kb. ugyanolyan gyors ha az FPU-t használod. Ez AMD processzoron jelent előny a DIV / IDIV utasításhoz képes. Az Intelek sajnos FPU esetén is csigalassan osztanak. Lehet hogy az ő itercációs algoritmusuk gyengébb, vagy nincs is.
A Microsoft-os megjegyzés az STDCALL -> FASTCALL váltásra vonatkozott. Most az első négy paramétert nem a vermenen kell átadni hanem regiszterekben, amikhez viszont a hívónak kell 16 bájtos illeszkedéssel helyet biztosítani a vermen. Mi a fenéért kellett váltaniuk? -
P.H.
senior tag
Jó nagy zagyvaság lett a vége, szóval
- ...nem biztos, hogy az FPU műveleteknek van jövője...
- add és sub esetében .... a gyorsulás kétszeres + pár még százalékos lehet
Viszont on is leszek: ma beindult az Einstein validálása. Felugrott a RAC mindenkinél, nekem perpillanat 992-re (egyéni csúcs). Ez megerősített abban a sejtésemben, hogy a RAC súlyozott átlag (legalábbis az utolsó nap »sokkal« erősebb), nem pedig az elmúlt pár nap/hét általános napi eredményének átlaga. -
#95904256
törölt tag
Pár napja beszéltünk róla hogy a 64 bit mennyivel is gyorsabb a 32 bitnél. Nos, az ABC@Home projektnél közel háromszorosára növekedett a sebesség. Lehet hogy első hallásra hihetetlen, hisz max. 64 / 32 = 2-szeres gyorsulást feltételez az ember, de az igazság az hogy a 32 biten feldolgozni egy ''nagy'' számot sokkal fáradtságosabb a processzornak mint 64 biten, a plusz köztes átvitelek kezelése miatt.
Végre feltelepítettem egy 64 bites Trial XP-t, így tudtam végezni magam is pár kísérletet. Az eredmény (nem) meglepő, tényleg 60-120%-os sebességnövekedést lehetett elérni az integer műveleteknél. De megjegyzem sokkal több odafigyelést igényel a 64 bites kód, ráadásul erre a Microsoft is rádobott egy lapáttal 64 biten... -
-
#95904256
törölt tag
''Egy jól megírt 64 bites kódnak kb. 2-szer gyorsabbnak kell lennie mint egy jól megírt 32 bitesnek.''
Ez hogyan kell érteni?
Mi a baj vele? Nekem érthető.
Ha fogsz egy feladatot és megírod 64 bitre, majd megírod 32 bitre, akkor azt tapasztalhatod hogy 64 bites kód kb. 2-szer gyorsabb.
Persze pl. egy logaritmus konvertáló algoritmus nem lesz gyorsabb 64 biten mint 32-őn, de mondjuk nincs is sok köze a 64 bites arhitektúrához. ( Ugyanúgy a jó öreg FPU-t fogod használni, ami már sok-sok éve változatlan. ) -
#95904256
törölt tag
Ez a screenshot kicsit elgondolkodtató... újabb ötleteket ( mi itt a cégnél csak úgy hívjuk hogy libákat ) vet fel.
Elsőre az ugrott be hogy a file I/O-n keresztül lehet megfogni még az Einstein-t. De ez elég meredek dolog, ugyanis az Einstein az idejének csak nagyon kis részében használja.
Másodszor arra gondoltam hogy a nagyon gyakori taszk váltások okozhatnak ilyet. Pl. az opera egy nagyon kis idejű időzítőt használhat. Ilyenkor az operációs rendszer ugye ide-oda váltogat a feladatok közt. Egy-egy ilyen váltás pedig több ezer órajelet is felemészthet, ami természetesen hozzáadódik a taszk idejéhez. Persze ez is csak ezredmásodperc környéki időzítésnél jelent valamit ( mondjuk ekkor is csak 1-2% eltérést jelenthet egy GHz-es processzoron ).
Tényleg milyen operációs rendszeren és processzoron futtatod?
A cache memóriás állítást pedig tartom. Kivéve ha az opera állandóan flush-olja a cache tartalmat... -
#95904256
törölt tag
Az Einsten CPU idő igénye szinte mérhetetlenül keveset ingadozik attól függően hogy mi fut a háttérben. Ez többek közt azért van így mert a cache memória tartalmának változása alig zavarja. Ha valaki valamiféle eltéréseket tapasztalt, akkor az inkább abból adódik hogy épp olyan csomagot kapott. Ugyanis a kis és nagy csomagok közt is vannak eltérések. Ezt az értük kapott kreditek kismértékű változása is mutatja. A krediteket már itt is előre kiszámolja a szerver a szükséges ciklusok alapján.
szerk.: függetlenül -> függően
[Szerkesztve] -
#95904256
törölt tag
Melyik disassemblert illetve assemblert ajánlod / használod? Nekem eddig a PE Explorer, Softice, FASM párosítás jött be a legjobban, de azért vannak vele gondjaim. Pl. a disasmolt kódok akkorák hogy a FASM már nem tudja lefordítani (512MB RAM), a Softice meg csak régebbi videokártyákkal működik, stb.
Megj.: Az Einstein magja sokkal egyszerűbb mint a SETI-é, ott mintegy 4kB az a rész ami a lényeg, a SETI-nél ez 100kB-okban ( az Intel SSEx-es math libek esetén MB-okban) mérhető.
Megj2.: A SETI-nél a már jól optimalizált FFT rutinokkal molyol a legtöbbet a masina, így gyorsítani csak úgy lehetne ha a keresések számát csökkentenénk. Erre szerintem van esély, nem is kevés... -
#95904256
törölt tag
Régebben más (ingyenes) fordítókkal próbálkoztam, de miután végig olvastam a SETI angol nyelvű fórumán az idevágó hozzászólásokat, kiderült hogy a forrást eredetileg Microsoft .NET 2003 VC++ szal fordították Windows alá és eddig másnak sem sikerült az ''open source'' kóddot máshogy lefordítani. Örülnék neki ha valaki közre adna egy ilyen forrást is. A tervem úgyis az hogy az egészet átírjam assembly-be, az mégis csak közelebb áll hozzám. Az igazi az lenne ha találnék valakit aki profi C programozásban és van kedve meg ideje ezzel bíbelődni.
-
#95904256
törölt tag
De akkor hogy jön ki a korrekt eredmény SSE-ben, ahol még rosszabb a kerekítés?
Egyfelől némi programozási készség kell hozzá és megoldható, másfelől meg én SSE2-ről beszéltem.
Átküldenéd az Einstein S5 forrást? Nem találom - én láma - sehol.
Szívesen átküldeném, de sajnos az a baj hogy az Einstein nem nyílt forráskódú, így nem tudom teljesíteni a kérést, mert nincs ilyesmi a birtokomban.
Nem lehet valahogy tuningolni? 
). Lehetséges, hogy ide-oda ''másolgatja'' a 3 MB-nyi feldolgozott adatot, lehetséges, hogy a 3 MB-ok ideiglenes területek, de mindkét esetben sokkal jobb lett volna előre lefoglalt fix pufferelést használni. (Előbbi esetben, ha nem lehet helyben feldolgozni, akkor egy dual-buffer megoldás már elég lehet, utóbbi esetben egy quad- vagy nyolcas pufferrendszer non-temporal store-okkal. Legjobb persze a helyben feldolgozás lenne. Vagy az, hogy az egyszerre letöltött nagyméretű adatot - legalább részben - 512 KB cache-re optimalizálva 256 KB-os chunk-okban dolgozza fel, de ennek megoldhatósága algoritmusfüggő).
Új hozzászólás Aktív témák
Hirdetés
- Eladó Steam kulcsok kedvező áron!
- Assassin's Creed Shadows Collector's Edition PC
- Eredeti Microsoft termékek - MEGA Akciók! Windows, Office Pro Plus, Project Pro, Visio Pro stb.
- Sea of Thieves Premium Edition és Egyéb Játékkulcsok.
- 27%-OS ÁFÁS SZÁMLA I Jogtiszta Microsoft digitális és fizikai termékek I DIGITALKEYZ.COM
- 18 éve! Billentyűzet magyarítás magyarosítás. Festés vagy lézerezés és egyebek! 3 lehetőség is van.
- Wacom Cintiq DTK-2260 - Digitális rajztábla
- Csere-Beszámítás! Corsair Dominator Platinum 2x32GB (64GB) Kit 5200MHZ DDR5
- BESZÁMÍTÁS! HP ZBook 15 G6 munkaállomás - i7 9850H 16GB DDR4 RAM 512GB SSD Quadro T2000 4GB WIN10
- Samsung Galaxy Xcover 6 Pro, 6/128 GB, Kártyafüggetlen
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest