[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-apl] performance in of ¨
From: |
Xiao-Yong Jin |
Subject: |
Re: [Bug-apl] performance in of ¨ |
Date: |
Sun, 19 Jun 2016 22:55:15 -0500 |
Jürgen, I can confirm that loop problem is fixed.
Christian, that “function” is an operator, same as each (¨). You would find it
listed in )ops, similar to ⎕NL 4, and ⎕NC'FE' would return 4 (as an operator).
In gnu apl you can use )nms to list all the )vars )fns and )ops.
Best,
Xiao-Yong
> On Jun 19, 2016, at 12:16 AM, Christian Robert <address@hidden> wrote:
>
> I think you fixed it. No longer running O(NxN) (still slower than native C++,
> I can live with that, no problems)
>
> btw, When I defined this test function two days ago:
>
>
> f2def 'FE'
>
> )sic
> )erase FE
>
> ∇Z←A (LO FE) B;rho_Z;N;N_max
> rho_Z←⍴B ◊ N←⎕IO ◊ A←,A ◊ N_max←N+⍴B←,B ◊ Z←N_max⍴0
> LOOP: Z[N]←⊂(⊃A[N]) LO ⊃B[N] ◊ →(N_max>N←N+1)⍴LOOP
> Z←rho_Z⍴Z
> ∇
> )fns
> D MEASURE MEASURE2 Replace df f2def ltrim rtrim time
> trim vert
> ⍝ FE does not appear here ! But *is* a function
>
> ⍝ but this function name appear in ⎕nl 4
>
> D ⎕nl ¨ ⍳4
> ┌4──────────────────────┐
> │┌⊖┐ ┌⊖┐ ┌8───────┐ ┌2─┐│
> │⌽ │ ⌽ │ 1D │ ↓FE││
> │└─┘ └─┘ 1MEASURE │ └──┘│
> │ │MEASURE2│ │
> │ │Replace │ │
> │ │df │ │
> │ │f2def │ │
> │ │ltrim │ │
> │ │rtrim │ │
> │ │time │ │
> │ │trim │ │
> │ │vert │ │
> │ └────────┘ │
> └∊──────────────────────┘
>
> what is {quad}nl 4 ?
>
> why 'FE' not displayed in ")fns" ?
>
> Xtian.
>
>
> On 2016-06-18 16:21, Juergen Sauermann wrote:
>> Hi,
>>
>> I believe I have fixed the problem,*SVN **749*.
>>
>> The fault was actually not related to macros but a general problem
>> affecting the performance of virtually all workspaces.
>>
>> The time-consuming line in the EACH macro was this:
>>
>> *LOOP: Z[N]←⊂(⊃A[N]) LO ⊃B[N] ◊ →(N_max>N←N+1)⍴LOOP*
>>
>> Due to an inefficiency in the runtime parser, the parser would, for example,
>> first resolve
>> B (which creates a copy of B) and then index the copy to obtain B[N] . Same
>> for A.
>> If B has N items then this would generate N copies of B, each copy taking
>> O(N) cycles,
>> and therefore the runtime of the above innocent looking LOOP would be O(N×N).
>>
>> Macros are a little slower than their built-in siblings, but the code that
>> could be removed
>> by using macros belonged to the most error-prone in the past, and some of
>> the built-in
>> operators (which are called when their function argument(s) are primitive
>> functions) could
>> also be simplified.
>>
>> /// Jürgen
>>