次のテーマはいろんな言語でデータベース操作

RubyのグラフィックスはDxRubyで決まりって結論も出たし、今後もボチボチと気が向けば小さなテーマでグラフィックは弄って行くとして、次なるテーマはいろんな言語でデータベースを操作して速度とか使い勝手とかを見ていきたい。

例えば
１）Accessでmdbとaccdbを比較。特に共有
２）他の言語でMDBかAccdbを使ってみる。Ruby,C#,VB,Java
３）SQLiteをAccess,Ruby,C#,VB,Javaなどで使う。
４）H2をJavaで普通に使ってみる
※イメージはfirebirdの代替
５）他の言語でH2を使ってみる。Access,Ruby,C#,VB
６）MS SQLサーバを使う。軽い標準環境を模索する

テストでは100万件とかから検索とか３つのクライアントから１万件づつ同時に登録とかやってみたい。

DxRubyとDxRubyWSと・・・ 或いはDxRuby vs Ruby/Tk

マンデルブローの描画速度で明らかになったもっとも大きな収穫はDxRuby使えるじゃんってこと。
前項のruby-profもそうだけどruby界隈には痒い所に手がとどくようなライブラリーが結構ある。
DxRubyの作者さんが提供しているDxRubyWS(DxRuby WindowSystemだそうな）なども面白そう。（ただし３～４年ぐらい放置なのだが・・）

ゲーム用のプラットフォームで仕事用のツールはちょっとあれだけど速いは正義ってことも大いにあるので活用していこうと思う。

しかしながらRubyTkには遅い以外にも問題がありそうな感じなのだ。
下記は現行で最速のruby/Tk,DxRuby,C#の各々のマンデルブロー集合描画

各々の実行時間はTk:Dx:C#=7533:2031:208 (mS)なのだが問題はそれ以外のところにあった。画面をよく見てみると細部の表現が同じではない。描写の細かさなどの順でも速度と同じ順位なのだ。つまり粗さの点でTk>Dx>C#でC#が最も細かい。

右の大きな黒い部分と左の２番めに大きな黒い部分の境の砂州に似た部分の長さが違う。

また個々のリアス式海岸様の部分の細かさも異なる。

過去の他言語の結果を見比べてみるとどうやらrubyだけがこの傾向を持つようだ。

そしてDxよりもTkのほうがより顕著に甘く粗い。繰り返し回数に依存しているわけではなさそうである。既に旧BASICを除けば最遅のRubyTkでこれ以上の追求はしない（する気にならない。）がDxについては繰り返し回数を他の並に上げるなどして様子を見たい。

これもまた実行が速ければの事だ。

さっそく32回で打ち切っていた繰り返し上限を100にして試行してみた。

実行速度が2.03→4.55と倍以上遅くなったが画面的には満足の行く形になった。

こちらはExcelのCellを画素に見立てて書いてみたもの。

256ｘ180と桁違いに小さい画素量だけどまずまずの速度かと思う。

まああくまでも実用とか他の表示とか無視した遊び。 

ついつい怖いもの見たさにやらかしてしまいました。

Ruby/Tkのmandelで発散確認回数を増やして画面精度を上げました。

なんと373秒です。(6分強か！待てねえな)

もうこの手の試用でruby/tkは辞めます。でも画面はやっと人並み

初めてのプロファイリング

昨夜、rubyのマンデルブロー集合描画がDxRubyの利用で10倍以上(正確には約13倍)速くなったのに気を良くしてさらなる高速化を目指して初めてのrubyプロファイリングをしてみた。
標準でruby付属のprofileは実行速度が100分の１位になるとの情報があって実用的でないと判断して高速なプロファイラとして知られているruby-profをgemして利用した。
ーー最初のものーー

どうも複素数のオブジェクト系の生成と操作に時間を取られている模様

 BASICなど複素数型の無いものを参考に単なる実数の掛け算に変更。

プロファイリングから手を入れた結果は？

改造前:改造後 = 5.86:2.03　と約３倍弱の高速化！これは美味しい。
プロファイリングなどを使いこなせるプログラマになろう。

DxRubyでリベンジ

8/4の「またしてもmandel」のエントリーでrubyが遅いことを書いた。
その時の記録がruby/Tkで書いたもので76秒とある。
他のやつが意外と速いので悔しかったのであれこれ調べていたらDxrubyで書くことに思い至った。実は前にも挑戦しようとしたことがあったけど静止画をどのタイミングで用意するかわからなかったので辞めていた。
今回、別件で探していたことからそのことに気が付いたのでチャレンジしてみた。

6秒弱ということは12倍以上の高速化でかなり有効だと思った。
ただしDxRubyはもともとゲームを書くためのライブラリーでたまたまmandelは点さえ描画できれば書けるので出来たけど直線や円を描く方法については未知である。
でもこれでちょっとはリベンジ出来たと思う。

visualbasic.netとC#

同じILにコンパイルされるはずのこの2つの言語ですが随分違って感じます。

こんなページが有りました。
VB.NET より C# の方が好きなところ

やはりC#はrubyとかと同じくOOPを軸足に据えた言語だと思います。
比べてVB.netのほうはそれまでのVB経験者やVBA出身者がOOPでビビることが極力無いように1フォームなど機能単位のクラスの中にC#で言うstaticなsub,functionで構造化的に開発するイメージを全面に打ち出したもののように思います。

同じことができるはずなんだけど、やっぱりソフトはそのシンタックスというか思想に影響を受けて描かれるものなのでしょう。ちまたでのVB.netの不評さはそのあたりから来る利用者の様相からの評価なのでしょう。
同じことができるはずなんだけどちょっとした字面の違いで随分作り手や読み手のソースへの思いが異なるんでしょう。（ラムダの書き易さなどの顕著に表れてると思う。）

やはりちょっとした実験や落書きはVBで、本格的な製品を作るのがC#、でさらに慣れてきてレベルが上ったらなんでもC#って感じで行きたい。

流石はmac

先日来ベンチしているmandelbrotだけど、windowsで好成績だったjavaの
ソースをmacに送って実行してみた。
なんと72msが出た！

こうなるとinkeyでちゃんとマルチバイト文字のコードすら取ってこれないクソな古代BASIC互換のソフトの1時間半待ちとか3時間待ちの意味が全くわからない。
java(on mac):n88互換:mbasic86=72ms:12830sec:5298sec=1:178194:73583
これにDebugのやりやすさ、やりにくさ、ネット上の情報の過多を加味すると古代BASICである程度のソフトを作ろうとすることは時間の大いなる無駄遣い以外のなんでもないとわかります。
しかし恐るべきはmac！core i7のWinよりも実効速度がはやいとは！

感動的に遅い！！

N88BASIC系のフリー言語でmandelしてみた。まずは

１）N88互換BASIC　・・　これは凄い！こんな遅いので良いの？！
　　　　この画面は開始して３０分ほど経過したものだけど・・・

それ以上に、以前のN88BASICユーザに触らせるのならダイレクトモード無しは拙いでしょ。

ちょっと動作を検証したいときにいま作成中のソフトを一度終わらせて確認用に

ちいさなプログラムを書くとかありえないし。

ソースは以下（今回の奴らで共通）

　　ようやく終わりました。所要時間3時間33分50秒(=12830秒)

２）mbasic86

　　こちらのほうが色々とましと思えてきますね。

　　特にダイレクトモードは普通に使えるので変に画面を分けて機能をダウンさせたようなものよりはN88-basic経験者に受け入れられる気がします。

　　知名度はN88互換のほうがあるみたいだけど・・・

　　所要時間は１時間28分18秒(=5298秒)

ソースは共通だけど随分環境で動作が変わります。

因みに「十進BASIC」でも文法にN88BASICを選ぶと上記のソースでマンデルは描けます。しかし所要時間の表示が同じ画面に出ずに別のテキスト表示専用のウィンドウに出ます。教育用なのでこんなもんかと・・・しかし所要時間は超桁違いの15秒！！これなら我慢できます。

N88と共通の環境にするためにjavaやC#のベンチマーク用の画素数640ｘ480ではなくて

640ｘ400で描かせているのですでにそこで2割のハンディをもらっているのにこの遅さ。

いやはや何をか言わんや！

ExcelのVBA入門へ導入するのにシルバー世代を引き込むためにN88から入ると面白いかもって考えての古いBASIC探しです。まあマンデルなんて描かないとは思うけどね。

合わせてレイトレーシングもやってみるか？