ensegre
-
Posts
583 -
Joined
-
Last visited
-
Days Won
26
Content Type
Profiles
Forums
Downloads
Gallery
Everything posted by ensegre
-
deconvolution=inverse problem=sensitivity to small denominators difference of large, almost equal numbers=large truncation errors Without seeing the code (maybe even seeing it), it's difficult to say which is more right. Given the kind of problem, anyway, I'd not be surprised that simply rescaling one set of datapoints (you say Hz or Mhz - this already shifts 6 orders of magnitude) gives a better or worse result. If you ever had experience, even with linear regression you may incur in the problem - fitting (y-<y>)/<y> to (x-<x>)/<y> may do wonders. In the code, I'd look first for possible places where you sum and subtract numbers of very different magnitudes, and see if a proper rescaling reduces the spread in magnitudes, while keeping the computation algebraically equivalent. "numerical analysis", proper.
-
Didn't think at it. [NXG claims to support unicode. Didn't try. The issue might exist for extended ascii chars, like latin1 accented chars, as they are coded as 1byte in LV-windows and as UTF8 in LV-linux]. But why passing anything else than basic 7bit ascii to libmuparser at all? I quickly tried /usr/lib/x86_64-linux-gnu/libmuparser.so.2 with muParser demo.vi, accented chars in variables seem illegal.
-
you make it sound more impossible than it reasonably is in this case. libmuparser is at least not unknown to ubuntu, I apparently brought it on 14 and 16 as dependency of meshlib or of some FEM package. Now Porter's toolbox is apparently using a patched version of it to add some syntactical feature, but the toolbox would also work with the off the box version of it. Even with an earlier version, if the ABI didn't change. If, I concede. But LV-muParser could say: requires x.x.x<libmuparser<y.y.y If a locally patched version of the library is so important, to avoid conflicts just give it an insanely improbable name - like libmuparser-with-added-esclamation.so Dump the responsibility to the author of the original library: ./configure; make; make install. If it can be built for the target distro (or if someone bothered to distribute it), ok; if it can't, just don't claim it is supported. I haven't thoroughly looked into, and I'm just a script-kiddy at it anyway, but FWIW nm -C libmuparserX64.so.2.2.4 | grep @ tells me only of GLIBC_2.0, GLIBC_2.3.4, GCC_3.0, CXXABI_1.3, GLIBCXX_3.4 - standard stuff, hopefully not dramatically changing across distros. Anyway - I agree that the effort is best invested in developing the toolbox. I never suggested that the toolbox should provide also compiled .so, and see the reasons why. I was perhaps carried along by the academic discussion, which in my view was in general about the best LV strategy to support different shared libraries for different platforms.
-
more PCs, more money, more performance...
-
6 PCs if you have a high bandwidth and a highly demanding image processing, one PC if you're tight in space or need a single control station. Or 7 PCs, 6 for processing and one for concentrated display. Personally I'd first evaluate the resources you need for a single task, and how many tasks could compete for resources if they run on a single PC, then assess how many PCs you need for upscaling.
-
I get the point. Dynamically referenced will not be visible by the builder as dependency. If I may forgiven for being so stubborn, as a workaround one could still put just one conditional disable structure with the different statically linked CLNs within a false if frame in just one mandatory, but called once, ancillary, and leave all the rest with mupLibPath.
-
For the record I obstinately still tried this, following smithd. Because of "current VI's path" this cannot be inlined, at most given subroutine priority. The result with the previous benchmarks is ~600ns overhead (on ~12us, 5%) on 32bit and ~200ns (on 10.4us, 2%) on 64 bit. Results obviously degrade for less than subroutine priority. mupLibPath.vi
-
So I unzip that on my desktop. This means "/home/owner/Desktop/LabVIEW 2015/Projects/LV-muParser" and "/home/owner/Desktop/LabVIEW 2015/resource/" . Go figure, "/<resource>/libmuparserX32.so.2.2.5" not found...
-
pre-build VI? Possibly... instinctively I'd say the less code the better, but have not benchmarked that.
-
Well, let's be pedantic: CLNbenchmark.vi mupLibPath2.vi (change the library names according to bitness and OS) there is a huge jitter in this benchmarking, to get ~1% variance I need to iterate 1M times, so results are not entirely conclusive testing in parallel like I did earlier was probably not a good idea, suppose libmuparser is single-threaded - indeed running 2 or 3 loops in parallel changes the picture. Testing individually each loop, static library name wins, by perhaps 1% (100ns on 10us) Testing in parallel, each timing is larger (~60%), and jitter is even larger, no clear winner in few attempts I wouldn't be surprised if YMMV in other machines, OS, bitnesses and LV versions I tested on linux LV2015 64bit, 2016 64bit and 2017 32 and 64 bit, results were similar and similarly scattered. On LV2017 32bit I got timings ~25% higher. don't even mention boundary conditions like FP activity Moral, even considering that some time is spent in the libmuparser routines themselves, and some is LV calling overhead, and that the ratio may change from function to function, this overhead is minute, and imho it pays much more to go for the most maintainable solution [hint: inlined subvi with indicator whose default value is set by an install script]. YMMV...
-
This small experiment, if not flawed, would suggest that actually CLN with a name constant is a few tens of ns faster than CLN with name written into. CLNbenchmark.vi
-
A supreme one, but proper scripting might be able to alleviate it. Scripts for checking that each CLN is properly conditionally wrapped, and that each conditional disable has the relevant library in its cases. I understand that performant parsing was one of the main motivations of this exercise; however, maybe let's first benchmark precisely the impact of different solutions.
-
Yesterday I played a little around with constructing an absolute path inside muLibPath.vi, kind of how you did now in the windows case, and the benchmark started crawling. To keep the libraries in the same dir as muLibPath.vi may simplify matters in the IDE but right, you have to do something for the exe. So yes, either devising the path in Construct.vi and passing it along with the class data, or having an installation script fixing the return value of an inlined subvi and saving it, look to me ways to go.
-
Maybe that is an output only argument to mupGetExprVar? It would make little sense that the call sequence has a completely transparent argument. In any case, have you noted the shift register for that pointer? This should keep the case of N=0 exprs from crashing. Apropo which, mupGetExprVars still crashes if called with Parser in=0, that should perhaps be trapped in a production version. yes. Probably sloppiness of the author who didn't push the version number everywhere (I added the X32 and X64 in the names on my own, though). About the choice of the library, I'm still thinking at the best strategy for muLibPath.vi. If one puts more complex path logics into it, that affects very badly performance, as the VI is called for every single CLN. Probably the best is to make an inlined VI out of it, containing only a single path indicator, whose default value is assigned once for good by an installation script. I hope that the compiler is then able to optimize it as a hardwired constant.
-
Debugging off, I realized that it is for inlining; compiled code, I downloaded your first commit on LAVA rather than the latest github. 2015, please: mupLib.zip If ever useful: libmuparser.zip compiled .so for X32 and 64 on ubuntu16. As they are dynamic, I doubt they may be themselves dependent on some other system lib, and hence particular of that distro. I'd also think at a benchmark which iterates on repeated open/evaluate/close. I see it as a frequent use case, and suspect that muparser might do better than the formula parser there.
-
6 PC. We mean, what do you take images for? What is the bandwidth? Are the cameras synchronized? Do the images need to be analyzed together, so that some program decides something according to what is in them? Can the computers exchange messages? What latencies are tolerated? Do the images need to be streamed disk? All these are considerations you have to take into account for a design.
-
Cracked it finally. You were passing the wrong pointer to DSDisposePtr. Here mupLib-path.zip is a corrected version of the whole lvlib. Now all examples and benchmarks run for me in LV2017 32&64, 64bit being marginally faster with the default eq in the benchmark
-
Ok, reporting progress: compiled a 32bit .so of your modified library sudo apt-get install g++-multilib cd muparser-2.2.5 ./configure --build=x86_64-pc-linux-gnu --host=i686-pc-linux CC="gcc -m32" CXX="g++ -m32" LDFLAGS="-L/lib32 -L/usr/lib32 -Lpwd/lib32 -Wl,-rpath,/lib32 -Wl,-rpath,/usr/lib32" make clean make patched muParser.lvlib, to include a target and bitness dependent libmuparser path. Attached, with compiled code removed (orderly: I should submit a pull request on github). mupLib-path.zip Testing on LV2017-32bit: mupLib example.vi WORKS all other examples crash when mupGetExprVars gets to DSDisposePtr, with trace like *** Error in `labview': free(): invalid pointer: 0xf48c3a40 *** Aborted (core dumped) Testing on LV2017-64bit, with system libmuparser 2.2.3 Ditto. Only difference, longer pointer in *** Error in `labview64': free(): invalid pointer: 0x00007f03aa6b78e0 ***
-
Ok, I traced it down to that, for me, muParser Demo.vi crashes on its first call of DSDisposePtr in mupGetExprVars.vi. Just saying.
-
I'm opening some random subvi to check which one segfaults. All those I opened were saved with allow debugging off and separate compiled code off (despite your commit message on github). Any reason for that?
-
Just mentioning, if not OT. Something else not supported are booleans (ok you could use 0 and 1 and + *). In a project of mine I ended up using this, which is fine but simplistic. I don't remember about performance; considering my application it may well be that simple expressions evaluated in less than a ms.
-
It appears that it might be straightforward to make this work on linux too. In fact, I found out that I had libmuparser2 2.2.3-3 already on my system, for I dunno which other dependency need. Would you consider to make provisions for cross platform? Usually I wire the CLN library path to a VI providing the OS relevant string through a conditional disable; LV should have it's own way like writing just the library name without extension, to resolve it as .dll or .so in standard locations, but there may be variants. I just gave a quick try, replacing all dll paths to my /usr/lib/x86_64-linux-gnu/libmuparser.so.2 (LV2017 64b), I get white arrows and a majestic LV crash as I press them, subtleties. I could help debugging, later, though. Also, to make your wrapper work with whatever version of muparser installed systemwise, how badly does your wrapper need 2.2.5.modified? How about a version check on opening?
-
Perhaps you stacked the decoration frontmost, so that it prevents clicking on the underlying controls? Try selecting the beveled rectangle and Ctrl-Shift-J (last pulldown menu on the toolbar)
-
-
Provided that the communication parameters are correct, probably you should initialize once, read no too often and close only when you're really done. Trying to do that 10000 times per second usually impedes communication.
