1. Edita on 4.0b3 (r3124)
- Posted by petelomax Mar 27, 2010
- 1636 views
Still runs like a dog... Hacked it down to another ref count foulup very similar to the last:
function ConvertTabs(sequence intxt) return intxt end function constant MAX=100000 sequence filetext filetext = {repeat("1234567890\n",MAX)} atom t t = time() for i=1 to MAX do -- if i<=length(filetext[1]) then filetext[1][i] = ConvertTabs(filetext[1][i]) -- else -- ?9/0 -- end if if remainder(i,4000)=0 then printf(1,"unpacking %d\n",i) end if end for printf(1,"%3.2fs\n",time()-t)
Above works fine. Uncomment the (pointless) length test and it is three thousand, eight hundred and seventeen times slower.
Pete
PS: Jesse reported problems with the old version of Edita/Arwen (reserved word 'label' on line 210 etc). These were fixed in 0.3.2 all along, the entry in the archive now points at http://www.edita.isgreat.org.
2. Re: Edita on 4.0b3 (r3124)
- Posted by mattlewis (admin) Apr 02, 2010
- 1448 views
Still runs like a dog... Hacked it down to another ref count foulup very similar to the last:
Thanks, that's very helpful. Basically, the temp referenced in the length call doesn't get released until after the end if. I suppose the better way to deal with this is to insert a DEREF_TEMP at the start of the main if block, each elsif block, and the final else block. The key, though is noticing when there is no else block, and creating one to make sure the temp is not leaked.
Matt
3. Re: Edita on 4.0b3 (r3124)
- Posted by mattlewis (admin) Apr 02, 2010
- 1498 views
Still runs like a dog... Hacked it down to another ref count foulup very similar to the last:
Thanks, that's very helpful. Basically, the temp referenced in the length call doesn't get released until after the end if. I suppose the better way to deal with this is to insert a DEREF_TEMP at the start of the main if block, each elsif block, and the final else block. The key, though is noticing when there is no else block, and creating one to make sure the temp is not leaked.
This is now fixed in svn:3131.
Matt
4. Re: Edita on 4.0b3 (r3124)
- Posted by petelomax Apr 04, 2010
- 1421 views
Thanks, that's very helpful. Basically, the temp referenced in the length call doesn't get released until after the end if. I suppose the better way to deal with this is to insert a DEREF_TEMP at the start of the main if block, each elsif block, and the final else block. The key, though is noticing when there is no else block, and creating one to make sure the temp is not leaked.
This is now fixed in svn:3131.
Matt
Thanks. I am pleased to say Edita now runs OK on r3132
Of course I immediately tried something else ("if filetext[1]=filetext[1] then", if you must know) which ran fine on r3132 but gave me problems on Phix. So, I examined your mods to parser.e, which gave me two thoughts:
(NB: this is now firmly in low-priority territory)
First, you may not need the additional code. My analysis (I use different opcodes to you, remember) was that only 8 things create dangerous refcounts (move?, subscript, slice, append, prepend, concat, repeat, and make sequence), and only 8 things "clone" due to non-1 refcounts (replace element, replace slice, append, prepend, concat, make sequence, repeat, and of course any form of call). Hence eg:
if length(filetext[1]) then flag = 1 end if
Whether you can avoid the extra code in such cases is another matter.
Secondly, the beast that is the hidden temp of function return values:
object x, y constant MAX = 10000 atom t0, t1, t2 function f(object x) return x end function t0 = time() for i=1 to MAX do x = repeat(1,100000) if length(f(x)) then x = append(x,1) end if end for t1 = time() y = repeat(1,100000) for i=1 to MAX do x = repeat(1,100000) if length(f(y)) then x = append(x,1) end if end for t2 = time() printf(1,"with:%3.2fs, without:%3.2f\n",{t1-t0,t2-t1}) --if getc(0) then end if
Much less severe than previous examples, about 6x slower (not at all bad compared to the expected 100,000 times slower!), and as said no impact on any real-world code, just thought you might like to know.
Regards, Pete
5. Re: Edita on 4.0b3 (r3124)
- Posted by mattlewis (admin) Apr 04, 2010
- 1372 views
Of course I immediately tried something else ("if filetext[1]=filetext[1] then", if you must know) which ran fine on r3132 but gave me problems on Phix. So, I examined your mods to parser.e, which gave me two thoughts:
Phix? Is this you eu implemented in assembly (formerly in Parrot)?
(NB: this is now firmly in low-priority territory)
First, you may not need the additional code. My analysis (I use different opcodes to you, remember) was that only 8 things create dangerous refcounts (move?, subscript, slice, append, prepend, concat, repeat, and make sequence), and only 8 things "clone" due to non-1 refcounts (replace element, replace slice, append, prepend, concat, make sequence, repeat, and of course any form of call). Hence eg:
if length(filetext[1]) then flag = 1 end if
Whether you can avoid the extra code in such cases is another matter.
Yes, that's possibly a next place to go. I'd started doing something like this, but the way I'd gone about it was too complex and buggy. So I backtracked to the way things were before, and we get more additional reference counts than we technically need, but don't accidentally miss a place with an op where we didn't normally need it, but did in some circumstances. This becomes especially important when you start using delete routines, which are incredibly useful.
The translator does a bit better on these counts, as it sometimes has a little extra information about what's going on. At least, the reference count is decremented closer to the increment, since it can afford a bit more processing when looking at opcodes.
Secondly, the beast that is the hidden temp of function return values:
-- snipped
Much less severe than previous examples, about 6x slower (not at all bad compared to the expected 100,000 times slower!), and as said no impact on any real-world code, just thought you might like to know.
I don't get slower results at all using svn:3133. Here were my results (both runs had with trace, and the second had without inline):
$ eui func with:3.29s, without:3.30 $ eui func with:3.28s, without:3.29
Perhaps a difference with how refcounts are dealt with? Was the 6x with Phix or eu?
Matt
6. Re: Edita on 4.0b3 (r3124)
- Posted by petelomax Apr 04, 2010
- 1345 views
Phix? Is this your eu implemented in assembly (formerly in Parrot)?
Yup. (windows only, but serves my needs)
This becomes especially important when you start using delete routines, which are incredibly useful.
Tell me more. What are delete routines?
I don't get slower results at all using svn:3133. Here were my results (both runs had with trace, and the second had without inline):
$ eui func with:3.29s, without:3.30 $ eui func with:3.28s, without:3.29
Perhaps a difference with how refcounts are dealt with? Was the 6x with Phix or eu?
Both. Phix is actually 9x, bit slower with the problem, bit faster without, btw. The problem vanishes here under with trace as well. Try it without trace.
Pete
7. Re: Edita on 4.0b3 (r3124)
- Posted by mattlewis (admin) Apr 05, 2010
- 1355 views
This becomes especially important when you start using delete routines, which are incredibly useful.
Tell me more. What are delete routines?
See the documentation for delete_routine() and delete(). Basically, they're a way to add the equivalent of a destructor (to use C++ terms) when a euphoria object is garbage collected. They only apply to atoms represented as doubles (integers are automatically promoted) or sequences. Some built-ins now use them, as well as some library code.
Take a look at allocate() for an example that automatically frees your pointer for you when the value is no longer referenced. open() also does this for you. Basically, you can do RAII in euphoria now. That's the main thing that drove the redesign of the refcount system. The regular expression data created by PCRE when you compile, etc, regular expressions is also released this way.
Both. Phix is actually 9x, bit slower with the problem, bit faster without, btw. The problem vanishes here under with trace as well. Try it without trace.
Aha. That did it. Also, without inline 'fixes' it as well. Though the slowdown for me is a little less than 2X. Looks like inlined function results need some work.
Matt
8. Re: Edita on 4.0b3 (r3124)
- Posted by mattlewis (admin) Apr 05, 2010
- 1311 views
Looks like inlined function results need some work.
svn:3135 fixes this.
Matt
