Új hozzászólás Aktív témák
-
blaireau
csendes tag
Igen, ez igaz, csak ezzel nem sokra mész, mert a legtöbb helyen nem jelszó alapon védik a fontos adatokat, hanem vmi SmartCard vagy hasonlóval, ott meg ugye tökmind1...
Ez max. arra lesz jó hogy otthon hash-ütköztetést csinálj egy unixos gép passwd fájljára.
Esetleg elfelejtett ZIP jelszót törj fel. De ez eddig is ment, különösebben nem is volt nehéz, vagy sok ideig tartó mutatvány, bár ezentúl tény hogy gyorsabb lesz. -
flugi
tag
nem optimalizálás, hanem keresési feladat: Nemdeterminisztikus Polinomiális eldönhetőségi probléma. Szeretnék kérni jóindulatú értelmezést, az NP rövidítés valóban többértelmű.
Az optimalizálás természetesen magasabb bonyolultság.
Még mindig igazad van abban, amit mondasz, és ez még mindig nem arra válasz, amit én írtam. Nem az AES általános és teljes feltöréséről van szó, hanem a kódolás futtatásáról X méretű adatbázison, ami vagy ad sikeres betörést, vagy nem. Az adatbázis mindenkori mérete a mindenkori kivárható algoritmus futási idő
-
flugi
tag
válasz
#95904256
#13
üzenetére
"Egy elméletileg 100GFlops-ra képes GPU-ból mennyit lehet kicsikarni vele?"
100 GFlops-ot. Egy olyan programmal, ami azon túl, hogy kinyomja a 100 GFlopsot, nem sok mindenre használható.
Az itthoni videókártyámon (HD4670) csináltam 72 GFlop futtatást, hogy egy bazinagy mátrixot saját magával megszoroztam sokszor. Ez mondjuk legnagyobb sajátérték keresésére egy nemisolyanrossz favágó módszer, de a cél mindenképpen az volt, hogy minél nagyobb GFlopsot kapjak. Ezt úgy lehet elérni, hogy a proci folyamatosan szoroz, nem tököl indexeléssel, válogatással, és végképp nem foglalkozik elágazásokkal. A HD4670-es képes egyszerre memóriából olvasni és szorozni, egy egyszerű pipeline van benne, így a mátrixszorzásnál alig van overhead. A szorzás végén össze kell várni a threadeket, és jöhet a következő kör. Az elején és a végén van egy viszonylag lassú adatmozgatás, ami ugye PCIE limitált.
A pontos kérdés tehát az, hogy egy bizonyos algoritmus milyen gyorsan fut, illetve hogy azt a funkciót, amit az ellát, ki lehet-e váltani ekvivalens, gyorsabb algoritmussal. GPU-n például nem illik elágazást futtatni, mert attól nagyon zavarba jön a párhuzamos végrehajtás.
-
blaireau
csendes tag
Bármilyen komolyabb protokollban van egy key-exchange, amit megfelelően nagy entrópiájú véletlenszám generátorra alapoznak, tehát ezzel nem sokra jutsz.
Amit utána írsz, az pongyola és nem igaz, de maradjunk annyiban hogy NP-beli problémák NEM mindig adnak P időben ellenőrizhető eredményt, maximum az NP beli döntési problémák pl. n-SAT probléma. Az NP-beli optimalizációs problémákra a megállapításod nem igaz.
Másrészt nem értem hogy szerinted az eredménylehetőségek száma nagyságrendileg hogy lehet összemérhető a problématér méretével? Mégis micsoda? 320 proci * 4milliárd PC és a 2^128 nemhogy nem azonos nagyságrendű, de nem is azonos világegyetemben található a két szám jóformán...
Gyakorlatban az a használható input, amit én annak definiálok, TLS protokoll következő kiterjesztésében dönthetnek úgy hogy mostantól kötelező AES-256 használata, a generált kulcsok meg szintén kriptográfiailag biztonságos véletlenek.
Ezt a szintet a procik száma SOHA nem fogja elérni, egész egyszerűen azért mert fizikai korlátai vannak. Azt a procit le is kell gyártani, energiát fogyaszt etc.
-
flugi
tag
A speckó már megvan. Az implementáción még dolgoznak. Kicsit beleolvastam, sokat átvettek a Brook-ból és a CUDA-ból, nem teljesen C nyelvű lesz, de közel hozzá. Fordítóprogramokhoz előfordítókat kell csinálni majd, ez időbe telik.
Amit viszont a matekról mondtam, azt tartom. Már ma is lehet használni a LAPACK lineáralgebra csomagot CUDA gyorsítással. Nem használom, mert gyártófüggő. De ha gyártófüggetlen lesz, hülye lennék nem használni.
A CUDA egyébként jelenleg is leveszi a feladatmegosztás terhét a programozó válláról, annyit kell tenni, hogy leírsz egy kernelfüggvényt, ami lényegében a ciklusmagja lenne annak a bazinagy ciklusnak, amit minden elemre végigfuttatnál, és azt, hogy mikor melyik proci melyik elemre lesz meghívva, azt majd beütemezi a CUDA. Vagy egy hónap múlva az OpenCL driver.
És ha a programozó csak annyit lát, hogy Matrix m1 = m2 * m3; akkor neki nem is kell tudnia, hogy a háttérben a szorzás a GPGPU-n futott le, és a mátrixai végig a videómemóriában ülnek, mert úgysem elemenként kérdezi le, vagy mert csak vizualizál OpenGL - OpenCL kapcsolattal a háttérben. Mert ugye az OpenCL-ben kezelt mátrix natív és osztott textúra, amit akármikor azonnal lehet rajzolni.
-
flugi
tag
x2 x2
elvileg háromutasak, tehát gyártanak olyan lapot, amibe három teljesértékű gyors PCIE busz van, akkor x2 x3, tehát 4800 stream proci
bár a számításokat semennyire nem gyorsítja a crossfire/SLI, azt másra találták ki, legfeljebb a kommunikációban segíthet. Mindenesetre mértünk SLI bekapcsoláskor hatékonyság visszaesést, úgyhogy kikapcsolva használtuk. (PPKE ITK) -
flugi
tag
természetesen nem gondolkodásmentes a lépcső. És természetesen nem azonos a CPU a GPGPU-val, ha figyelmesen olvastál, láthattad is.
A brute force algoritmus használatához hozzáértendő a jellegzetes jelszavak adatbázisa. Nem a mindenáron adott kód feltörése a cél, hanem legalább egy felhasználó jelszavának eltalálása a kódolt jelszavak ismeretében. Ez jelenleg is versenyképes, persze a gyenge jelszavak miatt. A jövőben viszont az azonnali siker garantált.
A lépcső létezik. Az NP problémák ugye P időben ellenőrizhető eredményt adnak, és ha az eredménylehetőségek száma nagyságrendileg egybeesik a procik számával, akkor az NP probléma P időben megoldható. Az egy dolog, hogy ez általában az input méretével exponenciálisan arányos, de lassan a procik száma is elérheti azt a szintet, hogy a gyakorlatban már használható inputhoz tartozó megfejtéslehetőségszám kezelhető lesz.
-
#24
M@trixfan
addikt
Macilaci457
#10
M@trixfan
addikt
válasz
Macilaci457
#10
üzenetére
Pedig ez lesz majd a fő irány. Ráadásul a jövőben egyre általánosabb célúak lesznek a processzorok, gyakorlatilag visszatér a szoftveres renderelés. Az lesz nagyon érdekes, hogy a kapacitás növekedésével mennyire fut fel a ray tracing. Szerintem marha nagy dolog, hogy a fény-árnyék viszonyok adódnak az eljárásból és gyakorlatilag nem kell külön renderelni. Persze akkor lesz ez mérvadó, ha majd rendes sebességgel fut a ray tracing és azon a hardveren összevetni a raszterizálással.
-
Egy CPU vagy GPU piacra dobása sosem számított az év eseményének, szerintem.
És az a legkeményebb, hogy az átlag programozónak ehhez SEMMIT sem kell tudnia, mert alá fogják tenni olyan matematikai mátrixkezelő könyvtárak képében a technikát, ami magától feltérképezi a viszonyokat, és a legmegfelelőbb módon elosztja a munkát. Könnyen készíthető olyan egyszerű interfész, aminél a melót tényleg csak beönti az ember, kernelfüggvény kódolás nélkül, pusztán matekra visszavezetve.
Ezt azért kétlem. Hardvert programozni sosem volt egyszerű és ez nem olyan, mint a .NET és a VS 2008, hogy összehúzgálod és majd sz IntelliSense megmondja, mit tegyél be... Főleg ne jelentsd ki úgy, hogy a következő sorban leírod, hogy ez csak bejelentés, vagyis nem ismert, milyen osztálykönyvtárak, egyebek lesznek...
Arra azért kíváncsi leszek, mikor jönnek az első demók és azok mit tudnak majd.
-
blaireau
csendes tag
Ez így nem egészen igaz.
Attól még hogy 1 proci helyett 3200 fog számolni (mellesleg mióta azonos ez egy teljes értékű végrehajtó maggal) nem lesz feltörhető egy titkosítás brute force módszerrel.Vegyük pl. az AES-128at, nem tudom hol tart most a "verseny" de régebben a Deep Crack keretében törtek DES-t aminek a kulcshossza ugye 56 bit, tegyük fel hogy most tartunk olyan 70 bit környékén amit emberi idő alatt vissza lehet fejteni.
Mennyivel bonyolultabb bruteforce feltörni egy 128 bites kulcsot? 2^58 szor
azaz ha az első feladat megvolt 1 másodperc alatt, a másodikkal akkorra sem leszel készen amikor az univerzum megsemmisül.De még ha fel is törik egyszer brute force a 128bites kulcshosszú szimmetrikus titkosításokat. Akkor elterjed majd a 256 bit, stb.
Szimpla lineáris számítási kapacitás emeléssel nem fogsz tudni exponenciálisan növekvő problématérbeli kereséseket megoldani, ez nem ilyen egyszerű.
-
flugi
tag
Szerintem túlzás nélkül állítható, hogy az OpenCL a számítástechnika (és számítástudomány) szempontjából az év eseménye. Ehhez képest egy-egy processzor vagy videókártya bejelentés nudli.
Az OpenCL lényege az, hogy _egyszerre_ tud _többféle_ számítást gyorsító eszközt használni. Ez most jellemzően videókari, mert televan GPGPU-val. Az ATI kártyákon 2xxx-től, Nvidiákon 8xxx-től használható lesz a cucc, manapság alig kapni már olyat, ami nem ilyen.
Amellett, hogy a videókártyát jól kezeli, a Cell procit is simán kihasználja, DSP-t, egyéb célhardvert, gyorsítókártyát. A piac ki fog szélesedni, gyorsan megjelennek majd az olcsó, számítást segítő PCI vagy akár PCMCIA kártyák, alacsony fogyasztás, több gigaflop teljesítmény.
Megváltozik a titkosítási algoritmusok használatának világa, a párhuzamos brute force már ma is durva, egyetlen 4870x2 kártyán 3200 processzor eshet neki a kódfejtésnek, ami elegendően egyszerű ahhoz, hogy GPGPU-ra lehessen implementálni. Az OpenCL megjelenésével ez nem lesz hardverhez kötve. A videókártyák fejlődési ütemét megvizsgálva sejthető, hogy 2009-ben már lesz 10000 proci feletti kártya, ami már 4 nagyságrendnyi sebességnövekedés. A titkosítástudományban ki kell majd találni azt a komplexitásfogalmat, ami a GPGPU-n való implementálhatóság hiányosságait használja ki (pl. rekurzió tilalma, branching probléma, stb)
És az a legkeményebb, hogy az átlag programozónak ehhez SEMMIT sem kell tudnia, mert alá fogják tenni olyan matematikai mátrixkezelő könyvtárak képében a technikát, ami magától feltérképezi a viszonyokat, és a legmegfelelőbb módon elosztja a munkát. Könnyen készíthető olyan egyszerű interfész, aminél a melót tényleg csak beönti az ember, kernelfüggvény kódolás nélkül, pusztán matekra visszavezetve.
Most már csak egy működő OpenCL lib + driver kombó kéne, merthogy ez csak bejelentés volt...
-
waterman_
aktív tag
azért az openGl meg a directX nem igazán általános számítások elvégzésére volt eddig alkalmas. pláne kezdetben. volt egy vas ami csak grafikai számításokra volt jó. aztán fejlődtek és egyre rugalmasabbra hangolták, hogy minél több lehetősége legyen a fejlesztőknek. manapság eljutottak arra a szintre, hogy a grafikus kártyában annyira univerzális mini végrehajtó egységek vannak, hogy komolyabb trükközések nélkül is megy vele az általános célú adatkezelés. pl régebben egy double lebegőpontos akármi eltárolása veremben, aztán feldolgozása, akkora varázsolással ment, hogy nem érte meg időben. most gondolom megy ez majd egy push paranccsal is.
megnéztem a linkelt doksit, van benne egy példa, hogy miként is lehetne vektorokat összeadni gpu-n. így már elég egyszerű dolga lesz a párhuzamosan programozóknak
__global const float a* .. és már viszed is a pointert. na eddig nem volt ilyen szabadság.
különben ez volt a gond a cuda-val is meg az amd féle stream-mel is, hogy a programozó vagy nvidia vagy ati vasra írta a programjait. ha most bejön egy opencl az igen nagy lökést adhat pl a szuperszámítógépek terjedésének. mindegy milyen gyártótól van a grafkártya, a kód futni fog rajta, csak legyen dx10.1 felett a kártya. -
#10
Macilaci457
őstag
benedekco
#8
Macilaci457
őstag
Működik. Majd legfeljebb az új driverekbe beleírják.
Ha valaki olvasta a K.Group oldalát, még az is szóbajött, hogy audio processzorok kihasználatlan erőforrásait megdolgoztatnák, (pl. mobiltelefonban a DSP grafikát számol)
De elég sok cikket olvastam még egy aktív programozótól is, hogy a GPU-s renderelés nem járható út, és azóta is beszélnek róla, hogy a GPU-tól függene, különbözne a kimenet (lásd CUDA), most arra lennék kiváncsi, hogy ez mennyiben változott meg, és megoldották-e a kifogásolt dolgokat, vagy kezdjünk megint CPU Clustert építeni renderelésre?Kiváncsian várom az első renderelőket és az összehasonlításokat...
(Qouck rendering Blenderben? ;-)) -
"hogy a OpenCL 1.0 végleges" ez az uccsó bekezdben van, sztem az "a" helyett "az"-nak kéne lennie... (höhö az első hibajavításos hsz-em)
Én is arra lennék kíváncsi, hogy ez régebbi hardvereken is működik-e, vagy csak az ez utáni, esetleg most csúcs cuccokkal lesz üzemképes
-
mephi666
nagyúr
hát benéz a marketing... amúgy az opengl meg a directx pont erre van elvileg, hogy ez fogja össze a célhardvereket... erre fejlesztenek általában a fejlesztők, nem konkrétan a hardverekre... azért mondom, hogy "általában", mert újabban főleg csak a port megy és a dx10ben és az opengl-ben rejlő lehetőségeket közel nem használják ki a játékok :S lehet szerintem adagolni nyugodtan, hogy: "majd a win7 meg a cuda, meg az opencl meg a társai..." szerintem szédítés szinte nagyrészt az egész... :S
Új hozzászólás Aktív témák
- Eladó Makulátlan 16" MacBook Pro M1 Pro 16/1TB (10/16) Dobozában, ajándék tokkal.
- Logitech G923 Racing Wheel and Pedals Xbox One/PC Kormány És Pedálsor
- eladó 4db 2TB NASware WD red (WD20EFAX)
- Xiaomi Redmi Note 13 Pro+ 5G 512GB 12GB RAM - 2027. FRBRUÁRIG GARANCIÁS / akár beszámítással is
- ÚJ Lenovo LOQ 15ARP9 - 15.6" FullHD IPS 144Hz - Ryzen 7 7435HS - 24GB - 512GB - RTX 4050 - 2 év gari
- SzoftverPremium.hu
- DELL PowerEdge R640 rack szerver - 2xGold 6138 (20c/40t, 2.0/3.7GHz), 64GB RAM,4x1G, H730 1GB, áfás
- Tablet felvásárlás!! Apple iPad, iPad Mini, iPad Air, iPad Pro
- iKing.Hu - Motorola Razr 40 Ultra Glacier Blue 8 GB RAM / 256 GB tárhely Használt, karcmentes
- PROCASTER 40UNB700 40" 101cm televízió eladó
Állásajánlatok
Cég: FOTC
Város: Budapest