From: Andrea at d. <me...@an...> - 2012-12-04 12:48:17
|
Hi there, I think C++ is still best choice to process large amount of data faster. But, one of the most important thing we need to consider is who will use this library and what kind of languages / environment they use. In my opinion we should use C++ so we'll be able to compile this library in all environment (Linux / MacOS / Windows). I didn't try but there is also this http://www.eclipse.org/cdt/ for C++ development. Andrea On Mon, Dec 3, 2012 at 12:09 AM, Ulf Lorenz <ul...@wa...> wrote: > Another thing that came to my mind between the project help request and > now is that there is another option for the programming language. > > Basically, there are two ways (there are more, but they will not be > more attractive...). > > We can use C++, especially C++-11, as suggested in the help request. > There is little to say here. However, an alternative that I came across > would be to use Java. > > The advantages, which brought up the whole idea: > > + It has much better integration in IDE's and with testing toolkits > (JUnit, JMock etc.) > > + It is an easier language for the end user; garbage collection does > not need to be kind of added, and there are less horrible language > features than for C++. > > + Deployment is way easier. If we could implement the basic algorithms > in Java only or find a library, one could have a stand-alone Java > program in the end. Imagine a course on some quantum mechanics, and > the students could just download a jar file and write their programs > without having to compile or care about operating systems and such > (of course, with a considerable performance penalty, but that might > not be a big issue for small demo systems and today's computers). > > + Possibly easier scripting language support. I know that at least > Matlab supports directly importing and working with java objects from > scratch. Possibly something like this might hold for other scripting > languages as well. > > > However, some disadvantages: > > - there is some performance penalty associated with the use of Java. I > once did a search and only found a factor of >= 2 in runtime for raw > numerics; I have no idea how much the overhead would be for the rest > of the code. > > - I did not find good Java-only numerical libraries. Also, for > performance reasons, we would have to interface the low-level > numerical details (matrix handling, FFT and such) with > platform-dependent code. I have no idea how well this works, what > quirks there are and so on. Also, the project would then > probably contain different programming languages, build systems etc., > which is kind of ... unaesthetic. > > - It might be that for some (large?) setups, setting up a Java Runtime > environment is not trivial (e.g., parallel computing), so it might be > that we effectively block this kind of usage. On the other hand, for > large setups, people will usually write their own wavepacket code > that is not portable to other problems, but well adapted to the > targeted problem, which we will have a hard time beating anyway, or > use a big monster like MCTDH, which is difficult to handle, but can > handle large problems with additional approximations. > > > I am not really decided either way, and as written, I have no feeling > for several of the points, so I would put this to discussion and joint > decision. Feel free to discuss and give a verdict. It might also be > that we agree on testing something out, that would also be fine. > > > Ulf > > > ------------------------------------------------------------------------------ > Keep yourself connected to Go Parallel: > DESIGN Expert tips on starting your parallel project right. > http://goparallel.sourceforge.net/ > _______________________________________________ > Wavepacket-ng-devel mailing list > Wav...@li... > https://lists.sourceforge.net/lists/listinfo/wavepacket-ng-devel > -- "Experience is what you get when you don't get what you want", Dan Stanford Andrea Girardi blog: http://www.andreagirardi.it linkedin: http://www.linkedin.com/in/andreagirardiverona web http://www.agdev.net |