做Simulation用Java才是王道呀

dclong

R吧，慢。致命硬伤是单线程。

Matlab吧，速度尚可。硬伤是商业软件，一般的Sever上面不一定有。即便有也不一定有Parallel Computing Toobox。

C/C++吧，快。可是门槛高，多线程运算比较复杂（听说，木有实践）。

Fortan吧，快。不过一个字：土。

Java吧，各方面都中规中矩，发展势头强劲。

综上所述，Java很好很强大！

autoban

JAVA多线程怎么个方便法啊？

OPENMP还是挺方便的啊。

enthumelon

回复第1楼的 dclong：C++的多线程有一堆一堆的现成库函数。 Fortran比C快比Java快多了，就是代码太格式化了。 Java上手方便，而且基本拿来开发界面...

easttiger

You're not compare things on the same level.

R is not a language like java.

While java has all those connections/streams to the infrustructures, R doesn't. It's just a high level wrapper language unifies syntax of the underlying real working ones like C, Fortran. In the end, R dev team will always have the option of having a interface with Java.

dclong

回复第2楼的 remember, discover, invent：

会者不难，你都会OpenMP了还跳这个坑。

dclong

回复第3楼的 enthumelon：

我曾经想学Fortran来着，可是一想学个Fortran就只用来做科学运算太不划算了。

效率不仅是用运行速度来衡量的。TR以前用C做MCMC的时候不是感叹过：用R做MCMC，两个小时写完code，花一个月运行。用C写MCMC，两个小时运行完，不过花一个月写Code。这话正反都能说。但是我觉得用Java，两个小时（上下浮动，取决于你怎么写）运行完，一天写Code。最关键的是Java各方各面都是中规中矩的，可以做的事情多着去了，不用再花很多时间去学习其他语言了。当然对于你这等精通C++的高手来说，Java只是个浮云。

dclong

回复第4楼的 easttiger：

的确不公平，R的优势在于人机交互的简洁性和多不胜数的package。

enthumelon

回复第6楼的 dclong：事实上那个MCMC的C++代码重用率很高～所以值得写:) 我本人主要是太厌恶JAVA了:类太繁杂也不知道哪个好哪个不好，可以很快写好，但是一点都没有运行效率... 过度抽象的面向对象语言对我也没有什么太大的作用。

autoban

MCMC的并行运算还是要费些脑筋的，具体问题下面可能会有比较好的办法，但是比较一般的算法好像还都不太成熟吧。个人认为是个很值得做的方向。

G_will

我是进来看论战的。

P.S. 个人不喜欢java，用java做模拟？还是C/C++ Fortran更靠谱。

enthumelon

回复第9楼的 remember, discover, invent：并行是一个方面~可我实际发现的是某些并不那么复杂的模型在R/Winbugs下的速度也够幽默的（相对于哪怕是单线程C＋＋实现）。按理说WinBugs做到了一个行业软件的极致（这个是事实），但是诚如你说的那样，一般的算法都不太成熟，有待大家努力:)

autoban

回复第11楼的 enthumelon：Are you sure you are comparing exactly the same algorithm? For example, if WinBUGS does not know how to sample directly, an adaptive rejection algorithm might be used. Are you implementing the ARS in C++ when doing speed comparison?

I dont' understand "并行是一个方面". What other benefits can we get from multi-threadding?

Actually, I heard that R is moving toward re-writing more code with OpenMP.

I wonder where is the ultimate cause of slowness in R. Is it parsing/interpreting overhead? Did you try to compile the R MCMC function before comparison?

autoban

My choice would be a combination of R and C/C++. R will be used for a majority part of the simulation, but the most time consuming part could be re-written into C/C++ as a .so/.dll, which can be easily called from within the main R code.

Development time for R is trivially ignorable and the translation time from R to C/C++ will be much shorter then starting up with C/C++ in the begining.

autoban

Thankfully, no one brings up SAS, which seems horrible in doing simulations....

dclong

回复第9楼的 remember, discover, invent：

这个早就有人做过了吧，MCMC由于其算法的原因，一般来说不好对循环使用并行运算。但是每一步循环里面一般来说是可以并行起来的。我觉得值不值得做取决于每一步循环需要的时间吧。

dclong

回复第10楼的 G_will：

多年之前程序员还说C？我看还是汇编靠谱呢

dclong

回复第11楼的 enthumelon：

一般性的解决方案当然不如一个特殊的解决方案。这就是为什么给你一个明确函数，optimization比较好做，但是目前为止也没有一个万能的optimization算法。

dclong

回复第12楼的 remember, discover, invent：

我觉得R的确该从底层进行改良了。我觉得R慢的原因主要是语法太灵活了，就像你所说的interpreting的时候自然就费事。碰上循环，这种时间消耗被急剧扩大，差距就出来了。我觉得还有另外一个可能的原因是R里面很多包都是基于其他一些并没有优化过的代码，这样层层累积导致一些包里面的函数效率及其低下。

dclong

回复第13楼的 remember, discover, invent：

我觉得R加上C/C++到底好不好用还得看具体情况吧。我以前也做时间序列的bootstrap时用R做主体框架，内部循环，代数计算等用了C，但是速度还是不理想。跟同样任务的Matlab代码相比效率差得没影了。也正是从那以后我才决定，做大型的simulation还是用单一的高效语言。至于最后的数据汇总，作图什么的，还是R是首选。

dclong

回复第14楼的 remember, discover, invent：

反对，反对。R可也调用其他高效语言，那么SAS也可以调用R，还可以调用R来调用其他高效语言嘛，哈哈~我是来搅局的