Prev: Few question about gradient/deriv and saving a vector function...
Next: StreamSmart
From: Gurveer on 27 Nov 2009 01:08
Hi

Performing some matrix calculations in System RPL, I didn't find a big
time difference as compared to User RPL. Can they somehow be made
faster in SysRPL? I only deal with real matrices and of order atmost
10 X 10(rarely, usually around 4). The basic operations I use are /,
*, +, -, inverse, transpose, etc. to do some stuff related to complete
least squares, Taylor Series Linearization, etc.

Thanks in advance.

Regards,

Gurveer
From: Raymond Del Tondo on 27 Nov 2009 02:04
Hi,

usually the UserRPL functions dispatch to SysRPL code,
and the core matrix access functions are coded in ML anyway,
so if you don't want to do real-time graphics,
there's not much to be gained IMHO;-)

HTH

Raymond

"Gurveer" <gurveer.sra(a)gmail.com> schrieb im Newsbeitrag
news:839ab21d-634b-483b-a87b-0663d2861bec(a)f18g2000prf.googlegroups.com...
> Hi
>
> Performing some matrix calculations in System RPL, I didn't find a big
> time difference as compared to User RPL. Can they somehow be made
> faster in SysRPL? I only deal with real matrices and of order atmost
> 10 X 10(rarely, usually around 4). The basic operations I use are /,
> *, +, -, inverse, transpose, etc. to do some stuff related to complete
> least squares, Taylor Series Linearization, etc.
>
> Thanks in advance.
>
> Regards,
>
> Gurveer


From: Gurveer on 27 Nov 2009 16:53
I was going through some other posts too and wondered if overclocking
could prove to be of any help.

Any idea?

Regards,

Gurveer
From: John H Meyers on 27 Nov 2009 18:03
On Fri, 27 Nov 2009 00:08:26 -0600, Gurveer wrote:

> Performing some matrix calculations in System RPL,
> I didn't find a big time difference as compared to User RPL.

UserRPL has only a _per-command_ overhead for some protection
(argument validation) and housekeeping (command name,
argument and stack depth saving for errors and for LASTARG).

The internal functions are not going to make themselves
any faster when called from a user command
then when directly called instead of the user command.

Significant savings may occur when you find that
by using a wider assortment of internal tools,
you can accomplish something much more directly
or efficiently than when restricted to UserRPL,
but when performing a time-consuming operation
(e.g. matrix calculations)
for which a single user command exists,
there just isn't much to save.

Similarly, there are situations where an elaborate,
special-purpose ML function is only a little faster
than when implemented in SysRPL, one example being
implementations of VARS, in which a small (40-byte)
SysRPL function is very satisfactory,
compared against a quite larger ML function
(VARS in the HP48S/G series was internally implemented
in an extremely slow manner, hence alternatives were provided
in a "Hack" library, in which there was both a larger ML
and a smaller SysRPL version, inviting such a comparison).

Some "internal" functions rely solely on UserRPL --
for example, the SEQ command actually creates a text string
containing a UserRPL program, then compiles and executes it,
which may be the most extreme case of "just get the darned thing
done, in as few ROM bytes as possible" ;-)

[r->] [OFF]
From: Gurveer on 27 Nov 2009 20:08
On Nov 27, 4:03 pm, "John H Meyers" <jhmey...(a)nomail.invalid> wrote:
> On Fri, 27 Nov 2009 00:08:26 -0600, Gurveer wrote:
> > Performing some matrix calculations in System RPL,
> > I didn't find a big time difference as compared to User RPL.
>
> UserRPL has only a _per-command_ overhead for some protection
> (argument validation) and housekeeping (command name,
> argument and stack depth saving for errors and for LASTARG).
>
> The internal functions are not going to make themselves
> any faster when called from a user command
> then when directly called instead of the user command.
>
> Significant savings may occur when you find that
> by using a wider assortment of internal tools,
> you can accomplish something much more directly
> or efficiently than when restricted to UserRPL,
> but when performing a time-consuming operation
> (e.g. matrix calculations)
> for which a single user command exists,
> there just isn't much to save.
>
> Similarly, there are situations where an elaborate,
> special-purpose ML function is only a little faster
> than when implemented in SysRPL, one example being
> implementations of VARS, in which a small (40-byte)
> SysRPL function is very satisfactory,
> compared against a quite larger ML function
> (VARS in the HP48S/G series was internally implemented
> in an extremely slow manner, hence alternatives were provided
> in a "Hack" library, in which there was both a larger ML
> and a smaller SysRPL version, inviting such a comparison).
>
> Some "internal" functions rely solely on UserRPL --
> for example, the SEQ command actually creates a text string
> containing a UserRPL program, then compiles and executes it,
> which may be the most extreme case of "just get the darned thing
> done, in as few ROM bytes as possible" ;-)
>
> [r->] [OFF]

Thanks! Good to know that:-)

Regards,

Gurveer
 | 
Pages: 1
Prev: Few question about gradient/deriv and saving a vector function...
Next: StreamSmart