[perl #30230] [PATCH] add Fixed(Integer|Float|Boolean|String|PMC)Array classes
Matt Fowles
# Please include the string: [perl #30230]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=30230 >
All~
This patch adds the above Fixed*Array classes. They are basic tests for
all of them included too, although more tests never hurts...
I will probably do the Resizable ones tomorrow.
Matt
Dan Sugalski
>This patch adds the above Fixed*Array classes. They are basic tests for
>all of them included too, although more tests never hurts...
With MANIFEST patch even! Woohoo!
Applied, thanks.
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Leopold Toetsch
> At 10:12 PM -0700 6/11/04, Matt Fowles (via RT) wrote:
>>This patch adds the above Fixed*Array classes. They are basic tests for
>>all of them included too, although more tests never hurts...
> With MANIFEST patch even! Woohoo!
> Applied, thanks.
1) Is there any good reason to start now malloc(3) based array classes?
This leads to code duplication for all the utility vtable entries (like
C<splice>). F<src/list.c> can deal with all types already.
2) What's the difference between *PMCArray and *BooleanArray?
leo
Dan Sugalski
>Dan Sugalski <d...@sidhe.org> wrote:
>> At 10:12 PM -0700 6/11/04, Matt Fowles (via RT) wrote:
>>>This patch adds the above Fixed*Array classes. They are basic tests for
>>>all of them included too, although more tests never hurts...
>
>> With MANIFEST patch even! Woohoo!
>
>> Applied, thanks.
>
>1) Is there any good reason to start now malloc(3) based array classes?
>This leads to code duplication for all the utility vtable entries (like
>C<splice>). F<src/list.c> can deal with all types already.
list.c's pretty inefficient for most array usage. It's good for
mixed-type, sparse, or really big arrays, but for normal arrays it's
overkill. A big wad of memory's just fine there.
>2) What's the difference between *PMCArray and *BooleanArray?
The PMC arrays hold PMCs. The Boolean arrays hold true/false values only.
Leopold Toetsch
> At 11:57 AM +0200 6/14/04, Leopold Toetsch wrote:
>>
>> 1) Is there any good reason to start now malloc(3) based array classes?
>> This leads to code duplication for all the utility vtable entries (like
>> C<splice>). F<src/list.c> can deal with all types already.
> list.c's pretty inefficient for most array usage. It's good for
> mixed-type, sparse, or really big arrays, but for normal arrays it's
> overkill. A big wad of memory's just fine there.
Well, yes. It depends on the usage of the PMC, which isn't known. What
about shift/unshift? Are these allowed for fixed sized arrays?
I'd vote for optimizing list.c for the "small usage pattern" and switch
to a different strategy for big arrays.
Anyway, the patch #30245 Resizable*Array implements these arrays on top
of fixed size. We had that some times ago with Array/PerlArray. It was
around 100 times slower for growing usage like:
@ar[$_] = $x for (0..$N)
for some big $N.
And it of course duplicates existing classes like IntList, which just
needs to get renamed.
>> 2) What's the difference between *PMCArray and *BooleanArray?
>
>
> The PMC arrays hold PMCs. The Boolean arrays hold true/false values only.
Then it should really store just one bit instead of a word.
leo
Dan Sugalski
>Dan Sugalski wrote:
>>At 11:57 AM +0200 6/14/04, Leopold Toetsch wrote:
>>>
>>>1) Is there any good reason to start now malloc(3) based array classes?
>>>This leads to code duplication for all the utility vtable entries (like
>>>C<splice>). F<src/list.c> can deal with all types already.
>
>>list.c's pretty inefficient for most array usage. It's good for
>>mixed-type, sparse, or really big arrays, but for normal arrays
>>it's overkill. A big wad of memory's just fine there.
>
>Well, yes. It depends on the usage of the PMC, which isn't known.
>What about shift/unshift? Are these allowed for fixed sized arrays?
Given that they change the size of an array... no.
>I'd vote for optimizing list.c for the "small usage pattern" and
>switch to a different strategy for big arrays.
I wouldn't. list.c is designed for a different set of usage than the
common array. Making it handle both common "wad of memory filled with
a single type" arrays and the much-less-common "sparse array of
multiple types" arrays doesn't make much sense.
Better to have the array have the needed smarts to upgrade itself to
the more heavyweight array type if it really needs to.
>Anyway, the patch #30245 Resizable*Array implements these arrays on
>top of fixed size.
So? I'm well aware that the implementation is suboptimal. Hell, the
commit message and the messages on the list make that clear. That
really, *really* doesn't matter for this. The point here is to get
the types in, get their behaviour correct, and nail them down as
guaranteed. How they do their thing is entirely irrelevant to that.
>>>2) What's the difference between *PMCArray and *BooleanArray?
>>
>>
>>The PMC arrays hold PMCs. The Boolean arrays hold true/false values only.
>
>Then it should really store just one bit instead of a word.
So fix it if you want. This is first cut code. There's plenty of time
to optimzie it later.