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

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.

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.

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.

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.

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.

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: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.

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