Re: n arity with method

[Damien Mattei <damien.mattei@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2532 bytes --]

yes ,indexing is overloaded ,using same procedure for vector,string,hash
table ,this take times but the slower is the infix precedence operator
algorithm that is called each time even if the formula in a loop never
change,example in:
(for-each-in (j (in-range len_layer_output)) ; line
   (for-each-in (i (in-range len_layer_input)) ; column , parcours les
colonnes de la ligne sauf le bias
       {M_i_o[j {i + 1}]  <-  M_i_o[j {i + 1}] - {(- η) * z_input[i] *
მzⳆმz̃(z_output[j] z̃_output[j]) * ᐁ_i_o[j]}})

        ; and update the bias
     {M_i_o[j 0]  <-  M_i_o[j 0] - {(- η) * 1.0 * მzⳆმz̃(z_output[j]
z̃_output[j]) * ᐁ_i_o[j]}}))

{M_i_o[j {i + 1}]  <-  M_i_o[j {i + 1}] - {(- η) * z_input[i] *
მzⳆმz̃(z_output[j] z̃_output[j]) * ᐁ_i_o[j]}} is expanded at each 'for'
loop iteration in:

($nfx$
  (bracket-apply M_i_o j (+ i 1))
  <-
  (bracket-apply M_i_o j (+ i 1))
  -
  (*
   (- η)
   (bracket-apply z_input i)
   (მzⳆმz̃ (bracket-apply z_output j) (bracket-apply z̃_output j))
   (bracket-apply ᐁ_i_o j)))

with evaluation of $nfx$ (see code in :
https://github.com/damien-mattei/Scheme-PLUS-for-Kawa/blob/main/scheme-infix.scm)
and many bracket-apply (
https://github.com/damien-mattei/Scheme-PLUS-for-Kawa/blob/main/apply-square-brackets.scm
) even if the expression never change, the numeric computation change, but
not the symbolic evaluation of operator precedence.

This could be precomputed by Scheme+ before compilation by Kawa or any
Scheme that use Scheme+ but this is a big work i have not begin.

Damien

On Sun, Nov 19, 2023 at 6:50 PM Per Bothner <per@bothner.com> wrote:

> On 11/18/23 23:23, Damien Mattei via Kawa wrote:
> > when comparing speed on the first part of my program written in Scheme+
> it
> > run in 15" with Kawa and 7" in Racket.
>
> It is likely you can speed up Kawa quite a bit by fixing a few slow spots.
> Specifically, anytime you do run-time reflection (or worse: eval/load)
> you're
> going to lose a lot of performance. If you can replace generic arithmetic
> or vector/list indexing with type-specific arithmetic/indexing that can
> also make a big difference. List processing (especially if you call cons
> a lot) is always going to be relatively expensive.
>
> Profiling is probably the thing to try. I do little-to-no Java programming
> these days, so I can't be any more specific with help.
> --
>         --Per Bothner
> per@bothner.com   http://per.bothner.com/
>