Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - mudrlant

Stran: [1]
1
Vývoj / Re:FPGA s Verilog na PCIe kartě
« kdy: 15. 10. 2021, 07:04:59 »
Zkusím popsat svoje zkušenosti, byť malé.
Hrál jsem si s FPGA cca před deseti lety, takže situace se mohla značně zlepšit, přesto je asi dobré si dát pozor na to, co zmíním.

- vývojová prostředí pro FPGA byla mnohdy zadarmo, ale s omezenou funkčností, např. jen pro učitá, spíše malá FPGA.
- pro přístup k DRAM nebo PCI byly dostupné generované obvody, jak řekl předřečník, ale mám dojem, že to bylo placené, čili byste stejně asi potřeboval plné IDE, ne žádnou free verzi.

O vlastní implementeci přístupu k periferiím ani neuvažujte, jednak to nejde kvůli pomalosti, jednak je to absolutně pekelná práce, začátečníkem prakticky nezvládnutelná.
- profesionální FPGA pro výkon s taktem >500 Mhz budou drahá, až bych si místo nich radši koupil desku s několika výkonými x86 a programoval multicore ...

No a dále k algoritmu vašeho úkolu. Bylo by dobré si přečíst něco o tom, jak jsou FPGA implementovaná. Brzy zjistíte, že jakýkoli obvod sice na FPGA naimplementujete, ale některé operace využíjí extrémně mnoho zdrojů FPGA, takže se vám to custom CPU ani nevleze.
Levné operace jsou sčítání, odčítání, různé přesuny a výměny bitů. Násobení je už horší, ale jsou tam dedikované násobičky typu 16x16bitů (nebo o něco více). Pokud násobíte větší integery, kvadraticky vám poroste počet zkonzumovaných násobiček. A těch tam tolik zase není.
Dělení je samozřejmě nutné se obloukem vyhýbat, na to dedikovaný obvod není a sežere vám to kus FPGA.

Nepověděl jste nám, zda pracujete s celočíselnými daty nebo floating pointem.
Pokud chcete pracovat s floaty, ani o FPGA nepřemýšlejte. Jen implementace jednoduchého FPU vám sežere hrůznou část FPGA (tedy zejména malé FPGA).
Proto FPGA mívají dnes často dedikované třeba ARM jádro na běžnou logiku - implemnetovat i RISC CPU třeba sežere i celou FPGA. Vím, že nechcete implementovat celé vlastní CPU, ale píšu to jen pro ilustraci, jak rychle můžete vyplýtvat zdroje FPGA. A kromě jednoduchých operací vám budou docházet integrované bloky SRAM (např. na registry), přičemž k jednotlivým blokům interní SRAM je omezený počet paralelních přístupů (třeba dva).

Dále k vašemu algoritmu. Říkáte, že máte radši sériovou implementaci algoritmu, ale pak spíše naznačujete, že byste chtěl paralelní frontu (pipeline). Dobře si rozmyslete, zda dokážete algoritmus vyjádřit jako pipeline s mnoha kroky.
Čím více kroků, tím lépe - využijete paralelních schopností FPGA.
Pokud pipeline nebude dost hluboká, budete to mít pomalé, protože FPGA je na čistě sériové operace pomalá (vyplývající z frekcence v řádu stovek MHZ, a toho, že na jeden takt frekvence toho mnoho nespočítáte).

Pokud tedy nemáte algoritmus, který počítá jen v integerech a fikaně nakládá s bity a je dobře paralelizovatelný do hlubokých pipeline, myslím, že si nepolepšíte a budete nepříjemně překvapen.
Na obecnou akcelaraci výpočtů bych skutečně radši nakoupil GPU nebo slušné desktopvé/serverové CPU.
FPGA dokáže urychlit jen určité, správně napsané algoritmy. Není vhodné to použít jako generalizovaný akcelerátor algoritmu, který jste si někde nachystal v C ...

2
Vývoj / Re:Objasnění chyb v C++
« kdy: 23. 02. 2020, 23:57:59 »
V C++ nejednou narazíte na to, že ne každá funkcionalita je napsána s ohledem na C++, a tudíž si tu a tam budete muset vypomoci s funkcí, která je pro C a tam pak musíte zkonvertovat typy. Základní knihovna C++ se postupně doplňuje s každou verzí, nicméně není to dokonalé a ve starších verzích kompilátoru se bez C-verzí funkcí neobejdete.

3
Vývoj / Re:Objasnění chyb v C++
« kdy: 23. 02. 2020, 23:55:21 »
Je to správné řešení, byť není tak hezké, jak bychom v C++ chtěli.
Od novější verze C++17 už existují způsoby mazání souborů, kam se nemusí předávat adresa bufferu (std::filesystem::remove()), ale s tím bych počkal, takový moderní kompilátor nemusíte mít všude, kromě toho byste se musel učit další typy.

4
Vývoj / Re:Objasnění chyb v C++
« kdy: 23. 02. 2020, 23:25:33 »
V C++ můžete s řetězci pracovat v zásadě dvojím způsobem - buď nízkoúrovňově, což se jedná o buffer se sekvencí bytů ukončený nulovým bytem (neuvažuji teď UTF16 kódování) - pokud tento buffer někam chcete předat, často předáváte jen adresu jeho pořátku (pointer typu char *).
Nebo můžete používat nějaký wrapper nad bufferem, který poskytuje obvyklé řetězcové funkce. Dřív si mnohé knihovny definovaly svůj warpper (QString, wxString, atd.), teď už jeto naštěstí standardizováno v std::string apod. třídách.

V kódu používáte funkci remove(char*), která očekává adresu nízkoúrovňového bufferu, ale vy jí předávat zaobalovací typ.
Musíte tedy v tomto případě předat adresu bufferu, který je zaobalen. std::string na to má metodu c_str(), takže v kódu použijete výraz remove(file.c_str()).

5
Vývoj / Re:SQL dotázek
« kdy: 18. 11. 2019, 21:14:52 »
A nejde to třeba jednodušeji pomoci průniku?

(SELECT jmeno FROM auta WHERE auto='Nissan')
INTERSECT
(SELECT jmeno FROM auta WHERE auto='Audi')

Jak z SQL databáze záznamy odpovídající podmínce? Názorný příklad : tabulka lidí(bez normalizovaní), která vlastní auta (pro jednoduchost značky). Chci vybrat lidi, kteří vlastní alespoň Nissan a audi (nebo alternativně řádky tabulky patřící této osobě).

6
Vývoj / Re:Uváznutí v Aktor systému
« kdy: 19. 10. 2019, 20:11:18 »
K čemu slouží zprávy OK?

Pokud Vám aktor B poskytl odpověď, proč mu znova posíláte další potvrzovací zprávy?
Pokud je to proto, aby si i aktor B byl jist, že odpověď došla, tak to je cesta do pekel - donekonečna se budou navzájem ujišťovat o tom, že si navzájem odpověděli.

V této konkrétní komunikaci je aktor A ten, kdo má zájem na výsledku a proto postačí, pokud od B dorazí odpověď.
B nemusí vědět, zda odpověď došla. Pokud by nedošla, tak ho A sám znovu upozorní.
Pokud A tedy nedostane v nějakém očekávaném časovém limitu odpověď, může se pokusit poslat požadavek znovu.

V reálném případě, kdyby požadavek měnil výrazným způsobem stav aktora B, a tudíž znova vykonaný požadavek by nežádoucím způsobem změnil opět stav B, řeší se to např. tak, že A očísluje své zprávy.
Pokud A tedy pošle znovu zprávu se stejným číslem, B už ví, že na ten požadavek odpověděl a pošle např. tutéž nacachovanou odpověď, aniž by měnil svůj stav.

Předpokládejme dva aktory A a B.
A -> B: kolik je hodin
B -> A: 19:41
A -> B: supr, díky
B -> A: není zač

7
Vývoj / Re:Rozdiely medzi F# a ocaml
« kdy: 20. 08. 2019, 18:24:28 »
Nemám přímo praktickou zkušenost s OCAML, ale řekl bych, že tam ekvivalentní konstrukce chybí, už třeba proto, že v OCAML není konstrukce na downcasting (přetypování na potomka v objektové hiararchii). V F# se využívá možností .NET runtimu, který dokáže vrátit typová metadata k objektu, či identifikovat jeho typ.

V OCAML to budete pravděpodobně donucen nějak obejít  - pokud je množina použitých typů předem známa, můžete použít discriminated union a ten pak testovat přes pattern matching, což je bohužel nepohodlné, protože budete muset data neustále zaobalovat a rozbalovat.

Jinou možností je využít objektového rozšíření OCAMLu, které je použitelné, pokud je množina typů (value: 'a) otevřená.
Tam byste třeba nadefinoval metodu to_string(), která v každém podtypu vrací jméno. I tak byste asi musel vytvořit zaobalovací typ.

Stran: [1]