LCB Performance

[Mark Waddingham]

You might be better off building the primes as a List, then converting to a string at the end. Although the conversion of each number is only done once so it probably doesn't make too much difference (apart from being a bit more LCBy).

In general LCB should be written to prefer structure over strings - it better represents the flow of individual values - which makes any future optimisations at the vm level more effective.

LCB should really be considered the language to use for widgets and foreign extensions - for much algorithmic stuff you'll get better performance from LCS.

To be fast LCB needs an optimisation phase which would lower the level of operations it performs - the internal structure of LCB makes this feasible but as yet not done.

In contrast LCS is pretty quick - it also needs an optimisation phase really - but with its current implementation that's largely infeasible!

(The optimisation phase would actually be the same - the problem is that both need to be translated to a slightly lower level common bytecode form first - then optimised).

Warmest Regards,

Mark.

Sent from my iPhone

> On 7 Aug 2018, at 22:54, Brian Milby via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> This is a continuation of some code introduced in the "valueDiff" thread,
> but wanted to take it in a slightly different direction.  We had some great
> success at getting a process that took over 50 seconds on my machine down
> to under 10 seconds.  It isn't anything that we would actually use in
> production, but I'm sure things like this can help us in the real world.
> 
> I decided to try and port the fastest of the methods over to LCB.  I'm sure
> quite a bit of it is due to my lack of experience, but the speeds were much
> slower.  I ended up putting some hard coded limits in my stack so that LCB
> wasn't used over 100,000 for the List and Array version and 1,000,000 for
> the Byte version.
> 
> What I found was that for arrays, the requirement to convert the number to
> a string killed the performance (my guess anyway).  Here is a full list of
> the various versions that I've tried:
> 
> "Find primes up to 100000, repeat 1 time(s)"
> "Byte (bernd)" - 0.065108 seconds
> "Byte (bwm)" - 0.103379 seconds
> "Byte (alex)" - 0.122581 seconds
> "Array (mark)" - 0.323269 seconds
> "Array (bwm)" - 0.345896 seconds
> "Array (original)" - 0.386326 seconds
> "Byte (LCB)" - 1.125969 seconds
> "List (LCB)" - 136.770451 seconds
> "Array (LCB)" - 845.35211 seconds
> 
> I've updated the stack that I uploaded with the new tests (but one would
> need to compile/install the LCB for the last 3 tests)
> https://milby.us/lc/Primes.livecode
> 
> Here's one of the handlers that I converted:
> 
> public handler getPrimesLCB_List(in pN as Number) returns String
>   variable tMroot as Number
>   variable tPrimes as String
>   variable tIsItPrime as List
>   variable tTenK as List
>   variable tYes as Data
>   variable tNo as Data
>   variable tI as Number
>   variable tJ as Number
>   put the byte with code 66 into tYes
>   put the byte with code 65 into tNo
>   if pN < 2 then
>      return the empty string
>   else if pN = 2 then
>      return "2"
>   end if
>   put (the trunc of sqrt(pN)) - 1 into tMroot
>   put the empty list into tIsItPrime
>   if pN >= 10000 then
>      put the empty list into tTenK
>      repeat 10000 times
>         push tYes onto tTenK
>      end repeat
>      repeat (pN / 10000) times
>         put tTenK & tIsItPrime into tIsItPrime
>      end repeat
>   end if
>   repeat pN mod 10000 times
>      push tYes onto tIsItPrime
>   end repeat
>   put "2" into tPrimes
>   repeat with tI from 3 up to tMroot by 2
>      if tIsItPrime[tI] is tNo then
>         next repeat
>      end if
>      put "\n" & tI formatted as string after tPrimes
>      repeat with tJ from tI^2 up to pN by tI
>         put tNo into tIsItPrime[tJ]
>      end repeat
>   end repeat
>   repeat with tI from tMroot + (tMroot + 1) mod 2 up to pN - 1 by 2
>      if tIsItPrime[tI] is tYes then
>         put "\n" & tI formatted as string after tPrimes
>      end if
>   end repeat
>   return tPrimes
> end handler
> 
> 
> Is there any way to optimize the speed of LCB to meet/exceed the same code
> in LCS or is the intention more for things where the speed isn't the main
> factor (like UI widgets and interacting with external code via FFI)?
> 
> Thanks,
> Brian
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode