digitalmars.D.learn - Fibers and async io stuff for beginners
- ref2401 (4/4) Apr 23 2015 I'm intrested in fibers and async io.
- =?UTF-8?B?QWxpIMOHZWhyZWxp?= (8/11) Apr 23 2015 I am working on adding a Fibers chapter to my book. Although it is still...
- ref2401 (1/1) Apr 23 2015 Awesome!
- Jens Bauer (21/25) Apr 23 2015 This is great information. I didn't know anything about Fibers
- Chris (7/33) Apr 23 2015 At the moment I'm using threads to implement a speech
- Jens Bauer (20/29) Apr 23 2015 I'll try and give you some (perhaps useless) input... :)
- Chris (3/33) Apr 24 2015 I was more thinking of the audio thread. But the audio is
- Jens Bauer (7/9) Apr 24 2015 I think you could do this too.
- Chris (2/12) Apr 24 2015 I might give it a shot.
I'm intrested in fibers and async io. Could anyone suggest articles, books or tutorials about the subject? Thank you
Apr 23 2015
On 04/23/2015 06:56 AM, ref2401 wrote:I'm intrested in fibers and async io. Could anyone suggest articles, books or tutorials about the subject? Thank youI am working on adding a Fibers chapter to my book. Although it is still a draft and not linked from any other page, I've made it online: http://ddili.org/ders/d.en/fibers.html I appreciate any feedback before the book is finally printed sometime before DConf. Thank you, Ali
Apr 23 2015
"ref2401" <refactor24 gmail.com> 
On Thursday, 23 April 2015 at 14:22:01 UTC, Ali Çehreli wrote:On 04/23/2015 06:56 AM, ref2401 wrote: http://ddili.org/ders/d.en/fibers.html I appreciate any feedback before the book is finally printed sometime before DConf.This is great information. I didn't know anything about Fibers before today. Since I started looking at D, I've seen many new and innovative ways of programming. Fibers are definitely also beneficial for microcontrollers. I can think of a few things that would make good use of Fibers: 1: Real-time Video decompression. 2: File decompression in general. 3: Audio mixing and playback (eg. a MOD player for instance). 4: Collecting data from external devices and sensors. 5: Queueing up a bunch of different jobs; for instance copying files (everyone probably knows by now not to start copying files if already copying files). ... Thinking a bit further, I've sometimes wanted to make multiple cores work on fetching jobs from the same queue. Would Fibers be good for spreading out jobs this way? Actually, it would be neat to have a class, which could manage job-dependencies, so that all CPUs could be made busy without having to make things look complicated. Someone probably made this already, though. ;)
Apr 23 2015
On Thursday, 23 April 2015 at 16:57:30 UTC, Jens Bauer wrote:On Thursday, 23 April 2015 at 14:22:01 UTC, Ali Çehreli wrote:At the moment I'm using threads to implement a speech synthesizer. It waits for input, synthesizes it, and then "speaks" in a separate thread. If new input comes, the speaking thread is stopped. I wonder, if fibers would be a viable alternative to threads (after all audio playback was mentioned in the list above).On 04/23/2015 06:56 AM, ref2401 wrote: http://ddili.org/ders/d.en/fibers.html I appreciate any feedback before the book is finally printed sometime before DConf.This is great information. I didn't know anything about Fibers before today. Since I started looking at D, I've seen many new and innovative ways of programming. Fibers are definitely also beneficial for microcontrollers. I can think of a few things that would make good use of Fibers: 1: Real-time Video decompression. 2: File decompression in general. 3: Audio mixing and playback (eg. a MOD player for instance). 4: Collecting data from external devices and sensors. 5: Queueing up a bunch of different jobs; for instance copying files (everyone probably knows by now not to start copying files if already copying files). ... Thinking a bit further, I've sometimes wanted to make multiple cores work on fetching jobs from the same queue. Would Fibers be good for spreading out jobs this way? Actually, it would be neat to have a class, which could manage job-dependencies, so that all CPUs could be made busy without having to make things look complicated. Someone probably made this already, though. ;)
Apr 23 2015
On Thursday, 23 April 2015 at 19:24:31 UTC, Chris wrote:On Thursday, 23 April 2015 at 16:57:30 UTC, Jens Bauer wrote:I'll try and give you some (perhaps useless) input... :) I think there are a number of good possibilities for spreading out the jobs. First thought is to split every job on spaces; eg. every word is a separate job, some words may be possible to "recycle" either fully or partly, depending on how they're pronounced in the particular context. I cannot give any conclusions, but I do see that ... Using multiple CPU cores with each their own Fiber would probably be the most optimal solution. Each Fiber could perhaps synthesize a word at a time. -But I do not know if you're able to control which core your Fiber is running on. That would of course only generate the data (faster than real-time on most systems). An audio frame-buffer interrupt could 'pull' the data, when necessary. Such an interrupt could also mix multiple voices (having different/variable volume and panning) if needed (here I'm thinking of 'speaking' the conversations in a chat-room).3: Audio mixing and playback (eg. a MOD player for instance). 5: Queueing up a bunch of different jobs;At the moment I'm using threads to implement a speech synthesizer. It waits for input, synthesizes it, and then "speaks" in a separate thread. If new input comes, the speaking thread is stopped. I wonder, if fibers would be a viable alternative to threads (after all audio playback was mentioned in the list above).
Apr 23 2015
On Thursday, 23 April 2015 at 22:26:28 UTC, Jens Bauer wrote:On Thursday, 23 April 2015 at 19:24:31 UTC, Chris wrote:I was more thinking of the audio thread. But the audio is probably better off in a separate thread.On Thursday, 23 April 2015 at 16:57:30 UTC, Jens Bauer wrote:I'll try and give you some (perhaps useless) input... :) I think there are a number of good possibilities for spreading out the jobs. First thought is to split every job on spaces; eg. every word is a separate job, some words may be possible to "recycle" either fully or partly, depending on how they're pronounced in the particular context. I cannot give any conclusions, but I do see that ... Using multiple CPU cores with each their own Fiber would probably be the most optimal solution. Each Fiber could perhaps synthesize a word at a time. -But I do not know if you're able to control which core your Fiber is running on. That would of course only generate the data (faster than real-time on most systems). An audio frame-buffer interrupt could 'pull' the data, when necessary. Such an interrupt could also mix multiple voices (having different/variable volume and panning) if needed (here I'm thinking of 'speaking' the conversations in a chat-room).3: Audio mixing and playback (eg. a MOD player for instance). 5: Queueing up a bunch of different jobs;At the moment I'm using threads to implement a speech synthesizer. It waits for input, synthesizes it, and then "speaks" in a separate thread. If new input comes, the speaking thread is stopped. I wonder, if fibers would be a viable alternative to threads (after all audio playback was mentioned in the list above).
Apr 24 2015
On Friday, 24 April 2015 at 09:15:21 UTC, Chris wrote:I was more thinking of the audio thread. But the audio is probably better off in a separate thread.I think you could do this too. In fact, this is very similar to how the audio from a MOD file is decoded. (I only mentioned an interrupt, because I'm used to putting audio in interrupts, since I work very close to the hardware; meaning that interrupts will normally be much more efficient)
Apr 24 2015
On Friday, 24 April 2015 at 12:38:39 UTC, Jens Bauer wrote:On Friday, 24 April 2015 at 09:15:21 UTC, Chris wrote:I might give it a shot.I was more thinking of the audio thread. But the audio is probably better off in a separate thread.I think you could do this too. In fact, this is very similar to how the audio from a MOD file is decoded. (I only mentioned an interrupt, because I'm used to putting audio in interrupts, since I work very close to the hardware; meaning that interrupts will normally be much more efficient)
Apr 24 2015