dotNETportal.cz

Dobrý den,

Rád bych vás požádal o radu při převodu kódu z VBA do VB.

V rámci zpracování disertační práce jsem vytvořil model v Excelu, který využívá VBA. Postupným rozšiřováním modelu se stala jeho kalibrace nesnesitelně dlouhá. Rád vás požádal o odpověď jestli:

1) bude délka výpočtu výrazně kratší převodem kódu do VB nebo VB .NET (díky kompilaci zdrojového kódu)

2) jestli převod z VBA do VB bude výrazně lehčí než přepisování modelu do jiného programovacího jazyka s možností kompilace (například kolegové většinou používají fortran, o který je u nás na ústavu považován za nejrychlejší ve zpracování výpočetních úloh v porovnání s ostatními progr. jazyky).

Zdrojový kód VBA už jsem (doufám) dostatečně optimalizoval (tj. zápis a získání dat rovnou z oblastí a ne z jednotlivých buněk, deklarování proměnných atd.).

Předem díky za odpověď a přeji všem pěkný den

Jirka

1) Záleží na tom, co je to za výpočty

2) Bude lehčí na přepsání, nebude rychlejší než jazyky kompilující do nativního kódu. A Fortran - to si děláte legraci ne?

Dobrý den a díky za odpověď,

AD 1) Při kalibraci získá program zdrojová data z Excelu a pomocí VBA provede výpočet, na jehož konci zapíše výsledky zpět do Excelu. V průběhu výpočtu se provádí velká spousta matematických operací, které pracují s rozsáhlými maticemi. Pět seti řádkový kód má jednu významnou subrutinu s 250 řádky, která je zopakovaná v průběhu řešení asi 120 milionkrát. V průběhu výpočtu nekomunikuje program s Excelem. Doufám, že jsem dostatečně pochopil a popsal, jaké výpočty mám na mysli. Jde teď nějakým způsobem zhodnotit, jestli bude doba výpočtu přepsáním z VBA do VB výrazně kratší?

AD 2) Doufám, že naivita mojeho dotazu bude snesitelná, ale nejde nějak například procentuálně odhadnout, o kolik by se mohl čas provedení výpočtu zkrátit? I velmi hrubý odhad mi umožní si udělat aspoň nějakou představu, jestli se bavíme o 90-ti nebo 10-ti procentech. Ideální by bylo odhadnout procentuální poměr mezi VBA – VB. NET – jazycích kompilujících do nativního kódu.

I když je Fortran skutečně starý programovací jazyk, má stále výrazné uplatnění v akademické a inženýrské sféře. Existuje spousta názorů proč tomu tak je, ale asi ten nejsilnější je rychlost zpracování výpočtů. Pěkná diskuze na toto téma je zde (úplně poslední příspěvek stojí za přečtení).

http://www.root.cz/clanky/fortran-chrous...

Předem díky za vaši odpověď

S pozdravem

Jirka

PS: nějak jsem se předtím zapomněl přihlásit :-)

Osobně jsem prováděl opakované výpočty na datech v excelu při využití maximální kapacity počtu řádků (Excel 2003) a procházený kód byl řádově několik stovek až tisíc řádků a následně jsem přešel na práci v .NETu a rychlost se posunula cca min. o řád.

Prakticky: v excelu trval jeden kompletní výpočet třeba 10 minut, ve .NETu řádově vteřiny (a to nepočítám komplikovanější procedury v .NETu).

Takže to určitě stojí za to.

Vážení,

dovolil bych si pokračovat v předchozí diskuzi a rozšířit ji o další dotaz.

Přeložil jsem popisovaný kód z VBA do VB. Net. Použil jsem Visual Studio (VS) 2010 Tools for Office Runtime. Ve VS jsem založil nový projekt jako template „Excel Workbook“ a naiportoval jsem převáděný program (uživatelské prostředí excel, zpracování výpočtu VBA). Ve VS jsem přidal nový modul a zdrojový kód kalibrace programu napsanou ve VBA (nejkritičtější část programu délku výpočtu) jsem nakopíroval do nového modulu a provedl potřebné úpravy tak, aby kód běžel pod VB .net.

Po spuštění a porovnání programu pod VBA a VB .net jsem se nedočkal výrazného zlepšení. Při nastavení zarážky do dvanáctiny výpočtu (kalibrace) jsem dostal následující časy výpočtu (počítač - Intel® Core™ i5 CPU 760 @ 2.80 GHz 2.80 GHz, 4G RAM):

VB. net 5673 s = 94 minut

VBA 113,7 minut

což považuji za bezvýznamný rozdíl pro moje potřeby. Další změnu týkající se výkonu, kterou jsem zpozoroval, je, že program běžící pod VB. net používá pouze 14 % výkonu procesoru, oproti VBA, který běží při 25 %.

Ve VB .NET se příliš neorientuji a proto si nejsem jistý, jestli nedělám nějakou jasně začátečnickou chybu, která způsobuje nízký výkon. Proto bych se vás rád požádal o zhodnocení, jestli jsem neudělal nějakou úplně jasnou blbost. Vyždímal jsem tímto možnosti VB .NET v jeho výkonu?

Pro jistotu zde přikládám oba programy:

www.brontosaurivhimalajich.cz/Slozka/Pro...

Předem díky za vaši odpověď a taky za provoz fóra

S pozdravem

Jirka

Ten kód jistě není optimální. Namátkou uvnitř cyklů se tam dělají operace jako změny velikosti polí (REDIM()), pracuje se tam se čtením buněk z listu Excelu atd. To je asi důsledek automatického převodu z VBA do VB.NET. Takhle se nedá výrazně zrychlit. Ten kód by se musel napsat celý znovu a optimalizovat. Pak by mohl být řádově rychlejší.

ZK

Rovněž by bylo vhodné se vyhnout využívání příkazu PRESERVE pro zachování položek ve stávajícím poli při změně velikosti pole. VB to totiž udělá tak, že vytvoří nové pole o požadovaném rozměru, stávající položky do něj zkopíruje a pak přidá nové. Toto je při použití velkých polí v mnohokrát opakovaném cyklu doslova výkonostní zabiják.

Ve VB.NET lze místo toho alternativně požít DataTable, ArrayList nebo jinou kolekci, která přidávání/ubírání položek řeší rychleji.

S pozdravem

RH

Vážení,

díky za vaše odpovědi. Nahradil jsem všechny REDIM (a taky PRESERVE) metodou ArrayList a použil jsem pouze jednodimenzionální pole. Délka výpočtu se kupodivu protáhla z 94 minut na 120 minut :-).

Rozhodl jsem se přejít na Fortran. Napíšu potom, jak dopadl výsledek.

S pozdravem

Jirka

Proč používáte VSTO místo normálního VB.NET? To se potom nedivte. Data můžete čerpat z Excelového souboru aniž by s ním aplikace byla jakkoliv provázána. Kromě toho pokud jste ve VB.NET nikdy předtím nedělal, jistě tam máte spoustu naprosto zásadních nedostatků a proto je to tak pomalé. Více poradit nelze pokud nebude uveden skutečný kód.

Díky za odpověď.

VSTO jsem použil, protože to bylo uvedeno na stránkách microsoftu jako návod jak převést VBA do VB.NET

http://msdn.microsoft.com/en-us/library/...

Můj program nijak zásadně nekomunikuje s excelem. Pouze na začátku načte vstupní data a parametry a potom už pracuje izolovaně na excelovském sešitu. Na konci každé iterace hlavního cyklu programu zapisuje průběžné výsledky do sešitu. Protože však k tomu dojde 80 krát za zmíněných 120 minut, těžko se mi chce uvěřit, že to je zásední problém pro výkon programu.

Převod z VBA do VB .NET jsem si zvolil protože jsem chtěl ušetřit práci při zrychlování výpočtu mojeho programu. Avšak pokud bych měl celý kód ve VBA přepisovat do VB .NET (plus znát všechny úskalí VB .NET) tak je už jenom kousek od toho, abych přešel na programovací jazyk, který je vhodný pro věděcké aplikace (tím je zmíněný FORTRAN, protože ani F# ani C nejsou tak vhodné, zvláš pokud se jedná o "haevy computaions").

Četl jsem si článek na vašem webu o optimalizaci kódu. Většinu zmíněných optimalizací jsem zvládnul pokýt.

Jinak pokud máte zájem kouknout se do kódu, můžete jej stáhnout níže. Moc mě zajímá, co je zde špatně (i když se už začínám pomalu profilovat jiným směrem):

a) původní VBA s prvním převodem do VB. NET

http://www.brontosaurivhimalajich.cz/Slo...

b) kód ve VB .NET kde jsem odstranil REDIM z nejcitlivějších míst, viz výše

http://www.brontosaurivhimalajich.cz/Slo...

Díky

S pozdravem

Jirka

Jestli si najdu trochu času, určitě se na to podívám.

Vážení, abychom smysluplně zakončili tuto diskuzi, která začala před dvěma měsíci, dovolil bych si vás seznámit s výsledky převodu diskutovaného programu do Fortranu.

Program jsem tedy přepsal do Fortranu a pomocí OpenMP jsem výpočty distribuoval na osm jader mého procesoru. S efektivitou využití výpočetního potenciálu 67 % (tj. že samotný výpočet zatěžuje pouze 67 % výkonu jader, zbývajících 33 % je využito na režii paralelizace) trvá výpočet 9,6 sekund. Což považuji za značné zlepšení oproti 93 minutám ve VB. NET nebo 123 min. ve VBA.

Tak doufám, že se čtenáři tímto dozvěděli něco nového

S pozdravem

Jirka

dobrýý :)