Reply by Paul Colin de Gloucester●August 12, 20162016-08-12
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
Reply by julius●August 2, 20162016-08-02
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."
Reply by Tim Wescott●July 31, 20162016-07-31
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
Reply by ●July 31, 20162016-07-31
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.
Reply by Les Cargill●July 26, 20162016-07-26
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
Reply by Tim Wescott●July 23, 20162016-07-23
On Fri, 22 Jul 2016 18:34:08 -0700, gyansorova wrote:
> On Thursday, July 21, 2016 at 11:57:07 AM UTC+12, 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!
>
> LabView runs about the same speed as C++. When you press the run button
> it compiles into the native code of the computer. A great way to write
> code.
> However, you are better using a compact Rio or single board Rio if he
> wants real-time because a PC is non-deterministic. You need a real-time
> OS and a Rio gives you this and FPGA for the front end.
It's real time in the "tons-o-math to be done in seconds" sense, rather
than "hit the nail on the head within a millisecond" sense. We've got a
previous version that's working fine.
Thanks for the comment on speed. I may still want to do benchmarks, but
it sounds like I don't need to worry much, if at all.
--
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
Reply by ●July 22, 20162016-07-22
On Thursday, July 21, 2016 at 11:57:07 AM UTC+12, 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!
LabView runs about the same speed as C++. When you press the run button it compiles into the native code of the computer. A great way to write code.
However, you are better using a compact Rio or single board Rio if he wants real-time because a PC is non-deterministic. You need a real-time OS and a Rio gives you this and FPGA for the front end.
Reply by ●July 21, 20162016-07-21
On Thursday, July 21, 2016 at 2:54:23 PM UTC-7, Tim Wescott wrote:
(snip on algorithms, distribution, and implemention)
> I really don't mind just delivering an algorithm, and I've had good
> success with doing that on two or three occasions. Basically, there's
> people out there who have a flair for propping a scientific paper next to
> their 'puter screen and churning out code to make it real, even if they
> could never come up with the math themselves.
Some time ago, I wrote a JBIG2 compressor from the description.
It took some time to get right, and the result of mistakes can be interesting.
Adobe reader has had the decompressor for some years now, so I could write PDFs
and test them that way. With a small enough mistake, it will work for a while, until a
rare data combination occurs, after which it produces pretty much random bits.
First I got it to properly compress all zero (white) input. Then all black input.
Then progressively more complicated input.
The last bug I had to fix only occurred when the input data width isn't a multiple
of eight. (That is, not an integer number of bytes wide.) With 400dpi data, it was
fairly easy to generate multiple of eight, but sometime later I didn't do that.
If there is an easy test for correctness, then it should be fine to distribute
the description only. Otherwise, you need a way to verify the implementation.
-- glen
Reply by Eric Jacobsen●July 21, 20162016-07-21
On Thu, 21 Jul 2016 16:54:15 -0500, Tim Wescott
<seemywebsite@myfooter.really> wrote:
>On Thu, 21 Jul 2016 13:22:05 -0700, herrmannsfeldt wrote:
>
>> On Thursday, July 21, 2016 at 10:55:09 AM UTC-7, Tim Wescott wrote:
>>> On Thu, 21 Jul 2016 05:45:43 -0700, makolber wrote:
>>
>> (snip)
>>> > 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).
>>
>> OK, but the solution also doesn't have to make sense, for tax reasons.
>>
>> There is a story from some years ago (might have changed) that the tax
>> rate on pick-up truck assembled in Japan and US was different.
>>
>> Japanese pick-up truck makers would build chassis and bodies in Japan,
>> ship them to the US, put the bodies on the chassis, and they were now US
>> assembled. No matter that 99% of the assembling was in Japan.
>>
>> The tax rules for software might be different, but it might be that you
>> can send a C function, and sample LabView code for calling C,
>> and the customer writes the actual LabView to C call for tax purposes.
>>
>> Tax laws could be completely different, but with a tax lawyer you might
>> find the right solution.
>>
>> Or you might, for example, write the algorithm in Java with a sample to
>> call the Java static method. An appropriately written Java static
>> method should translate to C relatively directly, yet for legal
>> purposes, even more than the case above, the C code is newly written.
>>
>> (It seems to me that in many ways Java is more C like than C++ is C
>> like. I believe that was intentional.)
>
>I really don't mind just delivering an algorithm, and I've had good
>success with doing that on two or three occasions. Basically, there's
>people out there who have a flair for propping a scientific paper next to
>their 'puter screen and churning out code to make it real, even if they
>could never come up with the math themselves.
>
>If they can find one, they'll do just fine.
>
I've been that guy many times. ;)
Reply by Tim Wescott●July 21, 20162016-07-21
On Thu, 21 Jul 2016 13:22:05 -0700, herrmannsfeldt wrote:
> On Thursday, July 21, 2016 at 10:55:09 AM UTC-7, Tim Wescott wrote:
>> On Thu, 21 Jul 2016 05:45:43 -0700, makolber wrote:
>
> (snip)
>> > 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).
>
> OK, but the solution also doesn't have to make sense, for tax reasons.
>
> There is a story from some years ago (might have changed) that the tax
> rate on pick-up truck assembled in Japan and US was different.
>
> Japanese pick-up truck makers would build chassis and bodies in Japan,
> ship them to the US, put the bodies on the chassis, and they were now US
> assembled. No matter that 99% of the assembling was in Japan.
>
> The tax rules for software might be different, but it might be that you
> can send a C function, and sample LabView code for calling C,
> and the customer writes the actual LabView to C call for tax purposes.
>
> Tax laws could be completely different, but with a tax lawyer you might
> find the right solution.
>
> Or you might, for example, write the algorithm in Java with a sample to
> call the Java static method. An appropriately written Java static
> method should translate to C relatively directly, yet for legal
> purposes, even more than the case above, the C code is newly written.
>
> (It seems to me that in many ways Java is more C like than C++ is C
> like. I believe that was intentional.)
I really don't mind just delivering an algorithm, and I've had good
success with doing that on two or three occasions. Basically, there's
people out there who have a flair for propping a scientific paper next to
their 'puter screen and churning out code to make it real, even if they
could never come up with the math themselves.
If they can find one, they'll do just fine.
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
I'm looking for work -- see my website!