Breaking the 50% CPU limit in Flash

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Re: [haXe] Breaking the 50% CPU limit in Flash

laurence taylor
gonzo programming...

"Like most others, I was a seeker, a mover, a malcontent, and at times a stupid hell-raiser. I was never idle long enough to do much thinking, but I felt somehow that some of us were making real progress, that we had taken an honest road, and that the best of us would inevitably make it over the top. At the same time, I shared a dark suspicion that the life we were leading was a lost cause, that we were all actors, kidding ourselves along on a senseless odyssey. It was the tension between these two poles - a restless idealism on one hand and a sense of impending doom on the other - that kept me going." 

On Wed, Jun 22, 2011 at 10:20 PM, Raoul Duke <[hidden email]> wrote:
On Wed, Jun 22, 2011 at 12:36 PM, laurence taylor
<[hidden email]> wrote:
> You can handle parallelism by specifying your program in Arrows and letting a scheduler handle thread execution. The benefit of this
> approach is that there is no notational difference between an event based program, a single threaded program, a multithreaded program,
> or one calling multiple remote components. /rant

you're hired!

:-)

--
haXe - an open source web programming language
http://haxe.org


--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Re: [haXe] Breaking the 50% CPU limit in Flash

singmajesty
In reply to this post by Michael Cann
I was talking to a head engineer who works at Adobe, and he said that they  
were looking at doing some kind of "background worker" type of threading  
... trying to create something that is simple and reliable enough. I would  
presume that Flash Player itself is single-threaded, so it may require  
some key work in the runtime to support an API like this. Handling it  
automatically would probably be a very bad idea



On Wed, 22 Jun 2011 12:19:26 -0700, Michael Cann <[hidden email]>  
wrote:

> Well this isnt an adobe problem strictly and rather a larger issue
> of parallel programming in general.
>
> Its difficult to parrellise a program, at what point do you split it?  
> How do
> you handle race conditions and deadlocking?
>
> Sure Adobe should give us worker threads so we can perform our expensive
> jobs in them (and they have hinted many times that they are coming soon),
> but you are still going to have the difficult problem of working out  
> where
> to split you program.
>
> Mike
>
> On 22 June 2011 20:08, Rob Fell <[hidden email]> wrote:
>
>>
>> On 11:59 AM, Joe Dohn wrote:
>>
>>> That settles it then. Thanks :)
>>>
>>>
>>> Will Adobe ever address this or are we doomed to live with 5%- CPU when
>>> we'll have 20+ cores? O_o
>>>
>>>  Hang in there!  If not already familiar, check out the Web Worker
>> approach in js and start planning your code design accordingly.
>>
>>
>>
>>>
>>>
>>> --- On *Tue, 6/21/11, Michael Cann /<[hidden email]>/* wrote:
>>>
>>>
>>>    From: Michael Cann <[hidden email]>
>>>    Subject: Re: [haXe] Breaking the 50% CPU limit in Flash
>>>    To: "The haXe compiler list" <[hidden email]>
>>>    Date: Tuesday, June 21, 2011, 7:44 PM
>>>
>>>    Yep, I have a quad core and you get 25% total CPU usage if you
>>>    write a never-ending while loop.
>>>
>>>
>>
>> --
>> haXe - an open source web programming language
>> http://haxe.org
>>
>
>
>


--
Using Opera's revolutionary email client: http://www.opera.com/mail/

--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Breaking the 50% CPU limit in Flash

Chris Ochs
In reply to this post by Joe Dohn
The flash GC is not thread safe.  We embed the flash vm (tamarin) in C and run multiple vm's each in their own thread with their own copy of the gc which works fine.  Passing gc'd objects between threads won't work.  Sharing a gc with multiple threads works but has the same restriction, you can't pass gc'd objects between threads.   So you won't be seeing native threads you can use arbitrarily coming to flash anytime soon.  Being that I don't think they want users to shoot themselves in the foot, you will probably only see threads being used in Adobe's proprietary code where they can control everything, and only for very specific use cases, like where you run some type of engine in a thread that communicates via a queue to the rest of flash.

Chris



--
haXe - an open source web programming language
http://haxe.org
Reply | Threaded
Open this post in threaded view
|

Re: Re: [haXe] Breaking the 50% CPU limit in Flash

Chris Ochs
In reply to this post by singmajesty
On Wed, Jun 22, 2011 at 2:29 PM, Joshua Granick
<[hidden email]> wrote:
> I was talking to a head engineer who works at Adobe, and he said that they
> were looking at doing some kind of "background worker" type of threading ...
> trying to create something that is simple and reliable enough. I would
> presume that Flash Player itself is single-threaded, so it may require some
> key work in the runtime to support an API like this. Handling it
> automatically would probably be a very bad idea
>

Ya that would work, The trick is what does the interface for passing
objects between threads look like given the restrictions of the GC.
It's not super difficult I've done it a couple of different ways, but
it is potentially expensive depending on what you want to send to a
worker.  You have to convert the object you want to send to some
intermediate thing that's not under the control of the GC, then
instantiate a new object on the other side.  One way we did this was
using bytearrays.  Bytearray goes into queue, read into C string, and
written into another bytearray in the other thread.

Chris

>
>
> On Wed, 22 Jun 2011 12:19:26 -0700, Michael Cann <[hidden email]>
> wrote:
>
>> Well this isnt an adobe problem strictly and rather a larger issue
>> of parallel programming in general.
>>
>> Its difficult to parrellise a program, at what point do you split it? How
>> do
>> you handle race conditions and deadlocking?
>>
>> Sure Adobe should give us worker threads so we can perform our expensive
>> jobs in them (and they have hinted many times that they are coming soon),
>> but you are still going to have the difficult problem of working out where
>> to split you program.
>>
>> Mike
>>
>> On 22 June 2011 20:08, Rob Fell <[hidden email]> wrote:
>>
>>>
>>> On 11:59 AM, Joe Dohn wrote:
>>>
>>>> That settles it then. Thanks :)
>>>>
>>>>
>>>> Will Adobe ever address this or are we doomed to live with 5%- CPU when
>>>> we'll have 20+ cores? O_o
>>>>
>>>>  Hang in there!  If not already familiar, check out the Web Worker
>>>
>>> approach in js and start planning your code design accordingly.
>>>
>>>
>>>
>>>>
>>>>
>>>> --- On *Tue, 6/21/11, Michael Cann /<[hidden email]>/* wrote:
>>>>
>>>>
>>>>   From: Michael Cann <[hidden email]>
>>>>   Subject: Re: [haXe] Breaking the 50% CPU limit in Flash
>>>>   To: "The haXe compiler list" <[hidden email]>
>>>>   Date: Tuesday, June 21, 2011, 7:44 PM
>>>>
>>>>   Yep, I have a quad core and you get 25% total CPU usage if you
>>>>   write a never-ending while loop.
>>>>
>>>>
>>>
>>> --
>>> haXe - an open source web programming language
>>> http://haxe.org
>>>
>>
>>
>>
>
>
> --
> Using Opera's revolutionary email client: http://www.opera.com/mail/
>
> --
> haXe - an open source web programming language
> http://haxe.org
>

--
haXe - an open source web programming language
http://haxe.org
12