Slashdot Mirror
Competitive Cross-Platform Development?
Avalonia asks: "I work for a software company in the oil and gas exploration industry with a software development team of seven. Our software and development environment is cross-platform on Solaris, Irix, Linux and Windows. Most of our customers are on Solaris and Irix 64-bit systems, but Linux and Windows are increasingly important. Our environment is based around an elaborate command-line system of Makefiles controlling four different compilers (gcc 3.1, Sun Forte, Irix MIPSpro and Visual C++ 7). Needless to say, maintaining this system and producing modern multi-threaded C++ that will go through the four build systems is time-consuming in the extreme. A large proportion of our time is spent finding C++ code that just works rather than being creative and competitive with new functionality. What tools and strategies can we use to increase our productivity and regain our competitive advantage, without going for Windows only?"
"Our recent single-platform competitors (Windows only) can seriously outrun us in terms of productivity by using a single modern IDE development environment - such as C++ builder or Visual Studio - although we can scale onto larger multiprocessor Unix systems. With Windows 64-bit imminent we may lose our 'big-iron' scalability advantage. Java is not currently an option for the high-performance numerical and immersive graphical aspect of our applications."
www.eclipse.org
I think it runs on several of the environments you mention. And I think there are C++ plugins for it.
BC
why all the different compilers?
.. but can't gcc cross compile? At least then you could dump alot of the compiler-specific scripting in your build procedures.
Hrm, this seems too simple an answer, there must be something wrong with it
"Old man yells at systemd"
Why not just use gcc for all four platforms? The sticking point would likely be Windows, but even if you elect to stay with MFC++ for Windows, you've reduced the incompatibilities from four to two different compilers.
Trust the Computer. The Computer is your friend.
You can, with some loss of performance, use GCC on all of those platforms. That would cut out compiler quirks as a variable.
Don't write Makefiles yourself. Instead write a script that translates simple build rules (foo.cpp -> foo.o -> foo.exe) into a custom Makefile for each platform. I went this route after battling for years with complex Makefile rules that never quite worked.
Are you kidding me? They are building a real application that performs and does multi-threaded as only C++ can do. If you can't use java, what makes you think that perl, especially interpretted, would do the trick? Yeah, fine for prototyping, but how is this going to help?
...begins in wonder
...uhm...ahmmm...mmm. Dunno what to add.
I assume that most of your problems are in the GUI end of the equation - why not break the application into two bits? Put the numerical stuff on a grunty 8 way box, and cook up the UI with whatever language best suits the available (and hireable) skills and platform?
Communication between the two is probably best through SOAP, although to be honest I've not looked into this area for a long time. The GUI can still be built from Java (I believe Java has some reasonably fast OpenGL wrappers now), or look into wxWindows using the existing C++ resource.
Dave
I write a blog now, you should be afraid.
I've done something similar in a mixed environemnt. The way we set it up is to use java for GUI and logic development and then run a profiler against it and go native on those functions that needed it. These functions would be compiled into a library. (You'd be amazed how little of your code you need to optimize for huge performance gains!)
If I had to do it again I would do the same thing except I would use python as the 'main, relatively slow, easy to code and maintain' language.
Hajo
Hajo Monogamy: Belief so strong that millions of people end perfectly good relationships in order to start a new one.
If you have to use C++, then wxWindows is a great environment: it works on lots of platforms and has extensive support for platform-independent I/O, threading, and networking.
http://www.wxwindows.org/ - mature crossplatform C++ library, and not only for GUI, either.
I don't know what you need, but WxWindows and GCC cross-compiling (see mingw32 faq, for instance) might be what you need?
WxWindows also have good bindings to python and perl etc. for more rapid crossplatform development.
Why not do what a great many other people do (though I have a feeling that you may be doing this already), and target a specific platform for initial release, and then release on the others afterward? This allows you to focus on the platform that gives you the most bang for the buck, but still keep your scaling advantage. If you already have an established product/development environment, then you should already know enough to keep from doing any of the "big mistakes" when it comes to writing portable code. Plus this allows you to divvie up your engineers into functionality vs porting.
Another thing would be to standardize on say, gcc. since the source is available, you can do whatever tweaks you need to to get around any performance issues (I know, easier said than done). Then standardize on things like configure.
I would suggest first using gcc on all UN*X platforms, and also trying out something like ant instead of the various forms of make you're dealing with now.
Also, have you considered using a library like Qt to handle most of the porting details? It's not free, but it is good if you can deal with it's oddities (I personally consider preprocessing to be evil).
Good luck.
-30-
gcc is built for portability, not speed. VC++'s code is faster, but has zero portability and its own magical, lsd-inspired "innovations." [" for(int i=0;in;i++); for(int i=0;in;i++); ? Why would anybody ever want to compile code like that?"] That intel compiler mentioned on /. a while back sounded fast; but the gcc-for-everything approach may not be best, if they find compiled java too slow.
"Whatever happened to fair use?"
-- Duff-Man
In defense of my previous post:
As for graphics, there is a QT binding for perl that will allow you to do cross platform GUI work (and it looks nice, too)
As for speed, making C/C++ plugins for perl is not hard, and if you can break out your high-speed numerical pieces into small bits of code, it's relatively easy to call them from perl.
That said, perl isn't that slow. After you break out a few critical routines into their own XSUB modules, I bet you'd be surprised how fast perl is.
Also, perl 5.8 has very good threading support, and it isn't a global mutex around the interpreter like it is with some other interpreted languages.
Just add more people to your team! Double! Tripple! GO WILD WITH NEW RECRUITS!
Sheeesh, some people never learn...
Belief is the currency of delusion.
...why you think you can't use Java.For all the bad press Java gets about being "slow", it is mostly old, outdated FUD. Newer virtual machines are often faster than C/C++ applications, especially in the number crunching arena. Intensive graphics are no big issue since Java now has a fullscreen API (page flipping, double buffering, and all that), a very fast implementation of Java3D, and (if you prefer) OpenGL wrappers.
Even if you feel that Java doesn't cut it for everything, apply the 80/20 rule. 80% of your non-performance critical code in Java, and the later 10& in C/C++. This solution would at least *reduce* your multi-platform woes. You might try posting this on JavaGaming. The guys over there are wizards at making Java perform with intensive graphics. (No surprise considering that some of the industries greatest performance experts hang out there.) They can also help you find the APIs you need. I'd really take a second look before you toss Java out as an option.
Javascript + Nintendo DSi = DSiCade
Java isn't an all or nothing deal. You could write your app in Java and then convert the parts that really need performance into C and call it via JNI. Then you only have to deal with keeping a much smaller C library portable.
-----
Free P2P Backup, Windows & Linux
I've developed several multi-threaded mulit-plateformed applications using ACE. This is a very well thought out package using various patterns to abstract the vulgarities of the different OS / compilers. ADAPTIVE Communication Environment
Three things are certain: Death, taxes, and lost data. Guess which has occurred.
I've seen a few shows on TV recently that featured some really wicked looking oil and gas exploration software. Stuff that let geologists view layers of terrain collected by seismic data in 3d, moving around in realtime... If that's the kind of stuff you're into, I can understand why java isn't an option for display right now.
However, java is exactly what you need. You can scale it across processors on the big iron or run it on the desktop without recompiling.
Have you considered only writing your display logic in C++ and using java for the backend number crunching? For raw floating point math, I've read that java is barely slower than native code at this point. It's my understanding that talking to the OS so you can get to the hardware is where you take the major performance hits using java. If you could do your raw crunching in multi-threaded java code, you could then deliver the data through one of many different mechanisms to your display logic and have that be the only code that you need to port from OS to OS...
Another thing you could possibly look at is licensing 3rd party libraries made for cross-platform development. From your post, the only thing I know you're definitely having trouble porting is thread-related code. I'm sure there are multi-platform threading libraries for C++ out there somewhere.
Have you looked at Qt? It supports all the platforms you are developing for. It is primarily a platform independent GUI toolkit, but it also got a lot of other stuff like container classes (if you for some reason won't use stl), thread support, sql classes, xml classes and socket classes, all which are platform independent. It is not only just a portable GUI toolkit, I think it is the best GUI toolkit there is. I recommend it even if you're writing for Windows only. If you think of Qt more as a platform than a GUI toolkit, writing applications that run on multiple platforms (with native speed) may be easier than you think. (I'm not an employee of trolltech, although I am wearing a Qt t-shirt as I write this :)
I don't understand why people even look at Makefiles anymore now that Ant exists. We've completely automated all of our builds and deploys across NT, Linux and Solaris with it, across different architectures and different locations.
I'm not going to expound on using Java, since it is fairly ubiquitous these days and if it would work for you, I'm sure you would have already considered it.
You're joking, right? Perhaps I'm a little behind the times, but I was under the impression that GCC used a register based architecture where VC++ uses a stack based architecture. While GCC might spit out some average performing code with the default options, using -O3 will produce very fast running code. I've compared the performance of code compiled with GCC vs. the same program written in assembler, and at its best, GCC is only 50% slower than hand coded assembly, which is very good considering that some very well respected compilers will produce code that is 10 times slower than hand coded assembly.
I've also looked at the assembly language output of VC++, and it's a joke. VC++ often inserts large sections of extraneous instructions into the code. I've managed to follow function calls in VC++, and it is not uncommon for a function call to have prolog and epilog code of several dozen instructions. Interestingly, GCC uses a register based schema, and I can actually follow the code pretty easily, in spite of the fact that it uses the AT&T syntax. GCC just produces cleaner code.
The society for a thought-free internet welcomes you.
Java is not currently an option for the high-performance numerical and immersive graphical aspect of our applications.
So what you're saying is:
You've coded it in Java, used native methods where applicable, optimized it, ran it, and it was too slow on every single hardware configuration known to man.
Or are you just guessing?
If you posted on Slashdot hoping we'd help you, give us the details. How "not an option" is it?
-... ---
Step 1. Go to http://java.sun.com and download the JRE 1.4.1.
Step 2. Visit http://www.datadino.com and click on "Webstart Now!".
Step 3. Right click and save Meat Fighter. Find where you saved the JAR file and double click.
Step 4. Right click and save Duke Nukes Stuff. Double click on the JAR.
Step 5. Visit jGoodies and try their wide variety of products.
If you are under Linux, I'm afraid the games probably won't perform well. (Little issue with getting X to be configured to handle high speed direct-framebuffer graphics). However, DataDino should work, although you may need to get the installer instead of using the super-cool WebStart link (Mozilla problem only!). If you don't have a database to use, visit the "Supported Databases" page and download the test HSQLDB database.
The plain and simple fact is that Java is fighting two issues:
1. Poorly written apps that give all Java apps a bad name. (For example, "genius" A decides to load a table before releasing the event thread. Table takes 5 minutes to load and user gets annoyed. The solution would have been to load the table in a separate thread so that the user can see and interact with the table items as they are being loaded.)
2. Perceived performance vs. actual performance. People see Swing and the default look and feel and instantly "feel" that the app is slower than windows. Nothing could be farther from the truth. In all reality, it is probably running faster than the Windows app, it just doesn't seem right. This is caused by the Java L&F being way too "flat". Your brain doesn't quite connect the buttons and other objects as being solid objects to be manipulated.
Javascript + Nintendo DSi = DSiCade
As far as makefiles go, cmake looks promising. It seems to be a generalized Imake replacement. I haven't used it, but looks interesting. It is now part of the cygwin toolchain.
as far as tools go, look at cygwin. My company uses gnumakefiles on NT and UNIX, with generalized Makefiles for each project, and platform specific build rules in universal gmake include heeaders. We use ACE for a lot of the cross platform C++ stuff, a lot of our things are servers so we avoid the cross platform GUI stuff.
Think about Point #2 in this context. How many programs have you tried that you are surprised to learn are Java? If you said none, you probably aren't looking hard enough. (Hint: Look for the java.exe file in the installation directory.) You tend to recognize Java apps by their distinctive look. The distinctive look has problems with perceived performance. As such, many good programmers change it to use a non-standard look.
After you visit jGoodies, you should understand more of what I mean.
As for Point #1. I don't know enough about MFC to be 100% sure, but I believe that Windows automatically handles repainting when you are populating complex objects such as tables. (e.g. You'll tend to notice large tables in SQL Server Enterprise Manager paint nothing in the table as you scroll. Instead, you can watch the text filled in after the fact.) Swing (the Java GUI toolkit) requires the programmer to make these optimizations. Why? Because that's who *should* be doing it.
What if for some reason, I want to design a scrollable table that is fast enough when pulling data over dial-up connections? Under Java, I might design it so that the data doesn't display until the user stops scrolling, or I might display partial data. Under MFC, do I have much choice? Not without jumping through a great deal of hoops.
Notice how Microsoft writes new components every time they have a new piece of software (e.g. Office toolbars, Outlook shortcut bar, etc.). They do this to improve performance in their programs. Java programmers shouldn't have to rewrite GUI components, just data models. However, few and far between is the programmer who actually does this.
BTW, another spot you might want to visit is
Swing Sightings. You can find links to all kinds of well written Java programs.
If you'd like to try a Java program that uses native components instead of Java Swing, try Eclipse. While I personally don't like it, it should help you understand the perceived problem a little more.
Javascript + Nintendo DSi = DSiCade
It doesn't mention Linux compatibility, only that it has been 'designed to appeal to the Unix and Linux communities' - basically they're pushing the standards compliance a lot.
There will always be compatibility issues... VC.NET is a lot better than VC6 but there are holes, like MS' continued habit of putting underscores in front of 'unix compatible' names (snprintf for example), and calling other things completely differntly (eg. strcasecmp).
This stuff is done for real. At IBM I worked on a very large project that compiled on AIX (several distinct versions that we were sensitive to) Solaris, Windows NT, Linux, HPUX, and supposedly OS/400 although I never actually built the OS/400 piece nor have I seen it operate. First things first, you need good coding conventions, don't let some punk break them either. Secondly you have to design some abstractions and build some foundation classes; or buy a really good set or downlaod some good free ones, I've heard positive things about ACE. This is mostly a problem with windows any more, back a few years you might support win16, win32, PM, and UNIX now it's pretty much just POSIX and Windows. You need to abstract the machine stuff out. Threads, possibly strings and such (Unicode vs. non-unicode..) possibly basic types (big endian vs. little) networking code.. A rule of thumb is that on this kind of project you should never talk to the OS directly without something in between, it's a huge effort to make that OS abstraction layer or learn the ins and outs of an off the shelf one but it's worth it, even if you pay with a little performance. Nothing sucks more than coding away on AIX building some cool classes and adding some cool new stuff, then checking it in and finding that it doesn't compile on any other platforms.. and you've got to figure that crap out ASAP to make a deadline. If you build one from scratch, as IBM usually does or did, you can tune some things for your application; your OS abstraction layer can be a great "helper" or "utility" layer.
Typically well coded C and C++ can go from compiler to compiler pretty easily. Then you can use Pro64 on Mips, ACC on sparc, Intel C on Windows for performance critical portions of code. You have to be smart about it though and use some good conventions. The biggest rule would be avoid MS Visual Studio which is by far the most non-standard setup out there and if you do use it don't use their projects unless you have to. Some good make files with some good rules can help make this pretty easy. I don't know why more people don't do it but look at the Linux kernel's rules file. I have a Rules.make that I've built up and it includes things like different options for debug builds, profiled builds, and optimized builds, sets up some common rules for compiling C++ code and C code and what have you. My makefile include that file and then they are usually pretty short, generally not much more than a list of .cxx files and a library name.
Then it's easy to make sweeping changes too. I think a good build
system, one that will last should usually take a day or two to kind of
put together pretty early on in a project, unless you can carp some
good stuff from another project. The goal is a flexable and reliable
build system that you don't have to worry about. Far too often people
start cobbeling a build system together and then after 6-9 months it's
broken and britle and hard to change because so many things have been
changed and added through out the project. Put some effort in up
front, consolidate your rules in to one place, use some environment
variables to control some build switches. Use some shell scripts to
figure out various things, not hundreds of lines of Bourne shell code,
just little bits. Do this until AAP is ready and rocking and then use
that. Also, if it needs to be said, use GNU Make; it runs damn near
everywhere and it's pretty good at what it does the 15 minutes it
takes to learn it will save you hours and even days worth of time in
the long run.
I'm a huge advocate of a solid and strong build. Mozilla is a project that festered for weeks or maybe even months becuase you couldn't build the damn thing when it went open source. Building code is something that can be done so well by tools that if you're worried about it then you need to fix the build. Building software is hardwork so take the pieces you can out of the equation, the build is the first one.
Next, I assume you've abstracted out the GUI from the meat. If not, make this job one if you wish to have any chance in hell against your one platform competitors or even your mulitplatform competitors when you get down to it. View/Data Model and client/server: learn it, live it, love it. Or switch to a web based interface, lot's of people do it.
While we're on abstraction. If you guys are really serious then you're probably going to have machine specific components. Look at /usr/src/linux/include and /usr/src/linux/arch for a starting point of
reference. I would envision a project like this have a set of small Mips,
Wintel, Linux-x86, etc. directories. Everything else can probably be
compiled with GCC and then in those directories you'd have your
assembly and machine specific compiled code.
Lastly, you want to have a staged check in process. People hate not being able to commit code but at the same time you don't want them to commit code for real until it compiles on all of your platforms. Honestly, I don't know of a really good way to do this. Set up a build lab, do nightlies against the real code. Do nightlies against the "staged" code. Then have some kind of weekly merge meeting. That's how I've seen it, it's time consuming and somewhat painful. You bite off too much and you're spending a shitload of time merging stuff.
gcc 3.2 is generally superior to VC++ emitted code,
in my experience.
Mingw32 is the target of choice if you don't want
to license Cygwin.
-I like my women like I like my tea: green-
I would sugest the same thing though. Write your whole app in Python. That's your base. Port each function that needs to be ported to C++. At the end you'll have something much more maintainable.
"A language that doesn't affect the way you think about programming, is not worth knowing" - Alan Perlis
I don't care so much about Java, but with Python, it's just that a lot of its cool features are also in Lisp, like functions-as-data, classes with metaclasses and the ability to define and change them at runtime, dynamic typing, docstrings, the REPL/interactive prompt, keyword and "rest" arguments to functions, ability to fix bugs without having to stop the running program, ... However, it lacks, for example, macros (don't even try to compare the power and beauty of Lisp macros to the C preprocessor!) and good native code compilers, optional type checking and a variety of free and proprietary implementations all adhering to the same standard.
As for syntax: Both Lisp and Python have the problem that people, esp. newbies, hate their syntax (the parentheses in Lisp and the significant whitespace in Python). Most people eventually get over it and even get to like it. Just because a language doesn't look like C doesn't make it bad.
You are right about the lack of easy-to-find, ready-to-use libraries for common tasks, however (not about the "standardized" part, however. Last I looked there was no Python standard.) There are some projects to change that, for example CLOCC, but there's still a long way to go.
IMHO, the single greatest problem Lisp has is non-technical. It is the (wrong) perception that the only data type in Lisp are lists, that there is no OO, or even iteration, that it is interpreted and slow, and generally dead. I'm not interested in forcing anyone to use Lisp, but I for one do like it, and if you are looking for a cool language to learn next, I'd say you definitely should have a look at it.
Programming can be fun again. Film at 11.