Labview vs. C++

Tim Wescott wrote:
> 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.
>

I once worked a few weeks of a summer for a guy who tried to use a
40-horse Ford to move big sandstone rocks. I had one conversation with
him about the sound of the hydraulics popping, and made it clear I'd
keep a minimum safe distance while he was doing that.

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

-- 
Les Cargill

On Wednesday, July 27, 2016 at 3:24:09 AM UTC+12, Les Cargill wrote:
> Tim Wescott wrote:
> > 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.
> >
> 
> I once worked a few weeks of a summer for a guy who tried to use a
> 40-horse Ford to move big sandstone rocks. I had one conversation with
> him about the sound of the hydraulics popping, and made it clear I'd
> keep a minimum safe distance while he was doing that.
> 
> LabView claims to have some flavor of CUDA support. So there's that.
> 
> -- 
> Les Cargill

LabView has just about everything support nowadays - at a price.
You pay for the huge mathematical libraries it has. A compact Rio FPGA and real-time processor is being used at CERN for instance where money doesn't matter. Great for lab equipment, one offs and simulations but of course way too expensive for mass production. You pay top bucks for the convenience. it has a great COMS squite nowadays and software radio support and is being used by many researchers for an experimental platform for the next generation of wireless systems.

A fantastic idea if only they would make the damned thing cheaper.

On Sun, 31 Jul 2016 10:50:10 -0700, gyansorova wrote:

> On Wednesday, July 27, 2016 at 3:24:09 AM UTC+12, Les Cargill wrote:
>> Tim Wescott wrote:
>> > 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.
>> >
>> >
>> I once worked a few weeks of a summer for a guy who tried to use a
>> 40-horse Ford to move big sandstone rocks. I had one conversation with
>> him about the sound of the hydraulics popping, and made it clear I'd
>> keep a minimum safe distance while he was doing that.
>> 
>> LabView claims to have some flavor of CUDA support. So there's that.
>> 
>> --
>> Les Cargill
> 
> LabView has just about everything support nowadays - at a price.
> You pay for the huge mathematical libraries it has. A compact Rio FPGA
> and real-time processor is being used at CERN for instance where money
> doesn't matter. Great for lab equipment, one offs and simulations but of
> course way too expensive for mass production. You pay top bucks for the
> convenience. it has a great COMS squite nowadays and software radio
> support and is being used by many researchers for an experimental
> platform for the next generation of wireless systems.
> 
> A fantastic idea if only they would make the damned thing cheaper.

Good for really low production, too, which is what my customer is doing.

-- 
Tim Wescott
Control systems, embedded software and circuit design
I'm looking for work!  See my website if you're interested
http://www.wescottdesign.com

Trick question. You have told us neither the type of algorithms you are developing, nor the final implementation fabric. 

Nice try, Tim. 

Or, "It depends." 

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