Re: Real-time buffer playback in Swift?
Re: Real-time buffer playback in Swift?
- Subject: Re: Real-time buffer playback in Swift?
- From: Zack Morris <email@hidden>
- Date: Wed, 17 Sep 2014 13:01:03 -0600
On Sep 17, 2014, at 11:47 AM, email@hidden wrote:
>
> Le 17 sept. 2014 à 19:09, Zack Morris <email@hidden> a écrit :
>
>> On Sep 17, 2014, at 10:20 AM, Paul Davis <email@hidden> wrote:
>>
>>>
>>> Continuing on ....
>>>
>>> On Wed, Sep 17, 2014 at 11:46 AM, Zack Morris <email@hidden> wrote:
>>>
>>> So the main problem seems to be stop-the-world garbage collection.
>>>
>>> and implicit memory allocation/free.
>>
>> Ya good points, I definitely don't disagree that processing time and unpredictable overheads matter. I'm just saying, at which point will computers be fast enough that we can work with more forgiving languages?
>
> Probably never. It is not a matter of processor speed, it is a matter of algorithm. You can have the fastest photonic processor of the world, if you algorithm require lock and contention, you can't guarantee it will be safe to use for RT processing.
>
> So, as long as your forgiving language has a runtime that do not guarantee it is RT safe, you can't use it.
>
>
> -- Jean-Daniel
Ok I think I get it now, this corresponds with what Paul was saying:
On Sep 17, 2014, at 10:06 AM, Paul Davis <email@hidden> wrote:
> Is it possible to write a "modern" language that has an RT safe runtime component? Probably. Has it been done? Probably. Does anyone know its name? Probably not.
So what we would need is a language like Swift that is lockless. On that note, lockless kernels have been written:
https://en.wikipedia.org/wiki/RTLinux
This explains a lot of the frustration I’ve had over the years trying to visualize the “next big thing” in high level languages. If they go the route of mutexes instead of atomic operations, they are unlikely to be realtime. And honestly I think mutex-based approaches inevitably reach a critical mass where it becomes difficult or impossible to add more code. They are subtly connected to other stuff that makes it difficult to parallelize code, that functional languages like Erlang and Haskell (and imperative languages like Go) avoid by preventing side effects.
So... how about someone port RTLinux to a VM that is inside the realtime component of CoreAudio. Then do whatever is necessary to Swift to make it a realtime high level language. I don’t think this is as farfetched as it sounds after seeing things like Docker. And even if it’s not particularly efficient at first, computers keep getting faster.
I wish so badly that an environment like this existed, because it would open up so many possibilities for multicore processing. Then I would get rid of GPUs and go back to full control. I don’t really think that DSP and shader-styles of programming are all that interesting compared to functional programming, once you need to go beyond the scope of what they were designed for. CUDA and OpenCL irk me, for example. I’m starting to see all of these as aspects of the same problem(s), but I digress.
Zack Morris
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden