Ops Review

[Chromatic]

           - ceil/floor
           - transcendental ops
           - gcd/lcm/fact
What are you suggesting as replacements?  Or (with the probable
exception of fact) must every language reinvent these wheels?

I had in mind the idea that they could become members of a PBC library.
Do you think that would be fast enough? The usual way for dynamic
languages to get fast compiled numeric code is to bind variables to
hardware types at compile time, and then inline numeric operations in
order to use that information. That seems to require op_i_i_i and
op_n_n_n versions of these ops, which are not language-dependent.

I don't see how Parrot can be fast enough in general without JIT. With JIT,
if these ops are implemented in terms of other ops, there's no speed penalty.

And possibly of other ops as well. Speed should certainly not be an
issue for Parrot 1.0, so I can see not wanting to add new numeric ops,
but I don't see the point of removing ops we already have only to decide
we need them later.

That's a fair point, though it can be difficult to remove ops later.

-- c

[Will Coleda]

On Tue, Jan 20, 2009 at 2:20 PM, Jonathan Worthington

Do you think that would be fast enough? The usual way for dynamic
languages to get fast compiled numeric code is to bind variables to
hardware types at compile time, and then inline numeric operations in
order to use that information. That seems to require op_i_i_i and
op_n_n_n versions of these ops, which are not language-dependent.

I don't see how Parrot can be fast enough in general without JIT. With JIT, if these ops are implemented in terms of other ops, there's no speed penalty.

I think one criteria to consider is, are their architectures out there
(that we're targeting now or likely to) that have the equivalent op
implemented at a CPU instruction level, such that we could JIT it in the
future? If so, there's probably benefit in it staying a Parrot op.
Jonathan
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev

I would rather defer that until we actually target those OSes; let's
stick with our core platforms for now (especially since we don't even
support JIT on all of our core platforms.)

[Jonathan Worthington]

Do you think that would be fast enough? The usual way for dynamic
languages to get fast compiled numeric code is to bind variables to
hardware types at compile time, and then inline numeric operations in
order to use that information. That seems to require op_i_i_i and
op_n_n_n versions of these ops, which are not language-dependent.

I don't see how Parrot can be fast enough in general without JIT. With JIT, if these ops are implemented in terms of other ops, there's no speed penalty.

I think one criteria to consider is, are their architectures out there
(that we're targeting now or likely to) that have the equivalent op
implemented at a CPU instruction level, such that we could JIT it in the
future? If so, there's probably benefit in it staying a Parrot op.

Jonathan