Re: Proposal for fixing race conditions

On Wed, Jul 17, 2013 at 8:41 PM, Chris Rogers <crogers@google.com> wrote:

>
>
>
> On Tue, Jul 16, 2013 at 7:24 PM, Srikumar Karaikudi Subramanian <
> srikumarks@gmail.com> wrote:
>
>> Your hypothetical test case merely demonstrates the difference; my point
>> is that it is silly to optimize for imaginary edge cases at the cost of
>> real-world use cases where developers will get unexpected results due to
>> leaving race conditions in this API. I should also note that it has come up
>> in past discussions that we could always introduce new no-copy APIs that
>> don't contain races, if the cost of memcpy is so severe.
>>
>>
>> It is not inconceivable to make an audio editor which plays an audio file
>> from a specific sample onwards by assigning the buffer to an
>> AudioBufferSourceNode and using start(t,offset,duration) ... possibly
>> followed by effects. Large files (even 5mins?) would be unusable with such
>> an editor if a copy were involved and clients/devs will be forced to do
>> crazy optimizations just to get it to work. Now shift that situation to an
>> iPad with limited memory and it can get worse. DAWs are a use case for the
>> API.
>>
>> With Jer's example code, it would be possible to simulate such a
>> (reasonable) case.
>>
>> What might, I think, be acceptable is a one-time copy provided the copy
>> can be reused without additional cost. As far as I can see, immutable data
>> structures are the best candidates to solve the race conditions.
>>
>> That said, I do find the argument (I think Rogers') that the worst thing
>> that can happen with these race conditions is unexpected audio output and
>> hence they are not very important an interesting stand.
>>
>
> You're simplifying my position a bit.  What I'm saying is there are no
> sensible or normal calling patterns where this type of race conditions is
> even a possibility.  As the API is designed and has been used for over 2
> years, these calling patterns are not used and so simply are not an issue.
>  We do have substantial developer experience to support this view, and
> these developers come from a wide range of backgrounds and experience
> levels from complete novices playing with audio for the first time, all the
> way to seasoned professional audio developers.
>
>
If we look at it from this angle instead: Do you think that it would be a
problem for Web developers if one browser neuters arrays (as the FF
implementation currently does - which I think doesn't violate the spec),
but another browser doesn't?

/Marcus



> Chris
>
>
>
>>
>> -Kumar
>>
>> On 17 Jul, 2013, at 7:13 AM, "K. Gadd" <kg@luminance.org> wrote:
>>
>> Of course you can claim hypothetical performance benefits from any
>> particular optimization, my point is that in this case we're considering
>> whether or not to leave *race conditions* in a new Web API because we think
>> it might make it faster. We *think* it *might*. Making that sort of
>> sacrifice in favor of 'performance' without doing any reproducible,
>> remotely scientific testing to see whether it's actually faster, let alone
>> fast enough to justify the consequences, seems rash to me.
>>
>> It should be quite easy to test the performance benefits of the racy
>> version of the API, as based on my understanding the Firefox implementation
>> currently makes copies. You need only run your test cases in Firefox with
>> SPS and see how much time is spent making calls to memcpy to get a rough
>> picture of the actual overhead. And once you know that, you can look at how
>> your test cases actually perform and see if the cost of that memcpy makes
>> it impossible to ship an implementation that makes those copies.
>>
>> I am literally unable to imagine a use case where the cost of the copies
>> would add up to the point where it would remotely be considered a
>> bottleneck. It is the case that the copies probably have to be synchronous,
>> so I could see this hurting the ability to trigger tons and tons of sounds
>> in a single 'frame' from JS, or set tons and tons of curves, etc. But
>> still, memcpy isn't that slow, especially for small numbers of bytes.
>>
>> Your hypothetical test case merely demonstrates the difference; my point
>> is that it is silly to optimize for imaginary edge cases at the cost of
>> real-world use cases where developers will get unexpected results due to
>> leaving race conditions in this API. I should also note that it has come up
>> in past discussions that we could always introduce new no-copy APIs that
>> don't contain races, if the cost of memcpy is so severe.
>>
>>
>> On Tue, Jul 16, 2013 at 6:27 PM, Jer Noble <jer.noble@apple.com> wrote:
>>
>>>
>>> On Jul 16, 2013, at 1:18 PM, K. Gadd <kg@luminance.org> wrote:
>>>
>>> This claim has been made dozens of times now on the list and I've seen
>>> multiple requests for even a single test case that demonstrates the
>>> performance impact. Is there one? I haven't seen one, nor a comment to the
>>> effect that one exists, or an explanation of why there isn't one.
>>>
>>>
>>> Isn't this self-evident?  Any solution which involves additional memcopy
>>> calls during the normal use of the API will have an inherant and known
>>> performance cost at the point of the memcopy.  Additionally, there is the
>>> ongoing performance cost of having duplicate, in-memory copies of audio
>>> data, as well as the additional GC cost of those extra copies.
>>>
>>> That said, it would be very easy to demonstrate: in the hypothetical
>>> test case, create a new ArrayBuffer from source data before passing it into
>>> the API.  I.e.,
>>>
>>> sourceNode.buffer = buffer
>>>
>>>
>>> becomes:
>>>
>>> sourceNode.buffer = buffer.slice(0)
>>>
>>>
>>> -Jer
>>>
>>
>>
>>
>