Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #24669 > unrolled thread

Labview vs. C++

Back to article view | Back to comp.arch.embedded

Contents

  Labview vs. C++ Tim Wescott <seemywebsite@myfooter.really> - 2016-07-20 18:57 -0500
    Re: Labview vs. C++ spope33@speedymail.org (Steve Pope) - 2016-07-21 00:17 +0000
      Re: Labview vs. C++ Tim Wescott <seemywebsite@myfooter.really> - 2016-07-21 12:30 -0500
        Re: Labview vs. C++ spope33@speedymail.org (Steve Pope) - 2016-07-21 18:01 +0000
        Re: Labview vs. C++ Paul Rubin <no.email@nospam.invalid> - 2016-07-21 12:13 -0700
          Re: Labview vs. C++ Tim Wescott <seemywebsite@myfooter.really> - 2016-07-21 16:50 -0500
        Re: Labview vs. C++ eric.jacobsen@ieee.org (Eric Jacobsen) - 2016-07-21 20:25 +0000
    Re: Labview vs. C++ jim.brakefield@ieee.org - 2016-07-20 19:11 -0700
    Re: Labview vs. C++ Marcel Mueller <news.5.maazl@spamgourmet.org> - 2016-07-21 07:37 +0200
      Re: Labview vs. C++ "Nasser M. Abbasi" <nma@12000.org> - 2016-07-21 01:20 -0500
        Re: Labview vs. C++ Jack <jack4747@gmail.com> - 2016-07-21 07:11 -0700
          Re: Labview vs. C++ George Neuner <gneuner2@comcast.net> - 2016-07-22 02:23 -0400
      Re: Labview vs. C++ Jack <jack4747@gmail.com> - 2016-07-21 07:08 -0700
    Re: Labview vs. C++ Jack <jack4747@gmail.com> - 2016-07-21 07:18 -0700
      Re: Labview vs. C++ Tim Wescott <seemywebsite@myfooter.really> - 2016-07-21 12:37 -0500
        Re: Labview vs. C++ John Speth <johnspeth@yahoo.com> - 2016-07-21 11:22 -0700
        Re: Labview vs. C++ pippo2@disney.com (Jack) - 2016-07-21 23:38 +0200
    Re: Labview vs. C++ Les Cargill <lcargill99@comcast.com> - 2016-07-26 10:29 -0500
    Re: Labview vs. C++ Paul Colin de Gloucester <Gloucester@nicht.At> - 2016-08-12 19:59 +0200
    Re: Labview vs. C++ Mike Smith <email@domain.com> - 2016-09-07 20:54 +0100

#24669 — 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!

[toc] | [next] | [standalone]

#24670

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

[toc] | [prev] | [next] | [standalone]

#24678

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!

[toc] | [prev] | [next] | [standalone]

#24680

Tim Wescott  <seemywebsite@myfooter.really> wrote:

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

>> Tim Wescott  <seemywebsite@myfooter.really> wrote:

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

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

[toc] | [prev] | [next] | [standalone]

#24682

Tim Wescott <seemywebsite@myfooter.really> writes:
>> proposing to include a C++ program 
> They specifically don't want to pay for that -- there will be a Scilab 
> program, but that has run-times roughly comparable to Labview.

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.

[toc] | [prev] | [next] | [standalone]

#24685

On Thu, 21 Jul 2016 12:13:19 -0700, Paul Rubin wrote:

> Tim Wescott <seemywebsite@myfooter.really> writes:
>>> proposing to include a C++ program
>> They specifically don't want to pay for that -- there will be a Scilab
>> program, but that has run-times roughly comparable to Labview.
> 
> 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 plan on doing that at any rate.

-- 

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

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

[toc] | [prev] | [next] | [standalone]

#24683

On Thu, 21 Jul 2016 12:30:49 -0500, Tim Wescott
<seemywebsite@myfooter.really> wrote:

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

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.

[toc] | [prev] | [next] | [standalone]

#24671

On Wednesday, July 20, 2016 at 6:57:07 PM UTC-5, 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.
> 
> -- 
> 
> Tim Wescott
> Wescott Design Services
> http://www.wescottdesign.com
> 
> I'm looking for work -- see my website!

Most NI boards now days have a FPGA
NI provides schematic based entry of FPGA code
Looks like NI also allows VHDL or Verilog: 
  http://www.ni.com/product-documentation/53056/en/
  Which in the case of Vivado compilation allows C/C++ code as well?
Also regards C++: https://decibel.ni.com/content/thread/1270

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

[toc] | [prev] | [next] | [standalone]

#24672

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

[toc] | [prev] | [next] | [standalone]

#24673

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
>

[toc] | [prev] | [next] | [standalone]

#24676

Il giorno giovedì 21 luglio 2016 08:20:39 UTC+2, Nasser M. Abbasi ha scritto:

> 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

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

Bye Jack

[toc] | [prev] | [next] | [standalone]

#24686

On Thu, 21 Jul 2016 07:11:26 -0700 (PDT), Jack <jack4747@gmail.com>
wrote:

>Il giorno giovedì 21 luglio 2016 08:20:39 UTC+2, Nasser M. Abbasi ha scritto:
>
>> 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
>
>Java is still slow (er than native programs), but only when it has to
>interact with things outside the VM (OS, UI, files,...). 

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

George

[toc] | [prev] | [next] | [standalone]

#24675

Il giorno giovedì 21 luglio 2016 07:39:11 UTC+2, Marcel Mueller ha scritto:

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

very bad java implementation then.

Bye Jack

[toc] | [prev] | [next] | [standalone]

#24677

Il giorno giovedì 21 luglio 2016 01:57:07 UTC+2, Tim Wescott ha scritto:
> 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.

well...

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

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

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

Bye Jack

[toc] | [prev] | [next] | [standalone]

#24679

On Thu, 21 Jul 2016 07:18:29 -0700, Jack wrote:

> Il giorno giovedì 21 luglio 2016 01:57:07 UTC+2, Tim Wescott ha scritto:
>> 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.
> 
> well...
> 
>> 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++.
> 
> why C++? Because it's the only language you know?

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.
 
> Anyway if they want the algorithm and want to do the implementation in
> house, well it's not your problem.

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.

-- 

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

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

[toc] | [prev] | [next] | [standalone]

#24681

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

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

JJS

[toc] | [prev] | [next] | [standalone]

#24684

Tim Wescott <seemywebsite@myfooter.really> wrote:

> > Anyway if they want the algorithm and want to do the implementation in
> > house, well it's not your problem.
> 
> 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.

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
-- 
Yoda of Borg am I! Assimilated shall you be! Futile resistance is, hmm?

[toc] | [prev] | [next] | [standalone]

#24710

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

[toc] | [prev] | [next] | [standalone]

#24844

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

[toc] | [prev] | [next] | [standalone]

#24918

On 2016-07-20 23:57:00 +0000, Tim Wescott said:

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

There is a LabView to C convertor available from NI.  See 
http://sine.ni.com/nips/cds/view/p/lang/en/nid/209015

Mike

[toc] | [prev] | [standalone]

Back to top | Article view | comp.arch.embedded

csiph-web