On 7/31/16, 2:18 AM, "Javier Guerrero García" <[email protected]> wrote:
>Alex / Justin: > >Just a general question, related to this thread: why are we just assuming >that a worker implementation should be always faster that a single >threaded >model? I don't think I've said that he's guaranteed to get better performance, but thanks for a great list of issues to consider below. IMO, the main issue isn't so much as to whether the code is "long running" as much as whether the work can in fact be divided. 9 women can't have a baby in a month. Thanks, -Alex >Isn't that heavily dependent on the underlying hardware (and flash >capability to properly use it)? I mean: > >In a single thread implementation, full CPU time available for calculation >only, even forgetting to update UI. CPU's only task it to finish the job, >all resources commit to that job, and every other think is left "on hold" >until job is done (even OS sometimes .... :) > >In a multiple worker implementation, BESIDES THE OBVIOUS APPARENT >RESPONSIVENESS IMPROVEMENT, that same CPU and underlying hardware, in >addition to "getting the job done", has to take also care of: > > - First, prepare the "context" for each worker (data partitioning, > variable replication, ...) and initialize each worker. > - Be in charge for task switching between each worker > - After task switching, resetting the branch prediction caches >(screwing > all previous predictions in the way) for each one of the threads / >loops. > - While at all that, also refresh and update the UI from time to time > - Loop the main thread, and listen to worker finishing signals, >platform > events, mouse events, ... and handle them. > - After all workers finish, combine the results to produce the final > array. > >All that using the same underlying hardware and CPU (benefits would be >obvious if we multithread using several different CPU's, one for each >worker, but that's not the case). > >So, *IF, and ONLY ONLY IF*: > > - the underlying hardware as a pretty good (and true :) multicore > support, keeping branch prediction caches for each core > - all contexts "fit" into one of each core memory space, so no memory > paging is neccesary > - you don't run more workers than cores > - Flash compiler can access and use those cores > - and the splitting/joining tasks are fast > >it could run faster than a single threaded model, right? > >Besides being a more "elegant" solution (at least a more "by the book"), >am >I missing something? Why is everyone so sure that a multithreaded solution >would run faster, hands down? (keeping "computational fashion" aside :) > >On Sun, Jul 31, 2016 at 9:10 AM, Justin Mclean <[email protected]> >wrote: > >> Hi, >> >> > It is bindable. I will try turning off updates. >> >> I would guess it going to be an order or two magnitudes faster - >>depending >> on the changes you make to items in that array collection. >> >> > How do you go about accessing/manipulating an array inside of an >> > array collection? >> >> myAC.source >> >> > I always just address the properties that I need by >> > accessing the arraycollection itself, ie >> > >> > myArrayCollection[1]["someProperty”] >> >> I think lookups like that are going to be slower than using the >> myAC[1].someProp form? >> >> > Should I just declare the variables outside of the loop and >> > just reuse them instead of instantiating them every single time >>inside of >> > the loops? >> >> Certainly worth a try (allocating and garbage collection of 38Kx38KxX >>vars >> cost is likely to be significant) but I’d give scout a try to see where >>the >> time is being taken up first so you know what to optimise. >> >> Thanks, >> Justin
