Labview vs. C++

Sounds good

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

Most NI boards now days have a FPGA NI provides schematic based entry of FPGA code Looks like NI also allows VHDL or Verilog:

So quiz the customer as to whether FPGA computation is allowed If so, they may be planning to convert time critical C++ to FPGA fabric? (and determine how much VHDL/Verilog and Vivado you need to learn)

Jim Brakefield

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

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)

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

itto:

very bad java implementation then.

Bye Jack

critto:

Java is still slow (er than native programs), but only when it has to inter act with things outside the VM (OS, UI, files,...).

Bye Jack

o:

well...

why C++? Because it's the only language you know?

Anyway if they want the algorithm and want to do the implementation in hous e, well it's not your problem.

Bye Jack

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.

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

C++ is the language I know, yes, but if the customer wants to do it in Fortran, or if it can be made fast enough in Java or Python or whatever, then that's fine too.

Left to their own devices they'll try it in Labview, which carries far more risk of it not keeping up.

My "problem" isn't to meet the terms of the contract and successfully demand payment. My "problem" is to help my customer succeed.

As an entirely-to-the-point example, the one time that I've ever rebuilt a trailer hitch was when a customer of my father's showed up with a slammed '50 Merc and a trailer, to pick up a car body he'd just bought. The trailer hitch was such a disaster that my dad told him we wouldn't load the trailer until it was up to snuff.

Then he detailed me to wallow around in the gravel underneath the car, with about a foot of room (because the TALL jackstands were in use) redesigning and rebuilding the trailer hitch so that it'd make the trip back to the guy's house. (Thanks, Dad).

Why? Because for an ethical businessman the _goal_ is customer success. Money is just the byproduct that feeds the kid and staves off the bank.

I have run into analogous situations where the customr wants me to deliver an algorithm, but does not want even sample code as this means (in their thinking) that they are paying for coding it twice. So all they get is a paper design. (Even though I have coded it up anyway.)

The customer is always right. :-)

Steve

Well said. It's how you keep a customer. It's just that simple.

JJS

I wonder if you could estimate without too much effort how much calculation is required, and then ask the customer to run a simple benchmark in Labview that calculates about that much, to see whether it can keep up.

I think that's all you can do, that is, make a recommendation. Sometimes you can write parts of it in red ink, with big arrows pointing at it, but that's really all you can do. If the client doesn't want more than that, then that's where you stop.

I've had to do that on a number of occasions, where you kinda knew things were ultimately gonna go badly, but you did your part as requested. It's never fun or easy.

Sometimes you get to charge extra to come back and clean things up later. ;)

I think that's a good place to leave it, in other words, provide a well-documented algorithm with lots of stated caveats about execution time and latency in the feedback paths, and leave it at that.

then implement the algorithm in C++ and give it to them for free. that probably what they want in the end. and probably for the next job they'll go elswhere.

Unfutunately there aren't a lot of "ethical businnessman" around, they all starved to death.

Bye Jack

I plan on doing that at any rate.

And code for things outside the VM can't be written in Java.

George

I once worked a few weeks of a summer for a guy who tried to use a

LabView claims to have some flavor of CUDA support. So there's that.

Tim Wescott submitted: |------------------------------------------------------------------------| |"[. . .] | | | |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++. | | | |[. . .]" | |------------------------------------------------------------------------|

It does not need to be in C++. VHDL and Ada are fast.

Regards, Colin Paul de Gloucester

There is a LabView to C convertor available from NI. See

Mike