Excel (VBA)

Excel VBAに関するフォーラムです。
  • 掲示板への投稿には会員登録(無料)が必要です。会員登録がまだの方はこちら
  • 掲示板ご利用上のお願い」に反するご記入はご遠慮ください。
  • Q&A掲示板の使い方はこちらをご覧ください
トピックに返信
質問

 
VBAとC言語の処理速度比較
投稿日時: 21/11/29 09:46:45
投稿者: Sofia

VBAで作成した技術計算プログラムがあります。
基本的に、四則演算と条件分岐が複雑なプログラムで、メモリも多大に消費します。
現在1時間程度の計算時間がかかっています。
これを何とか速くしたいです。
「順次コンパイル」の設定にはしています。
 
そこで、本カテゴリとは異なるかも知れませんが、
プログラムをC言語(VisualStudio Community等)で書き直すと、速くなるでしょうか。
一般的には判断しにくいのであれば、考え方でも結構です。
 
宜しくお願い致します。

回答
投稿日時: 21/11/29 10:24:16
投稿者: QooApp

素人意見で役に立たないかもしれませんが、C系勉強していた身としてはVBより早いイメージはあります。
ただ、VBもCも今現在、基礎的な計算能力はパソコンのスペックに依存する方が大きいと思ってます。
 
昔よりCPUのクロック周波数やメモリ量も増えていますので単純な計算式を投入しても僅か数ミリ秒で完了してしまいます。
 
では、何が計算速度の阻害になるかと考えますと、書き出しの箇所になると思います。
基本的に外部への書き出しは、はるかに遅いです。
具体的な計算の量とデータがわかりませんが、結構な頻度で書き出ししていませんか?
 
例えば10万セルに1セルづつ書き込んでるとか。
 
セルやテキストファイルなどへの書き出し操作を一度スキップ(コメントアウト)してみて動作速度がどのくらいかご計測できますか?
 
少し詳細なお話を伺えますか。

回答
投稿日時: 21/11/29 10:53:51
投稿者: simple

一般的な話として、
インタプリタ言語よりコンパイル言語のほうが
速度面で有利なことは確かでしょう。
 
別言語に移植するのも良いですが、
まずはどこで時間が掛かっているかを
見極めることが必要でしょう。
すでに指摘がありましたが
出力部分がネックになることが多いです。
数分かかっていたものが数秒で済んだなどという
経験もしています。
 
純粋に計算部分だけでということなら
言語そのものの変更を考えることになります。
それはまた次のステップで議論しましょう。

回答
投稿日時: 21/11/29 10:58:15
投稿者: WinArrow
投稿者のウェブサイトに移動

VBAとCの単純比較
 
Cの方が処理時間が早いです。
 
理由
コンピュータは、全て機械語で処理します。
そこは、VBAでもCでも他の言語でも同じです。
機械後に変換することを「コンパイル」といいます。
VBAは、1行ごとにコンパイルしながら実行します。
Cを含む言語は、コンパイルをいう作業があって、それを使って実行します。
 
従って、コンパイルする時間だけVBAは処理時間が掛かることになります。
但し、データの持ち方などで、処理時間かかわるので、一般的な概念という理解をしてください。

投稿日時: 21/11/29 11:06:48
投稿者: Sofia

お二方とも、回答頂き、誠にありがとうございます。
 
シートへの出力は確かに行っていますが、それをすべて抑制した場合、
時間としては10%程度しか低減しません。
時間がかかるのは、本質的に、純粋に計算量そのものが多いためです。
 
ちなみに、VBAの「逐次コンパイル」を有効にすると、Cのようなコンパイル言語
と比較して同等の効果はあるものでしょうか?
 
宜しくお願い致します。

投稿日時: 21/11/29 11:22:57
投稿者: Sofia

WinArrow さんの引用:
VBAとCの単純比較
 
Cの方が処理時間が早いです。
 
理由
コンピュータは、全て機械語で処理します。
そこは、VBAでもCでも他の言語でも同じです。
機械後に変換することを「コンパイル」といいます。
VBAは、1行ごとにコンパイルしながら実行します。
Cを含む言語は、コンパイルをいう作業があって、それを使って実行します。
 
従って、コンパイルする時間だけVBAは処理時間が掛かることになります。
但し、データの持ち方などで、処理時間かかわるので、一般的な概念という理解をしてください。

 
回答頂き、ありがとうございます。
 
お教え下さい。
 
「1行ごとにコンパイルする」
とのことですが、例えば、forループのような場合、同じ行を何万回も通るわけですが、
1回コンパイルすれば、あとはその行に関してはコンパイルはされないのか、
そうでなければ、同じ行を通る度、何万回もコンパイルするのか、
いずれでしょう。

回答
投稿日時: 21/11/29 11:37:48
投稿者: simple

順次コンパイルによりコンパイル言語と同等程度になる、
と言ったことはありえません。
そんな嬉しいことがあればだれもそうしています。
 
p-codeかいう中間言語にいったん変換されると思います。
http://addinbox.sakura.ne.jp/Excel_Tips13.htm
こちらを参照ください。
いずれにしてもそこをユーザーがコントロールは出来ませんから
現状を受け止めるしかありません。

回答
投稿日時: 21/11/29 14:08:36
投稿者: simple

以下は、VBAから離れた余談に近いものですので、
お急ぎの方はスキップください。

数理科学を扱う方々のなかには、今回のお話のように、
アイデア段階や早く結果を得たい場合などでは、
いったんPython,MATLAB,Rなどで書いて、
その後、速度アップを目的に C++,Fortranなどに書き換える、
といったことを行う人が多いらしいですね。
 
こうした話は、"2言語問題"と呼ばれますが、
まさにこうしたことを解消する目的で作成された言語があります。
MIT関係者によって開発された"Julia"という言語です。
「Pythonのように簡単に書くことができ、
 Cのように高速に動作する言語」を実現しようとしています。
(2009年開発開始、2018年にversion1.0が完成、最新版は1.6.4です。)
 
速度面については、かなり高速です。
https://julialang.org/benchmarks/
にあるグラフが一目瞭然です。
Python、Rよりも相当早いので、VBAよりは段違いに早いと思います。
 
言語仕様としては、多重ディスパッチが特徴的です。
これは、引数の型が違えば、同一名で複数の関数を書くことができるというものです。
それ以外は、特にトリッキーな点はないと思います。(大雑把すぎるけど)
なお、普通は、ループ処理を書くと速度低下するのが一般的ですが、
この言語は、ループ処理を書いても速度の低下は少ないです。
 
また、Python や R や C さえも呼び出して使うことができ、グルー言語として秀逸です。
 
また、案外使いやすいのが、変数にユニコードが使える点です。
μ、σなどのギリシャ文字や、下付きの添え字、上付きの添え字を使ったコードが書けるので、
通常の数式にかなり近いコードにすることができます。
 
候補のひとつに加えてみてはいかがでしょうか。
以下は、余談のさらに補足です。
 
【関連書籍】は、
「1から始めるJuliaプログラミング」(進藤、佐藤著(2020))
がよいでしょう。
これに従って関連情報のありかなども知ることができます。
 
【関連サイト】
https://julialang.org/
が本家サイト。
ただし、Documentはかなり大部のものなので、すべては読めませんし、
必要もありません。
https://docs.julialang.org/en/v1/manual/performance-tips/
といった速度関係のところなど、重要部分を選んで読むことになるでしょう。
 
あとは、個人的な好みですが、以下が参考になるでしょう。
(1)
http://www.nct9.ne.jp/m_hiroi/light/julia.html
(2)
https://julia.quantecon.org/intro.html
(3)
Julia のクイックリファレンス
http://bogumilkaminski.pl/files/julia_express.pdf
 
【補足】
・上記の書籍(「1から始める・・・」)は、プログラミング経験を前提としています。
"1から始める"というのはプログラム入門者もOKということではなく(絶対分からない)、
Juliaの配列のIndexが0ではなく1から始まる点をもじった言葉の遊びでしょう。
日本語の文献では一番まとまっていると思います。
 
・関連サイトについて、
(1)は簡潔な説明に加え、例文が多く参考になります。
 (著者の多くの言語経験が生かされ、信頼性を高く感じます)
(2)は、計量経済学の専門家がいかに使うかを実践的に書いたもので参考になります。
  そのうち前半13章までの部分は、計量経済学に限らない言語そのものをテーマに
  書かれています。
(3)これは、邦訳もされている "Julia Cookbook"(入門後に読まれるとよいと思う)を
  書いた人によるものです。
  簡易なクリックリファレンスになっていて、手元に置くと便利かもしれません。

回答
投稿日時: 21/11/29 14:57:39
投稿者: WinArrow
投稿者のウェブサイトに移動

引用:
「1行ごとにコンパイルする」
とのことですが、例えば、forループのような場合、同じ行を何万回も通るわけですが、
1回コンパイルすれば、あとはその行に関してはコンパイルはされないのか、
そうでなければ、同じ行を通る都度、何万回もコンパイルするのか、
いずれでしょう。

 
Pコードにすることで実行速度は上がると思いますが、
最終的には、機械語にする必要がるから、
それが順次コンパイルなんでしょうね・・・・推測
 
昔、simpleさんから教えて頂いたことですが、
VBAは、複数の「or」条件の「if文」は、その全部がチェックされる
それまで、私は、1つでも条件に合えば、全部をチェックされることは無いと思っていました。
 
 

回答
投稿日時: 21/11/29 19:02:06
投稿者: simple

実際にどのようなコンパイルが行われるかは、公開されていないと思いますし、
ユーザーが知る必要もないと思います。
 
もし、コンパイラオプションのようなものがあって、それを変えることで
速度向上が望まれるなら、詳しく知る必要もあるかもしれませんが、そういうことはありません。
(順次コンパイルというのは、コードが入力されたらその都度、中間言語を作るというに過ぎません)
 
実際にどれだけの時間がかかるか、それだけが判断材料かと思います。
 
ということで、他の言語と比較したVBAの速度を考える材料を提示したいと思います。
 
計算は、いわゆる竹内関数(「たらいまわし関数」)というものを使ってみます。
下記の計算式です。見た目はすぐに終わりそうに見えますが、結構時間がかかるのです。
 
【VBA】-------------------------------

Sub main()
    Dim t
    t = Timer
    Debug.Print simpleTak(15, 5, 0)
    Debug.Print Timer - t
End Sub

Function simpleTak(x, y, z) As Long
    If x <= y Then
        simpleTak = y
    Else
        simpleTak = simpleTak(simpleTak(x - 1, y, z), simpleTak(y - 1, z, x), simpleTak(z - 1, x, y))
    End If
End Function

【Julia】----------------------------
function simpleTak(x, y, z) 
    if x <= y 
        y
    else
        simpleTak(simpleTak(x - 1, y, z), simpleTak(y - 1, z, x), simpleTak(z - 1, x, y))
    end
end
function main()
    a = simpleTak(15, 5, 0)
    @show a
end

@time main()    # mainを実行し、その時間を計測する

実は、例えば
https://qiita.com/alucky0707/items/b3f9ab63c63e9e6399e6
にあるように、この手の計算では、普通は"メモ化"(memoization)というのをやります。
いったん計算した値は記憶させておき、二回目以降に呼ばれたときには再計算をせずに
単に記憶しておいた値を返すようにすれば、速度はあがるのです。(アルゴリズムの工夫)
 
しかし、今回は計算速度だけに注目するということで、
実直に計算させて、純粋に計算部分のスピードを比較してみました。
 
・VBAでは  250.35 秒かかりました。(4分強ですね)
・Juliaだと  5.94 秒でした。

Cは手元にありませんが、これも数秒でしょう。(3,4秒かと思われます)
(ちなみに、Pythonだと 215.0秒でした)
 
このコードは、ファイルアクセスはなく、単純な計算だけです。
関数を何度も呼びますので、スタックが積みあがっているでしょうけど、
いずれにしても、VBAはかなり遅いことがわかります。
 
(なんとかして早くしたいという気持ちはわかりますが、所詮はBasic言語なので、
速度面では勝負にならない、ということかと思います。
ただし、広くユーザーとの接点としてExcelが機能していて、そのうえで、
特段の装備をしなくても使えること、敷居が低いことなどが評価されているものと
思います。速度を求めるなら、VBAにこだわることは得策では無いように思います。
色々な手段を試したほうがよいと思います。)
 
極端な例かもしれませんが、ひとつの材料にしていただければと思います。
 
# 藪から棒に変な言語の話をして恐縮でした。
# C,C++を検討する方針だったのであれば、それにトライされたらよろしいかと思います。
# ただ、科学計算の分野でも、それなりに進歩もしてきているということを広く知って
# いただきたく敢えて紹介しました。
 
もちろん、現行のVBAの速度向上という議論はまだ始まってはいません。
どのような種類の計算なのか、ワークシートを間に挟むことで、
思わぬ速度劣化につながっている箇所がないか、という議論はありうるものと思います。

回答
投稿日時: 21/11/30 12:26:30
投稿者: たらのり

横入失礼します
 
VBA で平均 240sec ほどの PCで、C言語で以下のプログラムを
実行しました。
Cの実行環境は、同一 PCの WSL2 です。
 
【C言語】-------------------------------

#include <stdio.h>

int tak(int x, int y, int z)
{
    if (x <= y) {
        return y;
    } else {
        return tak(tak(x-1, y, z), tak(y-1, z, x), tak(z-1, x, y));
    }
}

int main()
{
    printf("%d\n", tak(15, 5, 0));
    return 0;
}

■ 実行結果
 
$ gcc -O2 tak.c     # 最適化してます
$ time ./a.out
15

real    0m4.014s
user    0m4.015s
sys     0m0.000s

# だいたい平均のところです。ギリギリ 3秒台もありました
 
はたして、simple さんの推察のとおりでした。。。

回答
投稿日時: 21/11/30 12:28:34
投稿者: WinArrow
投稿者のウェブサイトに移動

順次の解釈ですが、
 
ステップ毎ではなく、
 
プロシジャ単位にコンパイルしている節もあります。
 
 
Sub TEST1()
Dim a As String
    a = Left(a, 1)
     
End Sub
 
Sub TEST2()
Dim B As String
    B = "AAA"
    Debug.Print lefg(B)
End Sub
 
「順次コンピル」のチェックを入れた場合
TEST1実行時はエラーにならない。
TEST2実行時、開始する前にコンパイルエラー
 
「順次コンピル」のチェックを外した場合
TEST1実行時、開始する前にコンパイルエラー
 
ステップ実行だったら、当該ステップ実行する前にエラーになるはず。
 
勿論、デバッグタブの「コンパイル」は全モジュールがチェックされるのでエラーになります。
 

回答
投稿日時: 21/11/30 17:58:27
投稿者: simple

たらのりさん、Cによる計測例、ありがとうございました。たまたまだったようです。
# 私の関数名は確かにまずかったですね。意味も考えず単純にコピペしてしまったのでした。
 
いうまでもなく、私はVBA(VB 6.0)のコンパイル方式を知らない、全くのド素人です。
ですので、以下、眉唾ものですが。
 
JuliaはJIT(just in time)コンパイラーを使っています。
最適化されており、これが速度のキモになっていると思います。
 
なお、最近のニュースで、PythonにJITコンパイラを適用して速度向上を図る"Pyjion"と
いうものが開発された由。
では、VBAにもどうだ、という気にもなりますが、
すでに後継の.Netに基づくVBもあるわけで、Microsoftが骨董品的VB 6.0に
手を入れる可能性は極めて低いと思われます。
 
つまり、今後もVBAの速度向上には期待が余り持てないと思われます。
むしろ今のものとは全く違う基盤に基づくスクリプト環境をExcelに持ち込む
可能性のほうが高いかもしれません。いっとき、そんなニュースが流れましたね。
その後は、余り聞きませんが。
 
======
与太話はこのくらいで、質問者さんから、現行の計算処理についての情報提供を
待ちたいと思います。2割のものが、全体の8割の時間を要している、といった話もあるので、
どのあたりがボトルネックになっているか、そのあたりの説明があると前に進みそうですね。

回答
投稿日時: 21/11/30 18:57:31
投稿者: たらのり

おつかれさまです
 
最初からそうすればよかったのですが、
Visual Studio 2019 に同梱されている cl.exe を使用して
先ほどの C言語のソースをコンパイル(最適化オプション /O2)
・実行すると、結果はほぼ同様か、すこしだけ早くなりました。
4sec をコンスタントに切るくらいでした。
 
# スレ汚しですみません

投稿日時: 21/12/01 08:52:39
投稿者: Sofia

皆様、活発で深い議論を展開して頂き、誠にありがとうございます。
当初からは想像できないくらい、様々なことをお教え頂きました。
 
先の投稿でも書きましたように、当方のプログラムの中で、シートへの出力にかかる時間は、
全体のおよそ10%程度で、ほとんどが純粋に計算のために費やされている状態です。
よって、これまでの皆様の議論により、C言語へ変換することにより、かなりのスピードアップが
期待できることが分かりました。
その作業は、元のVBAの量がかなり多いので、すぐには完了しません。
これからじっくり取り組みます。
 
ただ、C言語への変換に当たり、少し分からないことがあります。
 
現在、VBAで気軽にセルへのアクセスができていたもの、例えば、
Cells(i, j).Value
のようにしていたことができなくなります。
何らかのテキストファイルを中間的に作成して、入出力は
fprintf
fscanf
などを使う必要があるでしょうか。
そうすると、これまでコマンドボタン1つで、シームレスで結果をグラフ化していたことが、
中間的なテキストファイルのCSVへの変換とか、またその逆と、
あまり意味のない操作をしなければならないことになりそうで、さらにその具体的な方法も
今は分かりません。
 
この辺りに関して、フォーラムの主旨とは離れてしまい恐縮ですが、
何らかの助言を頂ければと思います。
 
宜しくお願い致します。

回答
投稿日時: 21/12/01 10:53:01
投稿者: simple

日頃からC言語を使っているわけではないので、以下はほんの参考程度で。
ネット上でよく情報を集めたうえで判断されるとよいでしょう。
 
http://nalab.mind.meiji.ac.jp/~mk/labo/studying-C/Programing-in-C.pdf
などの記事が参考になるのではないですか?(ちょっと古いですが)
「C言語 数値計算」などで検索すると、たくさん関連記事があると思います。
 
・データの取得は、CSVを経由する方法になるでしょうね。
  fscanf,sscanfなどを使うのでしょうが、直接、Excelにアクセスするものがあるかもしれません。
  (C++ならExcelを操作するライブラリーがあるそうです)
・グラフは gnuplotを呼び出すことになるでしょう。自前でグラフを書くのは負荷が大きすぎます。
http://www.yamamo10.jp/yamamoto/lecture/2007/5E_comp_app/gnuplot/html/node1.html
の一連の記事が参考になるかも。
 
いずれにしても、「C(C++)言語による数値計算」といったたぐいの本を確認されてはいかがですか?
 
------------------------
【以下、余談】
検索の合間に、「C++を使って数値計算をしている学部生へのアドバイス」というのが目に入った。
https://qiita.com/shohirose/items/d06213fe28b6ba56b012
 
| C++を使った線形代数計算の話に入る前に、まず本当にC++を使う必要があるのかよく考えてください。
| Python, Matlab, Julia等の、C++よりもプログラミングの難易度が低くて簡単に線形代数計算ができる言語があります。
| そちらの方が幸せになれます。
などとありました。(2018年時点でJuliaに言及しているのは素晴らしい。)
 
C言語は、低水準言語(つまり、機械語、または機械語に近いアセンブリ言語などの言語の総称)の
ひとつです(別に能力が低いわけではないです)。
システムの能力を最大限発揮でき、速度は最高のものが望めるものの、
数値計算に特化したものではないので、コード作成、検証などに格段の負荷があると思います。
 
一方で、Matlab,Python,Rなどの高水準言語(記述の抽象度が高く、人間が読みやすい)は、
スピードはさほど高くないものの、扱い易い利点があります。
どちらも狙おうという「欲張りな」言語がJuliaです。(←ちょっとくどかったかな)
.xlsxファイルを読み書きできるパッケージもありますし、各種のグラフ表示用パッケージもあります。(matplotlibを基にしたPyPlotパッケージ等)
追記:
「Juliaで作って学ぶベイズ統計学」という本が出版されたようです。書店で眺めてはどうですか?

回答
投稿日時: 21/12/01 13:44:05
投稿者: たらのり

おつかれさまです
 
数値計算の部分が関数として抽出できれば、UIは Excel VBA のまま
DLL として C言語で関数を作成する方法もあるかもしれません。
 
コンパイル時には 32/64 ビットを意識する必要があるようで、
ちょっと躓きました。
また、以下の記述が今どきのものなのかは分かりませんww
 
【VBA】

Private Declare PtrSafe Function tak Lib "C:\Users\foo\tak\dlltak.dll" (ByVal x As Long, ByVal y As Long, ByVal z As Long) As Long

Sub Entry()
    
    Dim t
    
    t = Timer()
    
    Debug.Print tak(15, 5, 0)

    Debug.Print Timer() - t

End Sub

 
【C】
// dlltak.c
#include <windows.h>

int APIENTRY tak(int x, int y, int z)
{
    if (x <= y) {
        return y;
    } else {
        return tak(tak(x-1, y, z), tak(y-1, z, x), tak(z-1, x, y));
    }
}

// dlltak.def
LIBRARY dlltak
    EXPORTS
    tak

 
> cl.exe dlltak.c /LD dlltak.def

■ 実行結果(何回か)
 15 
 5.554688 
 15 
 4.992188 
 15 
 4.988281 
 15 
 5.003906 

回答
投稿日時: 21/12/01 15:44:00
投稿者: Suzu

言語の話にシフトしている様ですが、気になった点があります。
 

引用:
基本的に、四則演算と条件分岐が複雑なプログラムで、メモリも多大に消費します。

 
ロジックの詳細は判りませんが、 WinArrow さんも
引用:
昔、simpleさんから教えて頂いたことですが、
VBAは、複数の「or」条件の「if文」は、その全部がチェックされる
それまで、私は、1つでも条件に合えば、全部をチェックされることは無いと思っていました。

と言っていますが、
 
条件分岐式 の構造や、式を見直す事で 速くなる事もあろうかと思います。
 
 
Cと比べるものではありませんが、
VBAを使用せず、Excelのワークシート関数や、作業列を入れることも視野にいれてはどうでしょうか。

投稿日時: 21/12/01 16:17:15
投稿者: Sofia

Suzu様、
コメントありがとうございます。
当初の投稿で書きましたように、技術計算をしています。
簡単に言うと、大規模非線形系の最適なベクトル解を求める、ようなものです。
非線形反復を収束まで、大規模連立1次方程式を何千回と解く、といった感じです。
収束のためには工夫が必要ですが、その辺りも手を尽くした結果にあります。
 
たらのり様、
おっしゃる通り、VBAをベースに、Cの部分を関数として使うことができれば、
と考えていました。
そこで、例示して頂いたプログラムに関して、お教え下さい。
// dlltak.def
の内容は、どのような役割をしているのでしょうか。
コンパイルオプションに
/LD
とあるようなので、ライブラリの指定と思われますが、
この辺の詳細を解説したサイトはありますか?
 
とりあえず、VisualStudio Communityを考えていますが、それらは通用しますか?

回答
投稿日時: 21/12/01 16:48:21
投稿者: たらのり

こんにちは
 
「dll defファイル」などをキーワードに検索すると、
たくさんサイトがヒットすると思います。
 
/LD は DLLを出力するというオプションです。
 
また、先ほどは忘れてしまったのですが、
/O2 (最適化)のオプションを付加した場合、4秒を
コンスタントに切りました。
 
僕が使用したのは Visual Studio 2019 Community
なので、問題ないと思います。
 
 
ただし、他の方からも指摘があったように、
高速化に着手するのは最終手段と考えた方がよいです。
 
まずは Excel VBA でご法度といわれているような
処理がないかなどを点検すべきだと思います。
 

回答
投稿日時: 21/12/02 23:42:09
投稿者: MMYS

VBAの処理の一部を置き換えは、C言語等で、DLLを作成して、DLL内の関数をAPIで呼び出す方法も1つの方法ですが、VB.Net等による方法もあります。
 
VB.Net や C# でライブラリを自作してVBAから呼び出します。COM相互運用機能を使うと、VBEの参照設定に自作のライブラリが現れます。あとは、VBAから自作した関数を呼び出します。
VB.Netなら構文的にVBAに近いので、習得も楽かと思います。
 
 
VBAで独自の.NETライブラリを使うには?[VB]
https://atmarkit.itmedia.co.jp/fdotnet/dotnettips/1063vbausedotnet/vbausedotnet.html
 
VBAから扱えるDLLの作成
https://excel.syogyoumujou.com/memorandum/dll_1.html
 
 
C言語でのDLL開発はC言語の経験がないと苦労するかも知れません。ポインタってメモリアドレスを理解してれば、難しくはないのですが、VBAには無い概念なので。また、メモリ管理がプログラマの責任です。初期化忘れや開放忘れが、よくあるバグの原因です。
 
 
なお、個人的には、そもそも遅いVBAは開発初期の時点で、検討から外します。
Excelでの動作は考えず、最初から、他言語で開発します。
 

回答
投稿日時: 21/12/15 09:05:23
投稿者: mattuwan44

>VBAで作成した技術計算プログラムがあります。
 
VBAで大量のループをするようなことをすると、
機械語にコンパイルされたプログラムには劣ります。
 
が、エクセルも機械語に翻訳されたプログラムです。
表計算ソフトであるエクセルの機能を存分に使い倒せば、
VBAで書いた計算より、
高速化が見込めるかも知れません。
そうすれば、多言語に移植する手間は省けるかも知れませんが、
無駄足になるかも知れません。
上手く行けば、開発は楽になるかと思います。
 
参考になれば。

回答
投稿日時: 22/02/22 15:20:41
投稿者: simple

余談^n で恐縮ですが、少し追記させていただきます。
科学技術系言語であるJuliaを紹介させていただきましたが、それに関する最近の話題です。
 
(1)
Julia言語のコア開発者たちが、開発の趣旨を熱く語った"Why We Created Julia"を公表してから
ちょうど10年が経過しました。
     Rubyのダイナミズムを備えたCのスピードが欲しい。Lispのような真のマクロを備えながら、
     Matlabのような明白で馴染みのある数学表記を備えた、同像性の言語が必要です。
     Pythonのように一般的なプログラミングに使用でき、Rのように統計が簡単で、
     Perlのように文字列処理が自然で、Matlabのように線形代数が強力で、
     シェルのようにプログラムを結合するのが得意なものが必要です。(上記から引用)
 
これを機会に、Juliaコミュニティに参加している人たち100人が、
この10年を振り返り、また将来への期待を寄せ書きした記事が公開されました。
"Why We Use Julia, 10 Years Later"
https://julialang.org/blog/2022/02/10years/
 
ユーザーには大学院生や研究者、技術系実務者などが多いようですが、
彼らがどのようにJulia言語を発見し、これをどのように活かしてきたか、などが書かれています。
楽しく拝見しました。
 
言語のすばらしさもさることながら、このコミュニティに関係する人々こそがJulia言語の財産だと
いう印象を強く持ちました。
こちらの質問者さんや、技術系の研究者さんにとって、参考になるのではないかと思い、
紹介させていただきました。(まあ、このサイトは見ていないでしょうけどねえww)
 
(2)
ついでに、このスレッドの内容に関連するかもしれない、お薦めの書籍を紹介しておきます。
上の記事の89人目のMYKEL J. KOCHENDERFER氏(とTIM A. WHEELER氏)の手になる、
optimizationに関する書籍はとてもよいと思います。
https://algorithmsbook.com/optimization/
から、PDFが無料公開されています。
(少し高いですけど書籍もMIT Pressから販売されています。)
 
すばらしいのは、殆どのアルゴリズムが疑似コードではなく、Juliaで記載されていることです。
また、書籍の図表等に使用したコードがすべてGithubで公開されている点もすばらしい。
(KOCHENDERFER氏の指導学生だったTIM A. WHEELER氏の苦労のほどが偲ばれます。)
これは見ていて飽きませんな。
 
なお、同じ著者による、
ALGORITHMS FOR DECISION MAKING
という書籍もあり、これも既にPDFが無料公開されています。(この8月には書籍も販売予定)

トピックに返信