Managing Parallel Development in Two Languages?

Abhaga asks: "I work for a technology startup and our research work is mostly done in Matlab. The technology has matured, and now we are looking to build prototypes and products in C++. However, the dilemma is about the further research work/enhancements to the system. Should they be done in Matlab and continuously ported to C++, or is it better to move to C++ once and for all, at this point of time? Anyone having experience with similar things, what should we keep in mind while deciding on one or other."

Comments

Do one thing at a time.

[Anonymous Coward]

Every development project should have a proof of concept phase. You need to know that the underlying idea will work. Get something working however you can. Once you have done that you always have a fallback position that you know works. That's the stage where you use Matlab.

Trying to write C++ code and develop the math at the same time means that you have four times the trouble debugging. If you have a problem you won't be sure whether it's in the math or the code. If you get the math right first, you know that any problems you have are in the code.

Start High, Then Low

[Webz]

With neither experience in parallel development or MATLAB, here's something I've read before (regarding Ruby and C++)...

Start in whatever language happens to be easiest/most high level. Easiest in that whatever helps you express your final product the fastest. Then, when this prototype is up and running, go ahead and reprogram it in C++ for speed.

Think of using the first language as a roadmap, where you can concentrate on organizing your thoughts and getting user requirements out of the way. Done purely in C++, you may be subject to premature optimization or just wasting time re-inventing constructs and concepts that are trivial in the other language.

Re:Start High, Then Low

[swillden]

Are you calling GNU code elegant ? No-one I know that has to cope with GNU code would call it elegant.

What GNU code do you mean? There are many official GNU projects, some very elegant, some rather crufty, most a mixture of both. Your comment makes no sense.

Software wants to be free

[Anonymous Coward]

Get rid of all your Matlab code and rewrite in pure GNU Octave. The parallel development can be done in C with some assembler thrown in. Oh and be sure to license everything under GPL version 3. Then sit back and watch the money roll in off support, donations, and t-shirt sales.

Re:Proprietry lock-in

[antifoidulus]

Wow, talk about being penny wise and pound foolish. I know this isn't popular here on /., but if you are worried about the cost of matlab, then honestly your organization doesn't have a snowball's chance in hell.
If you can save time by using Matlab, even in your very unlikely scenario, the extra cost of the software is still dwarfed by the cost of programmers time as well as the potential losses of being 2nd to market. Unless the software is prohibitively expensive(which Matlab isn't), you need to go with what can get the job done the fastest with the fewest errors.

Choose one language for development.

[jellomizer]

Mixing two languages together will cause problems, Technical/Buisness/Political.

Political: Undoubtedly you will get some changes and fixes that are really easy in one language and a real pain for an other one. So say it takes 5 Minutes in MatLab and could take a week in C++or Vice Versa. Most people don't get this fact especially non professional programmers. So one side group will get a fast change and the other will get the slow change. Thus makes the other group feel like their side isn't as well supported thus making you look really bad.

Business: Maintaining the application will always require people with skill sets in both. Matlab is a rather uncommon skill set while as of right now C++is fairly common. But finding people willing to do both is much harder. As time goes on and as one language leaves common use finding people with these skill sets combined will be very hard and expensive to keep.

Technical: Reported bugs will be need to check on both systems and bug will appear in one system and not the other. But when a bug is reported you will need to check on both systems. And sometime you can easily fix on system and the other requires a major rework. Getting performance on one system to be equivalent to the other will be difficult.

I think you are about to enter a quagmire which you will not come out looking good in. If you do succeed you will probably get a neutral reaction to you work. So it is a Loose/Tie situation. I would spend more time descussing other options. Going one way or the other. Not 2 products that do the same thing but differently.

Re:Choose one language for development.

[maxume]

You have missed the point. They are using C++ to speed up stuff that is initially written in matlab. There are not two separate systems deployed, but a prototype and a product.

Why do this at all?

[kognate]

First, ask yourself why you want to port existing code to a new language? Presumably, the people who are writing
the Matlab code have a facility with Matlab and are subject matter experts that are doing the heavy lifting (algorithmically speaking). Are the C++ coders the same people? If they're not, can you afford to spend the time/staff to do the porting? Should the
original code even be in Matlab in the first place?

You can call matlab libraries from C++ code, which would seem to be the best of both worlds. Then you wouldn't have to port anything.

Lastly, this is not the kind of question that will get answered well on Slashdot. People who have never used matlab will make assumptions and not understand that it is very unlikely that C++ will have the kind of simulation and and capabilities that Matlab does. Besides, a lot of the time Matlab people (scientists, engineers, quants, etc) may be comfortable working Matlab but not C++, so you do what you can to make it possible for them to work. Also, the suggestion that Mathworks will raise pricing and hold your work hostage is laughable: They already do that, their pricing is crazy.

Re:The easy way

[josephdrivein]

I think that they're looking for better performances, porting it to python won't give a great improvement from this point of view. And MATLAB has a _HUGE_ collection of librieries and toolboxes of mathematical functions, even if python comes "with batteries included", it does not feature builtin functions such as coniugate gradient method solver, for example. So it won't be nor faster nor (a lot) easier. Maybe, porting to octave would free him from vendor lock-in, if octave is mature enough.

Compile the Matlab

[jabuzz]

Have you looked into using the Matlab compiler to convert your Matlab code into C/C++. Just keep developing in Matlab and solve your problems.

Do it in C++ from the start

[mangu]

I have done what you said, writing prototypes in Matlab first and porting it later to C++, and it hasn't worked too well. I have found that the two languages are too different, there are always new bugs appearing in the ported code. In my experience, the time spent in developing the math is less than the time spent in the user interface anyway, so I don't see too much problem in developing the math in C++, if you choose a good set of libraries.

However, having said that, I must say that I *do* write small prototypes first, only I do it in C rather than other languages. I also use plenty of small scripts, mostly in Perl, to perform auxiliary operations. But the main code that constitutes the algorithms used in the program should be prototyped as close to the end code as possible. There is no way you could develop an algorithm in Matlab or Python or Ruby and consider its testing a validation for a deliverable program written in C++.

Re:Do it in C++ from the start

[mangu]

if you're implementing an algorithm to solve a 2nd order differential equation using the finite element method or using the shooting method it is hard

Hard? Only if you cannot or don't want to use existing libraries for C++. Now try to find a pre-packaged solution for "they want a button for downloading the data in the same dialog that lets them open an Excel spreadsheet" or any of the infinite other changes one always gets to do in any non-trivial GUI.

Re:Proprietry lock-in

[jellomizer]

Remember US Programmers are payed between 15-150 an hour say MatLab licenses cost $10,000 and Major Upgrades every 2 year.
So that is $5,000 a Year of software cost. Now the programmer will work a 35 hour work week. Now the Cheap Programmer year cost is $26,250 a year and the expensive programmer $262,500 a year. So programmers are more expensive then licenses. So if this tool can make a programmer twice as productive then it is worth the license. So unless the programmer is getting like $3.00 an hour which is less then most outsourcing. The costs to do it in C++ vs. Paying for a license is worth it.

Re:The easy way

[EsbenMoseHansen]

octave 2.9 is pretty awsome. We use it (for solving a lot of Lp problems, with some branch-and-bound), and it works beautiful.

As for the question... I would question the wisdom in abandoning octave (or matlab) at all, but if you do need to do it, do it in small steps. At least, that is the best way in my experience.

Use ITPP C++ library which maps perfetly to matlab

[smogzer]

Drop matlab. Use http://itpp.sf.net/ and stay out of gsl, it's way too complicated to do simple things like matrix operations. For plotting there are great tools for python.

Been there, Done That...

[occamboy]

I assume that the algorithms and math are in Matlab. Matlab is much better than C++ for developing and unit testing math "stuff". However, shipping Matlab libraries with your application means a more complicated setup, licensing issues - and it will look pretty "bush league" (try it you'll see what I mean). Also, I'm guessing that your "domain experts" are more comfortable with Matlab than with C++ - which is why you're asking this question.

I would continue to develop algorithms in Matlab, and use the Matlab compiler to move the algorithms to C++ for integration with the C++ "presentation layer" code. Then compile and ship an all-C++ product.

Re:Ruby is worse

[jlarocco]

Give me a break. Nobody writes Ruby that way.

Ruby is far from perfect, and it's not for everyone, but that can be said for any language. You could at least try to criticize it for its faults, not some guy who programs like a moron.

OMFG!!!1 C is a bastardization. Only crazy zealots program in C, cause they're always doing stuff like this or this. You'd have to be a zealot to use C!

See how stupid that looks?

Don't drop MATLAB

[vijayiyer]

Your algorithm developers will curse you if you stop the use of MATLAB. I use it every day in a mostly Fortran/C shop, and I can get work done in a small fraction of the time it takes the fortran folks. In one case it took me 35 lines of code to do what would take hundreds of lines in fortran. If I need fast runtime, I port it after I've done the development. Writing it twice in this manner is still _far_ quicker than writing it in C or C++ the first time. Ignore the slashdotters who think MATLAB is bad because it's proprietary - I can assure you that they've never used it in a production environment, and don't understand that time == money.

Similar Situation

[robbyjo]

I've been in similar situation, except that we chose Java as opposed to C++ for the "lower" level language. For the higher level langauge, we have both Matlab and R. We're also dealing with research situation. Here's my experience...

• Prototypes are best done in higher level language, in this case, Matlab. Hands down. You want to test a new research methodologies fast. You don't want to get bogged down by unneccessary programming constructs. Moreover, it's the scientist's job who do the prototyping (since he invents the algorithm, right?). Scientists are more familiar with Matlab than C++ or Java.
• Be aware that prototypes are ALWAYS poorly structured. More often than not, they're more like spaghetti code and/or copy and paste. Prototypes are just prototypes. They're just proof of concepts that a particular method works.
• Consequently, you may want a cadre of C++/Java developers to do the structuring. It's more like 4 low level developers per 1 scientist who does the prototyping. Often times the scientists don't know low level languages well. So, it's the C++/Java developers' job to figure out the scientist's program. Of course, the scientist would have to explain how the algorithm / source code works. On the contrary, reading MatLab / R is NOT as hard as what people says here (they must be smoking cracks. Don't listen to them). The only trouble is to familiarize yourself with Matlab / R API, which can be cryptic for some.
• With respect to libraries, Matlab / R have a throng of ready made scientific libraries. Of course, for C++ you can use GSL, LAPACK, ATLAS, etc. But the problem is that sometimes the library call does NOT correspond one-to-one. So, you'll need to tinker around to find out how each library call behaves. Moreover, for some operations, like Matrix / Vector operations, are very simple in Matlab / R, since matrices / vectors can be treated as if they were scalars. Be careful in porting those.
• In addition, you'll need to profile the library call. Make sure you actually GAIN speed with such library calls (or else you'll need to use something else). In addition, speed is NOT the only concern. Accuracy is VERY important. You don't want to use a speedy library with expense of accuracy. In scientific programs, this tradeoff is OFTEN NOT desirable. Make SURE the libraries have the same accuracy level. This is often the grounds to dismiss some unknown library who only claims that they're fast. Losing one degree of accuracy is often a BIG issue in scientific library. For example: If a library is at least 10^-16 accurate may not be acceptable as opposed to a library with an accuracy of at least 10^-17. Think of simulations, which may have millions upon millions of iterations. One degree difference in accuracy often makes a HUGE difference in the final result. Therefore, it is OFTEN more desirable to obtain an open source library where you can inspect the algorithm and point out places where a library call may lose accuracy.
• Familiarize yourselves with many scientific algorithms that improves accuracy. In Matlab or R, they autodetect pathological situations where accuracy can lose. You'll need to do that manually in C++. For example: If you have a nearly singular matrix, you'll need SVD for better accuracy. In general, you can use QR decomposition. If the accuracy is not really an issue, LU decomposition might be enough. In Matlab / R, it can detect the matrix automatically when you try to invert the matrix and use the appropriate algorithm. Pay attention to that. Make sure your C++ program also behaves similarly.
• You MUST make A LOT of regression tests. If it is possible, make the prototype run with the same file format as in the final product. If it isn't possible, convert the file format first and then confirm with the scientist that both of them are exactly the same. Make sure that for all tests, both returns the same numbers

Re:Similar Situation

[mangu]

If you have a nearly singular matrix, you'll need SVD for better accuracy. In general, you can use QR decomposition. If the accuracy is not really an issue, LU decomposition might be enough. In Matlab / R, it can detect the matrix automatically when you try to invert the matrix and use the appropriate algorithm.

Then Matlab must have improved a lot since I last used it (Version 4). A problem I had was that matrices were well behaved with small test cases, but became ill conditioned when we used actual working data. Rewriting everything to use SVD in those cases was a real PITA, since many functions used QR internally and one had to modify the Matlab toolboxes library code. I ended with many adapted functions, like invfreqs_svd instead of invfreqs, for instance.

My conclusion was that, although it did textbook examples perfectly, Matlab wasn't robust enough to handle real-life problems.

Re:Proprietry lock-in

[try_anything]

Matlab also allows the expensive guys with math PhDs to work quickly in a pleasant, familiar, supportive environment. Those guys are smart enough to learn C++ and deal with memory management and templates (often helpful for supremely efficient math code), but it's not a good use of their time if it can be avoided. If you need C++, let the cheap programmers transcribe the Matlab work into C++ and do the tedious job of debugging in C++, while the math guys stay happy and productive in Matlab.

Re:C++

[mangu]

For example: every time you write a function, should it take its arguments by value, by reference, or by pointer?

Good question. I'll answer that if you answer this: every time I get to a street intersection, should I turn right, turn left, or go straight ahead? The answer to both is: it depends. Where do you want to go? If the argument is a basic type that will not be changed, use a value, if it needs to be changed, use a reference, if it's a large structure or array, use a pointer.

A language that ignores such details will not be necessarily safer or easier to code. For instance, should strings be mutable or not? C++ lets you choose, use the "const" modifier to make a string immutable. In languages where this property is fixed you cannot just ignore it, you may have to work around it, at the cost of possible bugs or inefficiency. When I was learning Python, I spent a lot of time in a program because a string wasn't changing when I tried to modify it. After I found out that strings in Python are immutable by design, I had to redesign my program.

C++ hard to learn, but there is a consolation, you only have to learn it once. The biggest problem in learning C++ isn't the complexity of the language itself, but the learning curve. In other languages you can start small and learn as you go, but to be effective in C++ you have to learn many details before you start using it efficiently. OTOH, the syntax is rather well-behaved, you don't have the anomalies you find in Perl, for instance, where variable types depend on the first character of the name, or in Ruby where a block of code is delimited by an "end" in some circumstances and by braces in other cases.

After you have become experienced, coding in C++ is easier than in more "helpful" languages, because you always have the choice of the best method to do everything. Knowing C++ is like riding a cross-country motorcycle. You can go to places you can't reach with either a bus (easier to ride), or a Ferrari (faster in well paved roads with light traffic).

Mathworks already went with Java

[Latent Heat]

What you really want for this project is Java. Really.

Matlab is morphing into a Java scripting language. You know why the Matlab UI takes so long to load these days? Its written in Java, so it needs to load a Java VM when it launches with all of the attendant byte code checking of loaded classes.

Did you know that you can launch Java apps from the Matlab command prompt? That you can also create object instances of individual Java classes and invoke function calls on them? That Matlab automatically manages conversions of array types between the Matlab environment and Java objects? That as of Matlab 7 that Matlab can host Java Swing widgets inside Figure Window GUI's in Matlab?

Forget about C++ GUI's, Python, Ruby, all the stuff people are telling you. Develop your application-specific widgets in Java Swing. Host them in your Matlab GUI for now. When you are ready, release stand-alone Java Swing apps using those same Java widgets. Continue to support Matlab as a scripting environment for your stuff.

Need to do some hard-core numerics in C++? The Java implementations may be fast enough. But if you really need C++, link into it from your Java widgets using JNI. You will need to compile your C++ modules for your different target platforms, but the compiled modules will have different names (YourModule.dll under Windows, libYourModule.so under Linux) so you can distribute all of the modules along with the Java class file that calls them and have cross-platform capability. The JNI takes some mastering, but it is no harder than what you do to write MEX files to call C/C++ directly from Matlab, and there are tons of documentation on the Web.

The people telling you to do a C++ GUI don't know what they are talking about -- you are probably doing a Matlab GUI and may be calling down to C++ in MEX functions. There are C++ solutions -- Qt, wxWidgets, (gasp, choke) MFC/ATL/WTL -- but they will look quited unfamiliar to what you are doing right now. Do your GUI as Swing widgets and you will get Matlab interoperability, a path to ween yourself from Matlab, and a way to operate on all the platforms that have Matlab.