I hav just returned from a week-long trip and will be moving forward with
the judging.
Regards,
-Jim Kring
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Andreas Nilsson
Sent: Tuesday, May 11, 2004 12:27 AM
To: Info-Labview Mailing List (E-mail)
Mike,
Here is the problem description that I put up on the challenge page.
This isn't an extremely hard challenge, but it is a fun problem. Also,
you can spend additional effort trying to shave off the last few
milliseconds.
-Jim
Marco Tedaldi wrote:
Jim Kring wrote:
Hello Info-LV'ers,
I have started a contest to create a high-performance VI that removes
backspace characters (and the characters preceding them) from a string.
The wining entry will become part of the OpenG Toolkit. (Note that VI
Icons will be judged
Mike,
Based on a lot of similar feedback, we have updated the Functional
Requirements to the following (thanks to Christian Altenbach for his work
on this):
--
Removes all backspaces (Slash Code: \b, ASCII Hex: 0x08) and the
characters preceding them. If there are N
Alex Le Dain wrote:
I would also think that re-entrancy here is only for testing as near to optimum, presumably building a VI into an EXE would achive the same increase in performance as is achieved with reentrant=TRUE, as the UI and debug code are removed then. Is that correct Jim?
We'll sure
Craig Graham wrote:
- Original Message -
From: Marco Tedaldi [EMAIL PROTECTED]
To: Info-LabVIEW [EMAIL PROTECTED]
Sent: Monday, March 29, 2004 12:59 PM
Subject: Re: OpenG Coding Challenge - Remove Backspace
That's just depressing! There are people in the rankint with a speedup
Craig Graham wrote:
Hmm. Just got round to my second approach and it also takes 20ms. However if
I change it to subroutine it comes down to 8ms here. Have the posted
results been normal priority or subroutine?
For the results currently posted, all entry VIs were set to the following:
It will be some work, but something like the evaluation done by NI on the
different submissions. My vote is evaluation for not only minimum time
but memory foot print etc. For the 1st NI challenge I was just out of the
top 10, but I was about 0.1% of the size of any of the top 10. I always
Hmm. Just got round to my second approach and it also takes 20ms. However if
I change it to subroutine it comes down to 8ms here. Have the posted
results been normal priority or subroutine?
--
Dr. Craig Graham, Software Engineer
Advanced Analysis and Integration Limited, UK.
Craig Graham wrote:
Hmm. Just got round to my second approach and it also takes 20ms.
However if I change it to subroutine it comes down to 8ms here.
Have the posted results been normal priority or subroutine?
Apparently the tests are being done reentrant, but not with the VIs set to
Craig Graham [EMAIL PROTECTED] wrote:
Apparently the tests are being done reentrant, but not with the VIs set to
subroutine. Both changes give the same doubling in performance- I assume
from ditching debug and UI code internally.
Does a similar speedup from ditching debug code occur naturally in
Rolf Kalbermatter wrote:
What speeds up things is, that for time critical or subroutine
priority VIs, LabVIEW not only disables front panel updates (done
anyway if the panel is
not open), but even the code necessary to buffer the data for front
panel display. A bitch to debug such a VI, (you
Craig Graham [mailto:[EMAIL PROTECTED] wrote:
Rolf Kalbermatter wrote:
What speeds up things is, that for time critical or subroutine
priority VIs, LabVIEW not only disables front panel updates (done
anyway if the panel is
not open), but even the code necessary to buffer the data for
Paul Brown wrote:
The best way to estimate your speed is to run both the example and your vi
on your machine. Multiply the ratio of these by the speed of the example
on the official machine (1008.6 ms). This should give you a decent
prediction of your official time, despite the differences in
On Wed, 31 Mar 2004 23:01:06 +0100, Craig Graham [EMAIL PROTECTED] wrote:
Apparently the tests are being done reentrant, but not with the VIs set to
subroutine. Both changes give the same doubling in performance- I assume
from ditching debug and UI code internally.
Does a similar speedup
Alex Le Dain [EMAIL PROTECTED] wrote:
Just be careful. The penalty of reentrancy is memory. Marking all your VI's reentrant
might give some increased processing speed but as each instance of the VI has it's own
memory space, so depending on what you're doing making all your VI's reentrant can
Of Jim Kring
Sent: Friday, April 02, 2004 11:33 AM
To: Alex Le Dain
Cc: [EMAIL PROTECTED]; InfoLabVIEW
Subject: Re: OpenG Coding Challenge - Remove Backspace
Alex Le Dain wrote:
I would also think that re-entrancy here is only for testing
as near
to optimum, presumably building a VI
Alex Le Dain wrote:
Oh dear, the list appears to have died again.
Just be careful. The penalty of reentrancy is memory. Marking all
your VI's reentrant might give some increased processing speed but as
each instance of the VI has it's own memory space, so depending on
what you're doing
Sam Behashtei wrote:
Jim,
Are you going to post new times? April 30th deadline is approaching
fast and if you leave it too close to the dead line some of us may not
have a chance to re submit new/improved entries.
-Sam
What kind of message does that give? You're already best so can't be
Jim Kring wrote:
Hello Info-LV'ers,
I have started a contest to create a high-performance VI that removes
backspace characters (and the characters preceding them) from a string.
The wining entry will become part of the OpenG Toolkit. (Note that VI
Icons will be judged separately).
Are the Results on the site really true? I allmost can't believe it! But
I'm trying :-)
They are probably quite true. My best vi so far does it 75 times faster
than the example. Like Jim said, you will need to stop resizing arrays in
order to get the best performance.
Paul Brown
- Original Message -
From: Marco Tedaldi [EMAIL PROTECTED]
To: Info-LabVIEW [EMAIL PROTECTED]
Sent: Monday, March 29, 2004 12:59 PM
Subject: Re: OpenG Coding Challenge - Remove Backspace
That's just depressing! There are people in the rankint with a speedup
of about 160! And I've built
Quoting Marco Tedaldi [EMAIL PROTECTED]:
I tried to build somethin cempletely different (much more complicated).
Marco,
The solution is not always in complexity. Look at the VI memory usage (from
VI properties):
Slow Sample VI: Code: 3.0K, data: 1.2K
My current solution is significantly
Mine does spurious \b's so go for it!
mike
-Original Message-
From: Scott Hannahs [mailto:[EMAIL PROTECTED]
In terms of the problem description, must the VI handle the case where
there
are more \b (backspaces) than there are characters? If this is true then
the
VIs should pass an
: Scott Hannahs; info-labview
Subject: RE: OpenG Coding Challenge - Remove Backspace
Mike,
Based on a lot of similar feedback, we have updated the Functional
Requirements to the following (thanks to Christian Altenbach for his work
on this):
--
Removes all backspaces
I think I have those covered. I don't know enough to shorten my time
anymore. I look forward to seeing the other VIs. I have no ideas how to
make it any cleaner.
It will be some work, but something like the evaluation done by NI on the different
submissions. My vote is evaluation for not
26 matches
Mail list logo
