Language suggestions for writing an app

AI Thread Summary
The discussion revolves around the choice of programming language for developing a graphical plotting program to complement an existing Zeta function root finder. C is currently used, but concerns about graphics implementation and portability lead to consideration of Java, despite its limitations with complex number support and numerical precision across platforms. Suggestions include using SDL for graphics or GTK for cross-platform compatibility, while GNUplot is recommended as an easier alternative for plotting. Performance comparisons between Java and C++ reveal that Java can perform comparably in certain scenarios, though compiler optimizations play a significant role. The conversation highlights the importance of balancing ease of use, portability, and performance in selecting the right language and tools for the project.
graphic7
Gold Member
Messages
450
Reaction score
2
I'm curious about writing a graphical plotting program to suplement an existing program. I've been working on a Zeta function root finder for a few months now, and I'd like to be able to graph some aspects of the Zeta function as well as many more functions. I'm contemplating what language to create a graphical plotting program; I'd like the program or function to be a part of my Zeta function program.

I've considered C, since my program now is written in C, but I'm not quite comfortable using X11 to do the graphics (might be something I should pick up). Right now, the C implementation only works on MIPS/Irix. (got to love C's renowned portability). I'm using the MIPSpro complex libraries, hence the problem.

Java seems like a solution given that it has Swing, which I think would be ideal. Performance isn't really an issue; I'd just like to do some calculations and graph them efficently. I do have a question(s) about Java, though:

I know Java is rather standardized when it comes to type specifications, but I've also heard that Java's numerical precision still varies from platform to platform - this is an issue. Does anyone have any experience or thoughts on this?

I've been reading some articles about Java's non-existent complex number support. All the articles say the some basic thing, "Java can't overload infix operations." That's not good, ugly code. Complex numbers are essential to the program. Anyone have experience or would know of a decent complex number class?

I'd prefer the application be rather portable (OS and architecture), which C isn't the solution here. I've converted so many types now (nice long makefile and configure), and it's getting rather old. Java again, seems like a solution.

Anyone have some thoughts?
 
Last edited:
Computer science news on Phys.org
Well, there are two solutions I'm thinking about, 1 would be to use SDL and access per-pixel data. This doesn't give you other widgets to work with unless you can find some lib laying around. It is very simple and works with c/c++ and has bindings for everything. It also extends nicely into the opengl realm giving you opengl access.

Another option is to look at something like GTK, cross platform. I haven't develled anything too big to comment on power, but as a heavy gtk user, i like it.

I agree no overloading makes ugly code ;)

How about instead of trying to re-write the world, you should try out GNU-PLOT.
http://www.gnuplot.info/
I highly recommend using this option instead of all others. It's much easier to write input for this program, or modify the program itself instead of writting one on your own. Another nice feature is the option for integration with latex. There are a bunch of helper commands to make it easy. Third party math softare such as octave (kina like matlab) use this to draw.
 
Last edited:
Python. I did a mandalbrot with it a few weeks back.

http://www.scipy.org/documentation
http://starship.python.net/~hinsen/ScientificPython/
http://gnuplot-py.sourceforge.net/
 
Last edited by a moderator:
If you do decide to use Java, take a look at the Ptolemy plotting package from UC Berkeley. http://ptolemy.eecs.berkeley.edu/java/ptplot/

Keep in mind it's not hard at all to integrate your already-written C++ code into your Java app, using the Java Native Interface. Voila, you have a nice UI with a powerful C++ numerical engine behind it.

- Warren
 
I was doing some tests this weekend and I noticed something startling.

I ported the C++ code to Java, which wasn't hard given the application isn't graphical. After doing so, I decided to run a few tests between the C++ and Java code. I set the test up so that the program requires roughly 10 ^ 9 iterations required to complete, and I compared Java and C++ compilers. On the Java side, Sun's javac and IBM's jikes, testing target releases 1.1, 1.2, 1.3, and 1.4 of Java. On the C++ side, GNU's g++ and SGI's MIPSpro.

At this time I have not run the test using IBM's jikes Java bytecode compiler.

The test machines are roughly a dual 866mhz Pentium 3 Xeon (SuSE Linux 9.0) and an SGI Octane 300mhz R12000 (Irix 6.5.14m). I can post the versions of the compilers, if needed. At this time, I have also not run the tests on the SGI, but I hope to do so in the next few days.

When running the test, I run each specific binary 3 times, record the time, and then average all 3 to get a rough benchmark.

Java scored around 10-20 seconds lower than the equivalent G++ compiled binary. Each test takes around 45 minutes to complete.

After I run the tests on the SGI, continue to run tests on the X86 with various optimizations G++ supports, and test Java performance using jikes on both platforms I'll post a comprehensive benchmark between Java's and C++'s performance on two different platforms: Linux/X86 and Irix/MIPS.

Enjoy.

(I must say I am suprised at Java's performance)

Some of this loss of performance in the C binaries could be explained by the fact they are compiled by a terrible compiler - thanks to GNU. I haven't tested *anything* on the SGI yet, and when I do so I'll be sure to compile with MIPSpro and G++, then test them individually.
 
Last edited:
graphic7,

I'm not sure why you're so surprised -- we've been telling you this all along.

The majority of Java JVM's perform just-in-time compilation, so, for scientific code doing a lot of math, arrays, and for loops, Java should run at virtually the same speed as the equivalent C code.

I'm also rather appalled at your continued unjustified hatred against the GNU project. I predict the GNU-compiled binaries will actually outperform the SGI compiled binaries, unless you're specifically making use of multi-processing (and you aren't).

- Warren
 
I'm curious too. Why did you say this "Some of this loss of performance in the C binaries could be explained by the fact they are compiled by a terrible compiler - thanks to GNU."?

Are you upset with the GNU project, or one of the GNU compilers?

As an aside, Apple uses gcc as the primary compiler in OS X. It's a good compiler.
 
I'm not saying GCC is a terrible compiler in all aspects. I respect GCC for it's portability - there's a GCC on every platform and I'm not complaining. But, let's face it, GCC isn't the fastest compiler in the world, whether that be compile time or run time. I've seen some interesting performance increases on my SGI when it comes to using the MIPSpro compilers and the GNU compilers.

I remember a few years ago (?), Intel came out with their own set of compilers. While I haven't tried the Intel compilers for X86, I bet the Intel advertised benchmarks weren't too far off from actuality.

People buy the MIPSpro compiler suites for a reason - not just to spend a load of cash. The suite supports *lots* of CPU optimizations that GCC doesn't support. Only because SGI naturally has more experience with MIPS hardware that GNU does.

GCC is probably the best compiler for X86 hardware, that I've seen. Another is 9c (developed by the Plan 9 people, but I won't get into that). Sun and SGI both sale compiler suites that *are* optimized for their hardware - that being Sparc and MIPS.

Regardless, I might turn into a Java supporter afterall.
 
Last edited:
  • #10
gcc-'s goal is portability not speedyness so there are issues in the architecture that make it difficult for optimization. Intel's compiler is just about one of the best you can get, especially for AMD cpu's.

Java has a run-time profiller and can optimize on the fly. That was one of the arguments about why byte-code apps could potentially run faster, especially for servers.
 
  • #11
Interesting, the Intel compiler performing well on AMD's processors. I'm sure that's not what Intel wants to hear. Do you think the Intel compiler suite is worth the money?
 
Back
Top