教你用Ruby算命！

我觉得Erlang和C# Plinq比并没有什么优势.... haskell我看不太懂，能确认算法是完全一样的么？

晚上找一个3.5的ilasm改一个带tail的C#版本来。

我也觉得Erlang和C#甚至Java比优势并不明显，那不应该叫优势，应该叫特色而已。

不能笼统的说面向函数编程比面向过程编程好，只能说个别地方有特色而已。

就如同Erlang的轻量级进程、高并发就是特色，但其他的和Java、C#比，没觉得有什么牛的。

算法都一样，各人线程数不同。

linq 语法其实挺 functional 的，F# 就更像 haskell 了。

并发数多，并且涉及大量共享数据才能体现出 Erlang 优于经典线程模型的特点。但这里不是那种服务器处理 n 用户连接的情况…… 为了充分利用多核 cpu，两个线程保持 busy 就够了，线程太多反而可能会因为内存分页问题搞慢速度。

+RTS -N2 似乎也没有改善，还是接近50% 60%

-threaded 能让haskell用native thread？

算了， 上一个groovy版本的，瞬间算算到M1000:

def f = 1g 
(2g..1000g).each { n -> 
f = 2 * f + 1 
if (f.isProbablePrime(100)) 
println "f($n) = $f" 
} 

输出结果如下：
f(2) = 3
f(3) = 7
f(5) = 31
f(7) = 127
f(13) = 8191
f(17) = 131071
f(19) = 524287
f(31) = 2147483647
f(61) = 2305843009213693951
f(89) = 618970019642690137449562111
f(107) = 162259276829213363391578010288127
f(127) = 170141183460469231731687303715884105727
f(521) = 6864797660130609714981900799081393217269435300143305409394463459185543183397656052122559640661454554977296311391480858037121987999716643812574028291115057151
f(607) = 531137992816767098689588206552468627329593117727031923199444138200403559860852242739162502265229285668889329486246501015346579337652707239409519978766587351943831270835393219031728127

15分钟算到M4000:
f(2) = 3
f(3) = 7
f(5) = 31
f(7) = 127
f(13) = 8191
f(17) = 131071
f(19) = 524287
f(31) = 2147483647
f(61) = 2305843009213693951
f(89) = 618970019642690137449562111
f(107) = 162259276829213363391578010288127
f(127) = 170141183460469231731687303715884105727
f(521) = 6864797660130609714981900799081393217269435300143305409394463459185543183397656052122559640661454554977296311391480858037121987999716643812574028291115057151
f(607) = 531137992816767098689588206552468627329593117727031923199444138200403559860852242739162502265229285668889329486246501015346579337652707239409519978766587351943831270835393219031728127
f(1279) = 10407932194664399081925240327364085538615262247266704805319112350403608059673360298012239441732324184842421613954281007791383566248323464908139906605677320762924129509389220345773183349661583550472959420547689811211693677147548478866962501384438260291732348885311160828538416585028255604666224831890918801847068222203140521026698435488732958028878050869736186900714720710555703168729087
f(2203) = 1475979915214180235084898622737381736312066145333169775147771216478570297878078949377407337049389289382748507531496480477281264838760259191814463365330269540496961201113430156902396093989090226259326935025281409614983499388222831448598601834318536230923772641390209490231836446899608210795482963763094236630945410832793769905399982457186322944729636418890623372171723742105636440368218459649632948538696905872650486914434637457507280441823676813517852099348660847172579408422316678097670224011990280170474894487426924742108823536808485072502240519452587542875349976558572670229633962575212637477897785501552646522609988869914013540483809865681250419497686697771007
f(2281) = 446087557183758429571151706402101809886208632412859901111991219963404685792820473369112545269003989026153245931124316702395758705693679364790903497461147071065254193353938124978226307947312410798874869040070279328428810311754844108094878252494866760969586998128982645877596028979171536962503068429617331702184750324583009171832104916050157628886606372145501702225925125224076829605427173573964812995250569412480720738476855293681666712844831190877620606786663862190240118570736831901886479225810414714078935386562497968178729127629594924411960961386713946279899275006954917139758796061223803393537381034666494402951052059047968693255388647930440925104186817009640171764133172418132836351
f(3217) = 259117086013202627776246767922441530941818887553125427303974923161874019266586362086201209516800483406550695241733194177441689509238807017410377709597512042313066624082916353517952311186154862265604547691127595848775610568757931191017711408826252153849035830401185072116424747461823031471398340229288074545677907941037288235820705892351068433882986888616658650280927692080339605869308790500409503709875902119018371991620994002568935113136548829739112656797303241986517250116412703509705427773477972349821676443446668383119322540099648994051790241624056519054483690809616061625743042361721863339415852426431208737266591962061753535748892894599629195183082621860853400937932839420261866586142503251450773096274235376822938649407127700846077124211823080804139298087057504713825264571448379371125032081826126566649084251699453951887789613650248405739378594599444335231188280123660406262468609212150349937584782292237144339628858485938215738821232393687046160677362909315071

别的语言算到M(607)也是瞬间的，我跑下Erlang看看到15分钟算到哪里，再贴给你。

Erlang版正好快到15分钟也计算到了M(3217),

看来对于这段算法，Erlang和Groovy这种运行在虚拟机上的编译型语言速度都差不多啊。

我那个机器是个虚拟机，2核2G。

这样的比较没什么意思……

对大规模的问题，语言的差别撑死也就常数级，算法复杂度才是性能的主宰。
假设 Intel C 平均操作比 Ruby 快 100 倍，那么同样的算法就差 100 倍左右。

看看算法复杂度的比较例子：

时间复杂度 O(n^5) 的算法，是 O(n^4) 耗时的 n 倍。
如果 n 是 100 位整数，那么区别就是：
1亿亿亿亿亿亿亿亿亿亿亿亿亿亿亿亿亿亿亿亿亿亿亿亿亿 倍

同意。

目前的算法大概都一样的吧，都是用卢卡斯莱莫的那个方法，而且都只用一台计算机做计算。

我们该想想怎么把这个东东写成多个计算机分布计算才NB。