Adatsor FFT előállítása hangkártyával

Adatsor FFT előállítása hangkártyával
2016-10-10T08:00:48+02:00
2016-11-12T17:06:30+01:00
2022-10-20T03:41:52+02:00
  • Anélkül, hogy (újra) végigolvastam volna ezt a beszélgetést: azért a Google tud olyasmire keresni, hogy .NET SIMD, és utána lesz valami. Pl. Numerics in the .NET Framework meg The JIT finally proposed. JIT and SIMD are getting married. (és itt az alján a SIMD címkére kattintva lesz még másik két bejegyzés: SIMD )
    Mutasd a teljes hozzászólást!
  • Sziasztok!

    Nem felejtettem el a témát, csak kicsit kiábrándultam... Nos, tényleg jó lenne a problémát ezekkel az SSE utasításokkal végeztetni, csak mint írtam VB.Net-ben írogattam mindent, ami nem támogatja ezt.

    Lélekben felkészültem, hogy C/C++ ra kellene áttérnem, de sajnos eddig teljes kudarc. A C könyvet átolvastam (kezdőknek szóló, régi "Programozzunk C nyelven, ANSI C Turbo C..."), szerintem sikerült pár dolgot megértenem, azonban C++ feladja a leckét nekem. (Egy sima Form sem jött össze (Visual Studio 2015 Community) helló Word-el, mert 600 error volt valami sal.h-ban, szerintem magát a projectet sem sikerült összeraknom, lehet a belépési pont sem volt jó.) Mondjuk ez a hiba kissé lelombozott, visszatérek rá.

    Mindenképpen Windows rendszerben kellene maradnom, a Visual Studio tetszik, azzal sok mindent meg tudok csinálni + ingyenes kell minden téren!

    Szerintetek tanuljak c++ -t ,hogy abban csináljak mindent, vagy elég lenne a dll-eket összerakni (mátrix műveletek, regresszió, FFT, ilyesmi), amit hívogatok VB alól? Ez esetben sokat lassulna a vb.net miatt? (adatok, eredmények mozgatása egymás között, stb.) Egyáltalán lehetséges olyan dll-t összerakni c++ ban (c-ben jobb lenne, de még nem találtam VS2015-ben C-t )ami ezeket az SSE/MMX utasításokat használja? Sok a kérdés tudom, de nem szeretnék nekiállni olyasminek, ami élből kudarcra van ítélve. Valamit sajnos továbbra sem értem pontosan, hogy az AMD MMX és az Intel SSE utasításkészletei mennyire kompatibilisek egymással, szóval ha a célgépen AMD proci van, akkor arra külön dll-t kell írnom, mert abban az MMX (3D!Now) utasításokkal oldom meg a dolgokat, míg ha Intel akkor SSE2-4  másik dll-el? Olvastam róla, de az angolom nem az igazi. Mintha írták volna, hogy van átfedés közöttük, de nem értem mennyire, egymással versenyt futottak, mindegyik kijött a sajátjával, (ok mindegyik x86) nehéz ez nekem még.

    Írtátok, hogy van sok optimalizált FFT, de ragaszkodom a sajátomhoz, abba senki nem köthet bele. Max lassabb, de szerintem még mindig gyorsabb lenne ezekkel az SSE stb megoldásokkal, mintha ugyanazt az fft algoritmust sima VB.net környezetben csinálnám. Gyorsulok, kód is az enyém, csak nyerek vele. Lehet maradi vagyok, de ezt tudom tovább fejleszteni, tanulok, semmi jogi blabla (kisbetűs angol szöveg) nem akadályozhat meg.

    Tényleg kellene pár infó, hogy nekiálljak-e egyáltalán, meg lehet-e oldani így a problémát, kikerülve néhány kompatibilitási problémát, vagy nem. Időm van, tanulni még talán tudok, viszont teljesen felesleges, illetve lehetetlen feladatoknak nekiállni nem szeretnék.
    Mutasd a teljes hozzászólást!
  • eltelleni? tellni?
    Rugalmas nyelv ez :D
    Mutasd a teljes hozzászólást!
  • telleni...
    Mutasd a teljes hozzászólást!
  • Sziasztok!

    Hálás köszönet mindenkinek! Időbe fog telleni, mire összerakok egy kis programot, mindegyik rész eredménnyel tesztelve. Ha lesz eredmény, vagy további kérdésem, akkor mindenképpen jelentkezem.

    Üdv.:

    Zizikus
    Mutasd a teljes hozzászólást!
  • Erthetobben fogalmazva: nem mono samplekon dolgozik az fft, hanem 4ch samplekon.
    Tegyuk fel, hogy 2048 point float fft kell, ekkor a feldolgozashoz kell 2 2048 komplex floatot tartalmazo buffer. Ez 32kb, ha jol szamolok, ami lazan belefer az L1 cacheba, ami olyan gyors, mint a muveletvegzok.
    Na most ha atallunk monorol quad channel samplekra, akkor a muveletvegzok ugyanannyi ido akatt kepesek ssevel szamolni, mint a mono esetben, viszont az 4x akkora memory footprint miatt az L1 cache kiesik, helyette az 5x lassabb kovetkezi cache szintre kell varni. Ezt a mono->quad jellego optimizaciot neg tudjak csinalni a cpp firditok is: auto vectorization. Viszont ha ekkora meretu az adat, akkor lehet erdemes megkuzdeni a mono adat sse optjaval.
    Mutasd a teljes hozzászólást!
  • Teli olvasmanyhoz keress ra Agner Fog optimization manual-jara!
    Remekul elmagyarazza egy modern (ertsd: 2000 utani :) cpu belso mukodeset. Tovabba itt talalhatsz instruction timing tablazafokat is. Nagyon hasznos.

    Ahhoz, hogy egy 10 eves atlagos gepen/laptopon menjen, max SSE3at szabad hasznalni. Az is rengeteg utasitas, efolott mar csak keves de nagyon kenyelmes extra van: horiontalis muveletek, stringben string kereses.

    4x fft egyszerre: itt nem a multithread feldolgozasra gondoltam, mert az telejes egyertelmu, hogy meg kell csinalni, hanem arra, hogy egy trhead 4 fft algoritmuson dolgozik egyidoben. Keress ra -> mulps x86
    Ez az a=a*b muveletet nem a float tipuson hajtra vegre, hanem a float[4] tipuson. Ugy kell varialni az algot, meg az adatstrukturakat, hogy ezt a Lego kockat fel tudd hasznalni!
    Mutasd a teljes hozzászólást!
  • Part2, mert az android stock browser nek kepes scrollozni az input memot, haha

    Felreertettelek, mert azt hittem, hogy te a c forditok optimizalasi kepessegeit emeled a manmade asm fole. Ezt evrol evre kiprobaljgatjuk itt, de osszessegeben az jon ki, hogy nem rossz, de nem okosabb, mint egy 5odikes XD

    Az intrinsicben szerintem a legjobb dolog inkabb az, hogy miniatur asm dolgokat bele tud inlineolni akarhova. Az utasitassorrend meg a core2-nel sem volt mar akkora problema, mint elotte. Kerulni kell a dependency chaineket es az ugganolyan muveletvegzoket hasznalo egymas melletti utasitasokat. Remek, ha megcsinalja a fordito, de egy kenyelmes macro assemblerben sem olyan nehez erre figyelni.
    A prj, amin dolgozom sajnos nem csak msvcn fordul igy aztan az intrinsicek nem mennek macintoshon, szoval meg mindig inkabb standalone assemblert hasznalok, minthogy megprobaljam a kulonbozo forditokat ugyanarra a vegeredmenyre osztonozni voodoo magia segitsegevel ;) Nem a klasszikus debug.exe kinezeu asmra kell gondolni: a JWAsm-ban peldaul meglepoen atlathato modon lehet strukturalt-szeruen programozni.
    Mutasd a teljes hozzászólást!
  • éppen kaput hegesztek, de gyorsan idejöttem!

    By using hundreds of processor cores inside NVIDIA GPUs, cuFFT delivers the floating‐point performance of a GPU without having to develop your own custom GPU FFT implementation.

    Olyan megoldást keresek, ami nem kifejezetten egy GPU/CPU-ra van optimalizálva. Mi történik akkor, ha a programomat olyan számítógépen akarom használni, aminek alaplapjára van integrálva a videó kártya, és nem Nvidia GPU van benne, ha van benne egyáltalán? (Működik akkor is ez?)

    Bocs, ha hülyeséget kérdezek, de ilyesmikre is válasz kell, mert még nem értem teljesen.
    Mutasd a teljes hozzászólást!
  • Szoval a prociban olyan muveletvegzok vannak, mint pl
    Int/float osszeado 
    Int/float szorzo
    Bitwise muvetek
    Memory read write es cimszamitas
    Ezek 128 bit (a dragabb i7sn meg 256 bit, de mar tervben van ennek ketszerese is) adaton kepesek dolgozni, felteve hogy az adat vagy regiszterben vagy  igazitva talalhato a memoriaban.
    Kb 6 stage pipelineval dolgoznak, emiatt minimum 6x annyi fizkai regiszter is kell nekik, mint amennyit asmbol meg lehet cimezni.
    Az ugroutasitasok es memory io kivetelevel joforman egy tetszoleges programot meg lehet irni sse-ben. Es mivel ez az a mod, ahogyan a processzort a legjobban ki lehet hasznalni, nem fognak az add eax,ebx szamara kulon muveletvegzot es kulon fizikai regisztereket hasznalni, hanem a meglevo dolgokat fogjak hasznalni csokkentett utilization mellett.
    Sok dologhoz kenytelenek kulon celhardvert hasznalni, pl 80bit fpu, de ezek mar inkabb csak lassu emulaciok, kenyelmetlen dolgok a kompatibilitas vegett.
    Mutasd a teljes hozzászólást!
  • Ne akard magadnak leimplementálni. Nem leszel vele előrébb.
    Gyorsabb, biztonságosabb és valószínűleg performancia ügyileg is jobban jársz egy bejáratott, az évek során szét optimalizált könyvtárral.

    Ha már PC és sok adat, miért nem keresel valami GPU implementációt, az többet fog gyorsítani, mint az SSE ;)

    Csak a megfelelőt kell kiválasztanod, gyors google pl..
    cuFFT
    Mutasd a teljes hozzászólást!
  • Sziasztok!

    Köszönöm mindkettőtöknek a hasznos és egyelőre nekem kissé magas hozzászólásaitokat.

    Még nem nagyon hallottam eddig az SSE utasításkészletekről, de tetszik nagyon! Ami nem világos, hogy ezek az utasítások minden processzorhoz mennek? Azt láttam, hogy Intelhez lettek írva, de PC környezetben pl az AMD-is tudja ezt, vagy oda a saját 3DNow kell? (bocs, ha blődég, még nem találkoztam vele.)

    Az FFT rutinokat meg tudnám írni c++ban, esetleg ezekkel az SSE utasításokkal, mert sok példa van erre, de amit nem értek pontosan az az, hogy ha ezeket a dll-eket hívom meg mondjuk VB.net környezetből, unsafe módban, akkor az sokat lassít rajta? Mert ha igen, akkor át kell térnem c++-ra...

    Es ha kihasznalod a VB.Net-nek az unsafe lehetosegeit, akkor kene tudnod olyan hatekony kodot generaltatnod vele, mintha MSVC-vel csinalnad.

    Ezt még nem próbáltam soha, itt lesz az ideje....

    Az eddigi rutinok tudnak floatban, és double-ban is számolni, pontosabban mindegyikre van egy külön rutin, azokat hívhatom meg amelyiket szeretném. A float bőven elég ide.

    Viszont azon is el lehetne filózmi, hogy mki lenne, ha 4 fft-t csinalnal parhuzamosan: ekkor adodik a 4x speedup viszont a

    Arra gondolsz, hogy pl 4 szálat indítsak, külön adatokkal? Ez megy, sokat is segített, pontosabban akkor volt a leggyorsabb, ha annyi szálat indítok, mint amennyi mag van a CPU-ban.

    Hosszú téli estékre meglesz az elfoglaltságom már látom!

    Mennem kell dolgozni...
    Mutasd a teljes hozzászólást!
  • a hagyomanyos x86 es fpu utasitasok ezek segitsegevel vannak csak emulalva.

    Ebben biztos vagy? Úgy tudtam, hogy máig benne van a prociban az aritmetikai koprocesszor ÉS külön az SSE elektronikája. Az integer aritmetika pedig éppen a legfőbb. Csak - gondolom - a stack-es koprocesszor mikrokódot már nem fejlesztik.

    Az optimalizálás alatt meg nem a saját tudásommal akartam kérkedni (vagy álszerénykedni, ahogy gondolod), hanem arra gondoltam, hogy az SSE intrinsic-ek esetén még képes a fordító a regiszterek és az utasítás-sorrendek átmozgatására is, hogy csökkentse az egymást követő parancsok függőségét. Ráadásul ezt az aktuális processzorhoz igazítva. Elhiszem, hogy van élő ember, aki ugyanilyen hatékonyan képes erre assembly-ben, sőt hatékonyabban, magam részéről örülök, hogy ezzel nem kell terhelni az agyamat. Épp most foglalkoztam ilyennel, és az első asm kód után inkább visszatértem az intrinsic-hez, elégedett vagyok azzal, amit a fordító művel.

    A témához: egyetértek real_het javaslatával, hogy csak a szűk keresztmetszettel kell foglalkozni, azt érdemes legjobban felgyorsítani, ami az idő legnagyobb hányadát viszi el.
    Visual C++ tudtommal jól optimalizál, nincsenek tapasztalataim, de azt biztos ne cseréld le.
    Nem lehet, hogy FFT-re vannak jó ingyenes kódok? Most nem néztem utána, de ezt annyian használják, hogy biztos nem kellene újra feltalálni...
    Inkább azt várom, amikor majd az új gyorsabb kód elérhetővé válik végre... (Gyorsnál is gyorsabb Fourier-transzformáció)
    Mutasd a teljes hozzászólást!
  • Hihi! Bocsánat, valamiért nem működött a Ctrl+C...

    Intel Intrinsics Guide

    Ez a valós link
    Mutasd a teljes hozzászólást!
  • Ha van mukodo kod, akkor remek, mert abbol kell kiindulni.

    Kizarolag az fft a bottleneck?
    Ha igen, azt kene elemezni.
    Ellenorizni, hogy nem double-ban szamol, hanem float-ban (gondolom eleg a float pontossag).
    Es ha kihasznalod a VB.Net-nek az unsafe lehetosegeit, akkor kene tudnod olyan hatekony kodot generaltatnod vele, mintha MSVC-vel csinalnad. Ha nem asm-ban akarod ellenorizni, akkor ird at c++-re a bottlenecket es ellenorizd ugyanolyan adatokon a sebesseget.
    A legvegso opt meg az sse lenne, de hacsak nem talalsz valami meglevo megoldast, akkor eleg sokaig tartana, hogy 0-rol beletanulj, de biztos rengetegen leoptoltak mar.

    Nekem van egy eleg jo hagyomanyos fft implementaciom, eddig még mindenre bejott, nem volt gond a sebessegevel. En stereo 60ezer samplés FIR filtert csinaltam vele fft convolution modszerrel es meglepoen keveset fogyasztott a CPU-bol 48KHz stereo output mellett, szoval nem is akartam dovabb optolni. De nalad ugye fileok vannak, ott meg erdemes lehet...

    Mivel rengeteget kell adatot osszefesulni, emiatt en azt mondanam, hogy az SSE a szokasos 4 helyetti itt csak olyan 2-3x-et huzna rajta, de ez csak tipp. Viszont azon is el lehetne filózmi, hogy mki lenne, ha 4 fft-t csinalnal parhuzamosan: ekkor adodik a 4x speedup viszont a legelejen es a legvegen itt is adat atrendezes van illetve ekkor 4x nehezebben férsz majd el a cache-ban...
    Mutasd a teljes hozzászólást!
  • "az SSE utasításcsalád, ami szinte egy második processzor a CPU-ban"

    Igazsag szerint ez az elsodleges 'processzor', a hagyomanyos x86 es fpu utasitasok ezek segitsegevel vannak csak emulalva.

    "de ma már olyan jól optimalizálnak a fordítók (nekem kedvenc a GCC), hogy kézzel nem is tudok olyan jó kódot."

    Te lehet hogy nem :D De az fft-vel az a baj, hogy a forditokban levo autovektorizacio nem tud vele mit kezdeni, mert az adat sosem 4es csoportokban halad (ha float-rol van szo), allandoan shuffle-zni kell. Ahhoz kepest, hogy mikre kepes az sse, az forditok csak az x[]=a[]*b[]+c[] jellegu feladatokra mennek csak.
    Mutasd a teljes hozzászólást!
  • Szia!

    A linked a portfolio egyik cikkére mutat! Abból nem vettem ki mi is kell nekem belőle, de nem rossz.
    Mutasd a teljes hozzászólást!
  • Sziasztok!

    Köszi mindenkinek az ötleteket!

    real_het:

    Fájlokban lévő adatsorokat kell megjelenítenem, szűrnöm stb. Sok csatorna van a fájlokban, kb 20 000 minta csatornánként. Mindez megy, saját kóddal, de kissé lassú. Biztos vagyok benne, hogy tudnám még gyorsítani, de annyira nem, mint a programomhoz hasonló más alkalmazás teszi. Sajnos mindenképpen saját magam írt program kell, külső dll, stb nem jöhet szóba. (Ne kérdezzétek, szerintem sejtitek miért)

    polyjoe:

    Sejtettem, hogy a VB.Net miatt lesz lassabb, de reménykedek még. Olyan könnyű írni benne grafikus felületeket, formokat stb.


    (Visual C++ is lassabb lesz? Elvileg hasonló kódra fordul le nem? Tudom, hogy nem 100%-ban, de azért érzés szerint nem is teljesen másra. Használjak inkább más rendszert, Visual Studio helyett?)


    Nem vagyok biztos benne, hogy a c++ ban írt külső dll sokkal gyorsabb lenne, mert kipróbáltam (2 éve volt már), de maradtam a saját kódomnál. (ennyi idő elteltével már lehet rosszul emlékszem, de a saját verzióm nem volt annyival lassabb, hogy megérje ilyen olyan license-el bajlódni, illetve a sajátom, tudom mi van benne, plusz az alkotás öröme ugye... ) Persze lehet, hogy a köré írt VB.Net miatt lassult vissza ez a dll, nem tudom.

    Gondolkodtam még, hogy esetleg az FFT algoritmusomon (per pillanat nem is emlékszem melyik algoritmussal megy ) kellene változtatni, mert vannak újabbak is, gyorsabbak lehetnek. Persze hozzá tartozó pszeudo kódokat még nem találtam, de keresek még.

    De a legjobb az FFT céljára az SSE utasításcsalád

    Bevallom, ezt még nem értem, agyalnom kell rajta. Nem vagyok programozó matematikus, kicsit lassan megy a megértése!

    Köszi mindkettőtöknek a válaszokat, ha van még bennetek ötlet, kérlek titeket ne tartsátok magatokban!

    Jelentkezek később mindenképp!
    Mutasd a teljes hozzászólást!
  • Igazából a VB.Net meggyőződésem szerint lassú, ott nagyon sok szinten megy át a kód. Csak az FFT-t érdemes C++-ban megírni. Régen azt mondtam volna, hogy ASM, de ma már olyan jól optimalizálnak a fordítók (nekem kedvenc a GCC), hogy kézzel nem is tudok olyan jó kódot.
    És ott van némi segítség is: ciklusok kibontása, utasítások átsorrendezése stb.

    De a legjobb az FFT céljára az SSE utasításcsalád, ami szinte egy második processzor a CPU-ban: külön regiszterek és külön aritmetika 4 párhuzamos lebegőpontos művelettel. Vagyis ideális esetben legalább négyszer olyan gyors, mint a sima CPU használat. C++ alatt van hozzá egy rutincsomag, ami néha jobb, mint az ASM kód.
    Mutasd a teljes hozzászólást!
  • Amugy ha elarulod, hogy mi akar lenni ez az egesz, akkor hátha tobbet tudok segiteni.
    Mutasd a teljes hozzászólást!
  • Sokan foglalkoztak vele: Google

    A két utasitas x86, amit hasznalni kell, az a mulps es az addps. Konkretan ilyen feladatokra tervezik az altalanos celu cpu-kat meg a gpu-kat is. Szorzas es osszeadas.

    Rakerestem, hogy dsp soundcard. Háát :D Sound Blaster ZxR nevetsegesen sok penzt el lehet kolteni, de itt inkabb a hangminosegen van a hangsuly, nem pedig a matematikai teljesitmenyen. Passziv hutesu az a kis chip, ami mindent csinal. Es mar a ram is bele van integralva. Szal a hang feldolgozasahoz mar nem kell olyan nagy cucc.

    VB.Net: Hat igen ilyen messzirol hardver kozeli dolgokat iranyitani sztem joval nagyobb tudast igenyel, mint C-bol :D

    Nem gyenge az x86. 100GFlops/s folott van egy atlagos processzor is, amit az uj jatekok csak eppenhogy eldocognek. Viszont kell valami extra, amivel azt ki lehet aknazni, mint pl OpenCL vagy ASM. A vektorizacio sajna még eléggé kiforratlan a kozvetlen programozashoz kepest.
    Mutasd a teljes hozzászólást!
  • Szia!

    Köszi a választ.

    A későbbiekben mindenképpen kell majd egy DSP csip, de az külön hardverhez. A PC oldalon is kellene egy minél gyorsabb FFT algoritmus, mert ami eddig nekem van (netről dll C++, saját magam által írt VB.Net), azok lassúak. (korábban teszteltem, hogy akkor a leggyorsabb mindegyik, ha annyi szálat indítok, amennyi processzormag van (kirajzolás nélkül, csak a nyers FFT), próbáltam a kijelzést gyorsítani, de még az sem elég gyors.) Biztos van sokkal gyorsabb FFT is, mert más programok megoldják ezt villám gyorsan (esetleg hardveres gyorsítással?). Természetesen elképzelhető, hogy a VB.Net miatt ennyire lassú. Próbáljak inkább
    assembler kódban megcsinálni ezt az FFT-t?


    Mivel több száz csatorna van, több ezer mintával csatornánként, ezért gondoltam olyasmire, hogy ezeket az adatokat nem a CPU felé küldeném, hanem a hangkártya felé, dolgozzon az rajta, hátha gyorsabb. Természetesen az is játszhat, hogy egy tömb 2 indexel, így ha a 0 index tartalmazza a nyers adatot, elküldeném a hangkártyának, az hajigálja az 1 és 2 index mellé a Im és Re eredményeket.

    CPU-nak nincs erre valami cél cucca, aminek direktbe meg lehetne adni a bemenő adatokat?

    Természetesen elképzelhető, hogy blődséget akarok, akkor bocsánat.
    Mutasd a teljes hozzászólást!
  • Ez manapsag elegge ertelmetlen, mert:
    Regen egy pentium 200 mmx eppen eleg volt arra, hogy mmx nelkul elboldiguljon 2 stereo 128kbps mp3-al. Annak a vegen ott van egy fft-hez elegge hasonlito valami.
    Ma meg pusztan flops/s alapjan 1000x gyorsabb cpu-t kapsz 50-60ezer forintert.

    En osszesen 1 sound DSP chip programozasat ismerem feluletesen. Az 48KHz mintavetel mellett 512 utasitast volt kepes vegrehajtani. Jellemzoen csak samplekkel dolgozott, az egyetlen dolog, ami blokkokon ment az a hardveres delay buffer volt. Ez nem jo fft-hez. Specialis driver kellett hozza (azaz hogy en a mai napig ezt hasznalom) Es a driver tulajdonkeppen egy mini fejlesztokornyezetkent is mukodott. kX Project -- Screenshots  Ezzel az SW kornyezettel egy SB Liva valoban hangkartyakent viselkedett, de ma mar az altalanos celu hankartyaknal ez nem kovetelmeny, oda eleg par AD/DA converter az alaplapra azt' kesz.
    Mutasd a teljes hozzászólást!
  • Sziasztok!

    Hirtelen eszembe jutott, hogy a hangkártyán lévő SDP processzorával lehetséges lenne előállítani egy adatsor FFT sorát. Írtam már FFT algoritmusokat, simán a CPU dolgozza fel, külön szálon, de ezek nem annyira gyorsak, mert a CPU-nak több dolga is van, illetve nem erre van optimalizálva. Ha jól sejtem, akkor a hangkártyában lévő chip tartalmaz kifejezetten erre a problémára célhardvert.

    Windows alatt lehetséges lenne pl VB.Net alatt célzottan ennek a hardvernek küldeni adatsort feldolgozás céljából? Gyorsabb lenne?

    Köszi a válaszokat!
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd