1. Optimization Question for Robert
I'm doing a bit of work with bitmaps, something along the lines of:
bitmap = bitmaps[index]
-- process it
bitmaps[index] = bitmap
My thinking is that when I hit the "process it" portion, Euphoria looks
at the reference count of the bitmap, and realizing that I'm trying to
alter a shared sequence, makes a copy of the original for me.
So I'm thinking that something like:
bitmap = bitmaps[index]
bitmap[index] = {}
-- process it
bitmaps[index] = bitmap
bitmap = {}
would prevent that from happening. I don't know if {} is implemented
specially, or if:
constant Empty = {}
bitmap = bitmaps[index]
bitmap[index] = Empty
-- process it
bitmaps[index] = bitmap
bitmap = Empty
would be better. Is the timing insignifigant, or should I not bother
trying to second-guess the interpreter?
Thanks!
- David Cuny
2. Re: Optimization Question for Robert
David Cuny writes:
> I'm doing a bit of work with bitmaps, something along the lines of:
> bitmap = bitmaps[index]
> -- process it
> bitmaps[index] = bitmap
> My thinking is that when I hit the "process it" portion, Euphoria looks
> at the reference count of the bitmap, and realizing that I'm trying to
> alter a shared sequence, makes a copy of the original for me.
> So I'm thinking that something like:
> bitmap = bitmaps[index]
> bitmap[index] = {}
> -- process it
> bitmaps[index] = bitmap
> bitmap = {}
> would prevent that from happening. I don't know if {} is implemented
> specially...
You are correct. I didn't time it, but it should be a bit faster
the second way above. Euphoria won't copy the entire
2-d bitmap, just the top-level sequence, containing
the pointers to all the rows. The rows will simply have their
refererence count incremented, and later decremented when
bitmaps[index] is overwritten.
In general, you can sometimes save a bit of time
by removing a reference to a sequence earlier,
thus avoiding the need for a copy.
If the variable is declared as a sequence, you can do
this by assigning {}, but otherwise 0 will do the job
using less memory. In your case, bitmap[index] = 0 would
be slightly better.
I've been considering an optimization along these lines,
where Euphoria would remove a reference earlier, when
it was sure that the variable's value would no longer be needed.
This could avoid unnecessary copies. As another example:
x = sort(x)
Currently sort will make a copy of x, but if Euphoria were
a bit smarter, it would realize that x is going to be overwritten,
so there is no need to preserve it's value. If the reference count
were dropped prior to the call, sort would not make a copy.
You have to remember though that the work done in copying
is much less than the work done in sorting, so you wouldn't
see a big speed-up.
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
3. Re: Optimization Question for Robert
Robert Craig wrote:
>If the variable is declared as a sequence, you can do
>this by assigning {}, but otherwise 0 will do the job
>using less memory. In your case, bitmap[index] = 0 would
>be slightly better.
Yeah, that's how I implemented it.
I was trying to figure out if {} was implemented as a "special" value (say,
a pointer to address 0, or a pointer to a globally shared empty sequence),
in which case I figured it would take the same amount of memory as an
integer 0.
Never mind...
>I've been considering an optimization along these lines,
>where Euphoria would remove a reference earlier, when
>it was sure that the variable's value would no longer be needed.
Like this?
dest = source
...
source = dest
Sounds like a lot of work, but you compiler writers are just gluttons for
punishment, right?
> x = sort(x)
Even I can understand this one.
Thanks!
-- David Cuny
4. Re: Optimization Question for Robert
Robert, this sounds like an extremely usefull optimization.
Up until now you've only optimized special cases like this:
s = append(s, x )
s = s & x
And trust me, you'll be suprised what the gain will be with long sequences.
function double (sequence s)
s = s & s
return s
end function
s = double (s)
-- Should be as fast as:
s = s & s
-- Why ?
It will motivate people to structure their code more nicely, since there
will be no speed loss.
If you take a look at some of my programs that require speed, you can see I
inline a lot. And lately, I do a lot of the reference-handle tricks as well.
This will prolly also solve the saving speed of EDOM with extreme large
values (as reported by Terence) wich slowsdown with a factor of 2 as the
length of the data increases. Sounds like copy-ing and re-assigning an
reference every so many times.
And what about compression ?
All routines handling huge amounts of data, will be enourmously sped up by
this and you no longer feel guilthy using routines, and other more clean
ways of programming at the cost of speed.
Ralf Nieuwenhuijsen
nieuwen at xs4all.nl
UIN: 9389920
