Labview vs. C++

OK.  Neither of the groups to which I'm cross-posting this are 
appropriate.

But, y'all are smart, and I know who to listen to.

Problem: I'm working on a proposal for a customer, for an app that's 
going to require heavy computation and is more or less real time*.  The 
guy I'll be working with the closest is pretty much a 100% LabView 
programmer -- he just doesn't _do_ C, or C++, or Fortran.

The customer wants me to deliver them an algorithm, to which they'll 
write code.  They're pretty firm (for good reason) on wanting to do the 
code in-house, or with local talent.  I'm trying to decide how hard I 
need to push, early on, for the computationally intensive bits to be done 
in C++.

I just Googled, and didn't find any good references on the relative 
speeds of doing things in some compiled language vs. Labview.  If the 
ratio is similar to what you get in Scilab or Matlab, then they need to 
go with C++.

So -- anyone know?  Any comments?

Thanks.

* It's not 100% hard real time, with an "exceed and you die" sort of 
deadline, but after the nominal deadline the slope of the user-crankiness 
vs. delay curve is pretty steep.  Moreover, while _occasional_ delays 
could be tolerated, if the computer just can't keep up then the delays 
will grow ever longer -- and the user ever crankier -- with time.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

I'm looking for work -- see my website!

Tim Wescott  <seemywebsite@myfooter.really> wrote:

> Problem: I'm working on a proposal for a customer, for an app that's 
> going to require heavy computation and is more or less real time*.  The 
> guy I'll be working with the closest is pretty much a 100% LabView 
> programmer -- he just doesn't _do_ C, or C++, or Fortran.

> The customer wants me to deliver them an algorithm, to which they'll 
> write code.  They're pretty firm (for good reason) on wanting to do the 
> code in-house, or with local talent.  

Sounds good

> I'm trying to decide how hard I need to push, early on, for the 
> computationally intensive bits to be done in C++.

I would say, not at all, unless you think your failure to steer them
on the issue might cause the project to collapse and negatively impact 
your future revenues; but even in this scenario you do not want to
directly challenge their internal technical approach.

I would recommend proposing to include a C++ program among your
deliverables to them, so that they have a reference implementation.
You may also want to propose a certain number of your hours as 
post-delivery support.

Steve

On 21.07.16 01.57, Tim Wescott wrote:
> I just Googled, and didn't find any good references on the relative
> speeds of doing things in some compiled language vs. Labview.  If the
> ratio is similar to what you get in Scilab or Matlab, then they need to
> go with C++.

There is no general factor. It depends.

If you do an FFT in LabView it is probably almost as fast as your C++ 
code on the same hardware, since the kernel functions of LabView is C++ 
too and uses appropriate libraries.

But simple code with loops in the LabView code can be quite slow if it 
requires many iterations. In this case I would expect up to 2 orders of 
magnitude.
LabView is AFAIR more or less a functional language which easily can be 
executed on many CPU cores if some of the execution paths are 
independent. In contrast you need to do this job by yourself in C++.

At the end it depends on the absolute required CPU power. As long as it 
fits below the desk paying for new hardware is almost always cheaper 
than paying for people to write smarter code. So only if recent hardware 
is not capable of the task in LabView there is a real need to switch to C++.

A few days ago I ported a small code from Java to C++ (computing 4E9 
numbers with a certain PRNG algorithm). The computation time reduced 
from several years to several days.
(In fact the task was solvable with "Brain" in several minutes - but 
that's a whole different story.)


Marcel

On 7/21/2016 12:37 AM, Marcel Mueller wrote:

> A few days ago I ported a small code from Java to C++ (computing 4E9
> numbers with a certain PRNG algorithm). The computation time reduced
> from several years to several days.

This only says that the Java code was not well written at all.

Current indications all point to Java being as fast (and sometimes
even faster) than C and C++ these days. Just google it.

One random link (July 18, 2016)

http://blog.optionscity.com/java-vs.-c-performance-face-off-part-ii

"In summary, it is clear that the raw performance of modern
Java is equal to, if not superior to C++ systems, and that
the quality of the code is the most important factor in
the performance of the system."

There are many more studies that indicate the same. Sure, there
are area where C or C++ is still faster, but it will be
few percentage points faster in those cases if any, not
multiple of magnitudes faster.  The days when Java was slow are
long behind us. Choice between C/C++ and Java these days
can no longer be about speed, but for other reasons specific
to the project.

> (In fact the task was solvable with "Brain" in several minutes - but
> that's a whole different story.)
>
>
> Marcel
>

On Wednesday, July 20, 2016 at 10:39:11 PM UTC-7, Marcel Mueller wrote:

(snip)
> A few days ago I ported a small code from Java to C++ (computing 4E9 
> numbers with a certain PRNG algorithm). The computation time reduced 
> from several years to several days.
> (In fact the task was solvable with "Brain" in several minutes - but 
> that's a whole different story.)

Either very badly written, or JIT was turned off.

For both C++ and Java, you have to be careful not to do allocation
and deallocation inside inner loops. 

Otherwise, with Java and JIT loops run about as fast as C++.

On Wednesday, July 20, 2016 at 10:39:11 PM UTC-7, Marcel Mueller wrote:
> On 21.07.16 01.57, Tim Wescott wrote:
> > I just Googled, and didn't find any good references on the relative
> > speeds of doing things in some compiled language vs. Labview. 

(snip)

> There is no general factor. It depends.
 
Yes.

> If you do an FFT in LabView it is probably almost as fast as your C++ 
> code on the same hardware, since the kernel functions of LabView is C++ 
> too and uses appropriate libraries.
 
For any of the compute intensive functions, matrix solvers, differential
equation solvers, and such, it should be pretty close.

But if you write complicated calculations using low level operators,
it can be pretty slow.  This is pretty much true of any of the 
interpreted mathematical processors, such as R, Mathematica,
Matlab, and Octave. 

> But simple code with loops in the LabView code can be quite slow if it 
> requires many iterations. In this case I would expect up to 2 orders of 
> magnitude.

Some years ago, I had to speed up a program in R. 

First I did some timing to find where the slow parts were, using an
assembly language routine using RDTSC.  (The time stamp counter
on IA32 processors.)  Then put in calls to simple C routines at the
appropriate places. 

And yes, with not so much work you can get two orders of magnitude
speedup in many cases.

> LabView is AFAIR more or less a functional language which easily can be 
> executed on many CPU cores if some of the execution paths are 
> independent. In contrast you need to do this job by yourself in C++.
 
(snip)

-- glen

can Labview support a "call" or "subroutine" to a module in C?

You write the critical C part and provide documentation and they do the overall Labview.

   

On Thursday, July 21, 2016 at 5:45:57 AM UTC-7, mako...@yahoo.com wrote:
> can Labview support a "call" or "subroutine" to a module in C?

> You write the critical C part and provide documentation and they do the overall Labview.


Seems that R, Mathematica, Matlab and LabView all allow for calling external C routines,
usually through a DLL.

Supplying a DLL and sample code calling it would seem to be a good way to do it.

On Thu, 21 Jul 2016 00:17:30 +0000, Steve Pope wrote:

> Tim Wescott  <seemywebsite@myfooter.really> wrote:
> 
>> Problem: I'm working on a proposal for a customer, for an app that's
>> going to require heavy computation and is more or less real time*.  The
>> guy I'll be working with the closest is pretty much a 100% LabView
>> programmer -- he just doesn't _do_ C, or C++, or Fortran.
> 
>> The customer wants me to deliver them an algorithm, to which they'll
>> write code.  They're pretty firm (for good reason) on wanting to do the
>> code in-house, or with local talent.
> 
> Sounds good
> 
>> I'm trying to decide how hard I need to push, early on, for the
>> computationally intensive bits to be done in C++.
> 
> I would say, not at all, unless you think your failure to steer them on
> the issue might cause the project to collapse and negatively impact your
> future revenues; but even in this scenario you do not want to directly
> challenge their internal technical approach.

My job is to point them in the direction of success.  If that means that 
using the computing language they're comfortable with won't lead to 
success, then I need to point that out to them -- even if they don't like 
it.  I won't beat them with a stick, but they need to understand.

> I would recommend proposing to include a C++ program among your
> deliverables to them, so that they have a reference implementation. You
> may also want to propose a certain number of your hours as post-delivery
> support.

They specifically don't want to pay for that -- there will be a Scilab 
program, but that has run-times roughly comparable to Labview.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

I'm looking for work -- see my website!

On Thu, 21 Jul 2016 05:45:43 -0700, makolber wrote:

> can Labview support a "call" or "subroutine" to a module in C?

Yes, that's what they're doing now with the current revision.

> You write the critical C part and provide documentation and they do the
> overall Labview.

Yes, but this time _they_ want to write all of it (for tax reasons -- it 
doesn't have to make sense if it's for tax reasons).

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

I'm looking for work -- see my website!