On Fri, 2004-04-23 at 15:34, Dan Sugalski wrote:
> At 3:25 PM -0400 4/23/04, Aaron Sherman wrote:
> >That I did not know about, but noticed Dan pointing it out too. I'm
> >still learning a lot here,
>
> It might be best, for everyone's peace of mind, blood pressure, and
> general edification, to
Aaron Sherman <[EMAIL PROTECTED]> wrote:
> On Fri, 2004-04-23 at 14:52, Leopold Toetsch wrote:
>>
>> I'd posted that as well. Here again with an O3 build of parrot:
> Oops, missed that. Thanks! I'm shocked by the difference in
> performance... it makes me wonder how efficient the optimization+JIT
At 3:25 PM -0400 4/23/04, Aaron Sherman wrote:
That I did not know about, but noticed Dan pointing it out too. I'm
still learning a lot here,
It might be best, for everyone's peace of mind, blood pressure, and
general edification, to take a(nother) run through the documentation.
The stuff in docs
On Fri, 2004-04-23 at 14:52, Leopold Toetsch wrote:
> Aaron Sherman <[EMAIL PROTECTED]> wrote:
>
> > What might be interesting is to compare Parrot to Parrot doing this with
> > and without a hyper-operator. That's all I was trying to say.
>
> I'd posted that as well. Here again with an O3 build
Aaron Sherman <[EMAIL PROTECTED]> wrote:
> What might be interesting is to compare Parrot to Parrot doing this with
> and without a hyper-operator. That's all I was trying to say.
I'd posted that as well. Here again with an O3 build of parrot:
$ time parrot ih.imc
6060
real0m0.214s
user
At 2:09 PM -0400 4/23/04, Aaron Sherman wrote:
As for the DOD: you have an excellent point, but it extends far beyond
the hyper-operators. I'm starting to think that front-ends like the
Python compiler or the Perl 6 compiler are going to need controls over
the DOD for just the reasons you cite. Aft
Note: We've moved past hyper-ops (I hope!), but there are still some
details in this post that deserve a response on tangential topics.
On Wed, 2004-04-21 at 11:52, Leopold Toetsch wrote:
> Aaron Sherman <[EMAIL PROTECTED]> wrote:
> > That's unrealistic.
>
> No. A real test.
Sorry, I was not c
At 3:58 PM -0400 4/22/04, Aaron Sherman wrote:
On Wed, 2004-04-21 at 15:46, Larry Wall wrote:
On Wed, Apr 21, 2004 at 03:15:37PM -0400, Dan Sugalski wrote:
: The math folks tell me it makes sense. I can come up with a
: half-dozen non-contrived examples, and will if I have to. :-P
I've said thi
On Wed, 2004-04-21 at 15:46, Larry Wall wrote:
> On Wed, Apr 21, 2004 at 03:15:37PM -0400, Dan Sugalski wrote:
> : The math folks tell me it makes sense. I can come up with a
> : half-dozen non-contrived examples, and will if I have to. :-P
>
> I've said this before, and I'll keep repeating it ti
On Thu, Apr 22, 2004 at 10:29:39AM -0400, Aaron Sherman wrote:
: That said, I now see why hyper goes in Parrot... maybe. It depends on
: how dynamic Perl is about lazy arrays (e.g. "my int @foo = 1..Inf")
As dynamic as it needs to be. The built-in array type has to know how
much of the array is r
On Wed, 2004-04-21 at 13:51, Larry Wall wrote:
> In any event, it is absolutely my intent that the builtin array
> types of Perl 6 support PDL directly, both in terms of efficiency
> and flexibility. You ain't seen Apocalypse 9 yet, but that's what
> it's all about. Straight from my rfc list fil
On Thu, Apr 22, 2004 at 12:14:27AM +0200, Leopold Toetsch wrote:
: I don't care and mathematicians will like to be able to override e.g.
: »*«.
None of my mail on this subject seems to be getting through to
p6i, and I'm getting frustrated. Perl 6 will *not* be allowing
mathematicians to turn »« i
On Wed, Apr 21, 2004 at 02:01:35PM -0600, Doug McNutt wrote:
: I understand that it's not practical extraction and report generation
: and understandably shouldn't be built into perl 6, but the individual
: override capability seems important to me.
I think if you want a mathematical dwim metaoper
On Wed, Apr 21, 2004 at 03:15:37PM -0400, Dan Sugalski wrote:
: The math folks tell me it makes sense. I can come up with a
: half-dozen non-contrived examples, and will if I have to. :-P
I've said this before, and I'll keep repeating it till it sinks in.
The math folks are completely, totally, b
On Wed, Apr 21, 2004 at 11:04:56AM -0400, Simon Glover wrote:
: Why? I was under the impression that in Perl 6 it was going to be
: possible to declare arrays that only contain values of a particular
: type -- I believe the syntax I saw was:
:
:my @array is float;
Just for the record, that
Jeff Clites <[EMAIL PROTECTED]> wrote:
> On Apr 21, 2004, at 9:05 AM, Leopold Toetsch wrote:
[ just another f'up to separate items ]
> So are you saying, have separate vtable slots for the hyper operations,
> but then you only have to fill in the vtable->hyper_add() slot _if_ you
> want it to do
Jeff Clites <[EMAIL PROTECTED]> wrote:
> On Apr 21, 2004, at 9:05 AM, Leopold Toetsch wrote:
> Although, I would think that "@ary += 1" would extend the length of the
> array by one. That is, I can think of logical uses for the
> currently-unimplemented arithmetic ops on PerlArray.
I can think of
At 15:15 -0400 4/21/04, Dan Sugalski wrote:
>At 10:24 AM -0700 4/21/04, Jeff Clites wrote:
>>then there wouldn't be any temptation to think of >>+<< as a separate operator.
>
>I think... that'd be bad, generally speaking. (And not just because the math folks
>have tensors and know what to do with
At 10:24 AM -0700 4/21/04, Jeff Clites wrote:
So are you saying, have separate vtable slots for the hyper
operations, but then you only have to fill in the
vtable->hyper_add() slot _if_ you want it to do something other than
applying vtable->add() in a loop (otherwise, do what your
proof-of-con
Aaron Sherman <[EMAIL PROTECTED]> wrote:
> In fact, Parrot Data Language (if there were such a thing) would likely
> introduce its own runtime-loadable opcode set to operate on a new PMC
> type called a piddle.
It would likely base the piddle object on Parrot's internal datatypes
like IntvalArray
On Apr 21, 2004, at 9:05 AM, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
I'm drawing the distinction between an operation
on the container and an operation on all the
container's contents here. I think it's the right
distinction.
Sure. But the prefix C just is the distinction.
Aaron Sherman <[EMAIL PROTECTED]> wrote:
> On Tue, 2004-04-20 at 18:06, Leopold Toetsch wrote:
>> Well, yes. Except for the special case, which is nice though:
>>
>> $ time parrot ih.imc #[1]
>> real0m0.370s
>>
>> $ time perl i.pl #[2]
>> real0m5.656s
> That's unrealistic.
No. A re
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> I'm drawing the distinction between an operation
> on the container and an operation on all the
> container's contents here. I think it's the right
> distinction.
Sure. But the prefix C just is the distinction. PerlArray's add,
add_int, bitwise whatever v
At 11:04 AM -0400 4/21/04, Simon Glover wrote:
On Wed, 21 Apr 2004, Aaron Sherman wrote:
>
You don't want to have to convert to-and-from arrays of PMCs in order to
do those ops, and regardless of what kind of hyper-nifty-mumbo-jumbo you
put into Parrot, that's exactly what you're going to have
At 4:00 PM +0200 4/21/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 10:55 PM +0200 4/20/04, Leopold Toetsch wrote:
Do you want to reserve these just for implementing perl's scalar context
of arrays or hashes, or is there more behind the scene?
More behind the scenes. (Tho
On Wed, 21 Apr 2004, Aaron Sherman wrote:
> On Wed, 2004-04-21 at 10:13, Simon Glover wrote:
>
> > Absolutely -- I really, _really_ want to be able to use hyper ops with
> > fixed size, floating point arrays, and to have that be as fast as
> > possible, as that should make it possible to imple
On Wed, 2004-04-21 at 10:13, Simon Glover wrote:
> Absolutely -- I really, _really_ want to be able to use hyper ops with
> fixed size, floating point arrays, and to have that be as fast as
> possible, as that should make it possible to implement something like
> PDL in the core.
Mistake.
Yo
On Tue, 2004-04-20 at 18:06, Leopold Toetsch wrote:
> Aaron Sherman <[EMAIL PROTECTED]> wrote:
This horse is getting a bit ripe, so I'm going to skip most of the
detail. I think we all agree on most of the basics, we just disagree on
what to do with them. That's cool.
I do want to pick a couple o
On Wed, 21 Apr 2004, Leopold Toetsch wrote:
> PMC-only means, that you'll always have to call e.g. get_integer on the
> PMC, because the PMC might be tied. This limitation isn't really good
> for performance reasons. People might use it most likely in combination
> with natural typed arrays.
Ab
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 10:55 PM +0200 4/20/04, Leopold Toetsch wrote:
>>
>>Do you want to reserve these just for implementing perl's scalar context
>>of arrays or hashes, or is there more behind the scene?
> More behind the scenes. (Though that's a good reason too) The proble
At 10:55 PM +0200 4/20/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 8:10 PM +0200 4/20/04, Leopold Toetsch wrote:
[ unused scalar vtables in aggregates ]
Aren't the relevant vtable slots for aggregates unused anyway?
Only because we've not gotten around to writing the c
On Tue, Apr 20, 2004 at 04:30:42PM -0400, Dan Sugalski wrote:
: At 4:20 PM -0400 4/20/04, Aaron Sherman wrote:
: >On Tue, 2004-04-20 at 11:53, Dan Sugalski wrote:
: >
: >> Y'know... let's just go all the way with this, since we're going to have
: >> to.
: >>
: >> We'll add a hyper version of all t
Jeff Clites wrote:
On Apr 20, 2004, at 3:06 PM, Leopold Toetsch wrote:
hyper
Px += 4 # add 4 to each column in data base
How does this look in pasm? Is it supposed to be:
hyper
add P0, 4
Exactly that.
If it's the former, it seems really odd to have an op which modifies the
meani
On Apr 20, 2004, at 3:06 PM, Leopold Toetsch wrote:
hyper
Px += 4 # add 4 to each column in data base
How does this look in pasm? Is it supposed to be:
hyper
add P0, 4
or is it:
hyperadd P0, 4
If it's the former, it seems really odd to have an op which modifies
the meani
Aaron Sherman <[EMAIL PROTECTED]> wrote:
> Why does Parrot need this? What's so special about hyper operations that
> makes Parrot want to take them on?
The special thing is optimizing for integers and floats. The bad thing
is overridden »op« for aggregates holding PMCs. These might do whatever
t
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 8:10 PM +0200 4/20/04, Leopold Toetsch wrote:
[ unused scalar vtables in aggregates ]
>>Aren't the relevant vtable slots for aggregates unused anyway?
> Only because we've not gotten around to writing the code. :)
Do you want to reserve these just fo
On Tue, 2004-04-20 at 16:30, Dan Sugalski wrote:
> Because they can be overridden separately from the regular version of
> the operation.
Of course.
Quoting A3 (note, syntax has changed, but as far as I know, the content has not):
@a ^* @b
is equivalent to this:
At 4:20 PM -0400 4/20/04, Aaron Sherman wrote:
On Tue, 2004-04-20 at 11:53, Dan Sugalski wrote:
Y'know... let's just go all the way with this, since we're going to have to.
We'll add a hyper version of all the vtable entries.
Another of those darned "I don't get it" posts, but I'll keep this on
On Tue, 2004-04-20 at 1:26PM, Aaron Sherman wrote:
>
> Another of those darned "I don't get it" posts, but I'll keep
> this one short.
>
> Why does Parrot need this? What's so special about hyper
> operations that makes Parrot want to take them on?
I'm not sure I entirely get it myself, but perhap
On Tue, 2004-04-20 at 11:53, Dan Sugalski wrote:
> Y'know... let's just go all the way with this, since we're going to have to.
>
> We'll add a hyper version of all the vtable entries.
Another of those darned "I don't get it" posts, but I'll keep this one
short.
Why does Parrot need this? What'
At 8:10 PM +0200 4/20/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
We'll add a hyper version of all the vtable entries. Since this is
going to bloat the hell out of the vtable, we'll do it by adding a
VTABLE *hyper to the main vtable structure and hang it off there.
Aren't
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> We'll add a hyper version of all the vtable entries. Since this is
> going to bloat the hell out of the vtable, we'll do it by adding a
> VTABLE *hyper to the main vtable structure and hang it off there.
Aren't the relevant vtable slots for aggregates unu
At 4:28 PM +0200 4/20/04, Leopold Toetsch wrote:
I've implemented a (rather hackish and incomplete) new opcode called
C. Usage looks like:
ar = new IntList
ar = 100
hyper
ar = 10
or
hyper
ar += 10
The atached tests fill an integer array with one Meg int constants
and
I've implemented a (rather hackish and incomplete) new opcode called
C. Usage looks like:
ar = new IntList
ar = 100
hyper
ar = 10
or
hyper
ar += 10
The atached tests fill an integer array with one Meg int constants and
then increment each value 5 times.
Here are the
44 matches
Mail list logo
