Menu
▾
▴
opengtoolkit-developers
|
From: ALTENBACH,CHRISTIAN <cal...@uc...> - 2004-04-02 17:56:03
|
> can just pick up were we left off and everyone can get up to speed on > the issues without too much effort. I see several issues that must be discussed. (1) A good set of test strings. =============================== I would think that in real life such a VI typically encounters relatively short inputs with only a few \b characters. (In this respect, the current test string is quite pathological). A VI needs to be fast under all kinds of inputs and should not encounter slowdowns under certain conditions, so I suggest the following set of strings (to be expanded as needed): - an empty string - A short string (currently I use "XX\b\b\b\bAAAA\b\b\bBCC\bDXXX\b\b\b"=ABCD) - Jim's long string - A string of 1000000 characters (no \b!) - A string of 1000000 \b characters - A string of 1000000 characters, all even numbered characters are "\b". Suggestion for scoring: The times for each string are normalized to the fastest time (e.g. if one candidate is 10% slower, it would get a 1.1). Winner will have lowest average score, which could be as low as 1 if it is fastest on all strings (unlikely?). (2) VI settings =============== I am not sure if we should force priorities/reentrant on the VIs as currently done, but if so, what should the settings be? (3) VI execution ================ There are several ways to execute the VIs. Jim uses "invoke node" while my current VI uses "call by reference node". Jim sets the actual VI to "time critical", I set the core tester VI to "time critical", while setting the test subject to subroutine. What is better and why? What more realistically models the use in a real application? (4) Timing ========== Due to the ms timer resolution, the test must last at least a few hundred ms to get a few significant digits. Fast running VIs need to be called inside a loop, with the loop count tuned to the execution time. I would not use any averaging of runs, but do multiple runs, then pick the fastest. (All OS disturbances tend to lengthen the time!) 'later Christian |
|
From: Bookwalter, D. <Dan...@hs...> - 2004-04-03 02:30:25
|
well if you guys really want to test 'any' of your VI's i have someone working where i work that can challengE ANY-thing you can come up with!!!! just me being frustrated, no matter what i do i cant make these programs tight enough for this/these individual(s) not to break it/them.... hell one of these people broke XP within 30 mins... i had to completly re-install XP.... have a good weekend all......... Dan -----Original Message----- From: ALTENBACH,CHRISTIAN To: ope...@li... Sent: 4/2/04 12:56 PM Subject: Re: "Remove Backspace" test harness > can just pick up were we left off and everyone can get up to speed on > the issues without too much effort. I see several issues that must be discussed. (1) A good set of test strings. =============================== I would think that in real life such a VI typically encounters relatively short inputs with only a few \b characters. (In this respect, the current test string is quite pathological). A VI needs to be fast under all kinds of inputs and should not encounter slowdowns under certain conditions, so I suggest the following set of strings (to be expanded as needed): - an empty string - A short string (currently I use "XX\b\b\b\bAAAA\b\b\bBCC\bDXXX\b\b\b"=ABCD) - Jim's long string - A string of 1000000 characters (no \b!) - A string of 1000000 \b characters - A string of 1000000 characters, all even numbered characters are "\b". Suggestion for scoring: The times for each string are normalized to the fastest time (e.g. if one candidate is 10% slower, it would get a 1.1). Winner will have lowest average score, which could be as low as 1 if it is fastest on all strings (unlikely?). (2) VI settings =============== I am not sure if we should force priorities/reentrant on the VIs as currently done, but if so, what should the settings be? (3) VI execution ================ There are several ways to execute the VIs. Jim uses "invoke node" while my current VI uses "call by reference node". Jim sets the actual VI to "time critical", I set the core tester VI to "time critical", while setting the test subject to subroutine. What is better and why? What more realistically models the use in a real application? (4) Timing ========== Due to the ms timer resolution, the test must last at least a few hundred ms to get a few significant digits. Fast running VIs need to be called inside a loop, with the loop count tuned to the execution time. I would not use any averaging of runs, but do multiple runs, then pick the fastest. (All OS disturbances tend to lengthen the time!) 'later Christian ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ OpenGToolkit-Developers mailing list Ope...@li... https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers _____________________________________________________________________ This electronic mail transmission contains confidential information intended only for the person(s) named. Any use, distribution, copying or disclosure by any other person is strictly prohibited. If you received this transmission in error, please send an electronic mail message to pos...@hs.... |
|
From: Paul F. S. <Pa...@SU...> - 2004-04-03 13:14:46
|
I assume that all entries are compiled and saved for the LabVIEW version and platform of testing before hand, but that is an assumption. Changing the priority or reentrancy also causes an asterisk to appear. Do such operations also cause a compile lag on the first run after the change? Paul |
|
From: Jim K. <jk...@ja...> - 2004-04-03 16:35:47
|
Prior to running, changes are made to priority, execution system, etc. and then the VI is saved. This way they are compiled prior to running. -Jim Paul F. Sullivan wrote: > I assume that all entries are compiled and saved for the LabVIEW > version and platform of testing before hand, but that is an assumption. > > Changing the priority or reentrancy also causes an asterisk to appear. > Do such operations also cause a compile lag on the first run after the > change? > > Paul > |
|
From: ALTENBACH,CHRISTIAN <cal...@uc...> - 2004-04-05 07:32:58
|
Well, I made a rough draft of my test suggestion. www.bol.ucla.edu/~caltenba/backspace_testerA010.zip To run, just select a folder containing several VIs conforming to the connector pattern of the backspace VI. It tests 6 different input strings, including empty. It uses the following scoring algorithm: - For each test, divide all times by the fastest to get normalized values. - For each VI, take the average of the normalized values. - Score = 100/Average. (Best possible score is 100% if VI is fastest on all tests.) There are some sparse comments on the diagrams. Lots of loose ends in the code, some held together by duck tape, but it seems to run fine. I'll document it a bit better later. Cheers Christian |
|
From: Brian G. <bri...@da...> - 2004-04-02 20:05:22
|
>can just pick up were we left off and everyone can get up to speed on >the issues without too much effort. > > Here is a copy of my original thoughts sent to Jim: 1. The existing testing only tests a string 1/10 th of the original (at a time). I propose that the input gets switched between a large and small string (minimum). I believe that the transition metrics are of particular interest, ie the first run after the imput changes 2. The first run should not be thrown out, but listed as a metric (LabVIEW now does a good job on resizing arrays in shift regs, but still gets caught when the array size changes significantly. The existing metrics analysis may throw that information out.) 3. Can we randomize the order? 4. Can we create a batch that completely quits LabVIEW between test VI's? 5. We need to verify that the output is correct. 6. Add tests for robustness (empty string, no backspaces, all backspaces, string that results in empty string as a result)? 7. OK to remove the example from the test folder so we can make generic Tester? I should have something to share by this weekend. Brian |
|
From: Jim K. <jk...@ja...> - 2004-04-03 17:23:49
|
Brian Gangloff wrote: > 4. Can we create a batch that completely quits LabVIEW between test VI's? Or even better, how about a LabVIEW executable that controls the development environment? I have been working on a tool called "lvbld" that allows building LabVIEW applications (as defined by .bld files) from the command-line on the Linux and Windows platforms. It is an executable application that communicates with the LabVIEW development environment using VI Server over TCP-IP. This methodology could possibly be used in the Remove Backspace test harness. When lvbld is run, it attempts to connect to LabVIEW using VI Server. If it cannot connect, it launches LabVIEW from the command-line, and then attempts to establish VI Server communication until a timeout is reached (see "lvbld.ini Settings" section, below, for a listing of lvbld settings). Once a VI Server connection (Application Reference) is established a strict VI reference is opened to <.\project\prodisttool.llb\_Build Application from Script.vi> which is called by reference. Finally, when all the builds are complete the remote application is shutdown, if it was not open prior to running lvbld. VI Server does not provide any means for shutting down an application. But, since both lvbld and LabVIEW share the same file system space, LabVIEW can me made to call VIs within lvbld (since LabVIEW executables are just glorified LLBs). A VI called app_exit.vi is included in the lvbld exe and contains a call to the "Quit LabVIEW" primitive. lvbld causes the LabVIEW development environment to run this VI and thereby causing it to exit. If you want to take a look at the lvbld source, it is located here: http://www.openg.org/tiki/tiki-index.php?page=LVBLD+-+Command+Line+Build+Tool -Jim |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X