Language suggestions for writing an app

Click For Summary

Discussion Overview

The discussion revolves around the selection of programming languages and tools for developing a graphical plotting program, particularly in the context of enhancing an existing Zeta function root finder application. Participants explore various languages including C, Java, Python, and libraries like SDL and GTK, while considering factors such as portability, performance, and ease of integration with existing code.

Discussion Character

  • Exploratory
  • Technical explanation
  • Debate/contested
  • Mathematical reasoning

Main Points Raised

  • One participant is considering C for its portability but is hesitant about using X11 for graphics.
  • Another participant suggests using SDL for per-pixel data access and mentions its simplicity and OpenGL compatibility.
  • GTK is proposed as a cross-platform alternative, though one participant notes limited experience with it.
  • GNU-PLOT is recommended as an easier option for plotting, with integration capabilities for LaTeX and other math software.
  • Python is mentioned as a viable option, with links to resources for scientific computing and plotting.
  • A participant shares their experience with Java, suggesting the Ptolemy plotting package and discussing the integration of C++ code into Java applications using JNI.
  • Performance comparisons between Java and C++ are shared, with one participant noting Java's surprising performance in benchmarks.
  • Concerns are raised about Java's numerical precision and lack of complex number support, prompting requests for recommendations on complex number classes.
  • Discussions about compiler performance, particularly regarding GCC and MIPSpro, highlight differing opinions on optimization capabilities and speed.

Areas of Agreement / Disagreement

Participants express a range of opinions on the best programming language and tools for the task, with no consensus reached. There are competing views on the performance of Java versus C++, as well as differing experiences with various compilers.

Contextual Notes

Participants mention limitations related to Java's numerical precision and the challenges of integrating complex number support. There are also unresolved questions regarding compiler performance and optimization across different platforms.

Who May Find This Useful

Readers interested in programming languages for scientific computing, graphical applications, and performance optimization may find this discussion relevant.

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?
 

Similar threads

  • · Replies 9 ·
Replies
9
Views
3K
  • · Replies 4 ·
Replies
4
Views
2K
  • · Replies 44 ·
2
Replies
44
Views
6K
  • · Replies 2 ·
Replies
2
Views
2K
  • · Replies 1 ·
Replies
1
Views
8K
  • · Replies 2 ·
Replies
2
Views
1K
  • · Replies 1 ·
Replies
1
Views
2K
Replies
19
Views
4K
  • · Replies 10 ·
Replies
10
Views
3K
Replies
1
Views
2K