Hi Dimitris,
Thank you for your response.
Feel most free to send it to the Gambit ML too, as to encourage further conversation on this topic.
The IO performance can be boosted to really good performance by doing it via read/write-subu8vector only, but that has huge system-level limitations so even though for almost-all applications that can solve it, in the big picture it's not a solution.
Re boosting byte-level access speeds, I remember I think Marc making a ML post where he inlined read-char's or read-u8's code in the user code and got much higher performance that way. That saves of the trampoline call at least... It should be easy to repeat that experiment as to check out how it affects performance.
Condition variables... Hmm. Do you have any clue at what granularity they work?
Brgds :) Mikael
2013/3/10 Dimitris Vyzovitis vyzo@hackzen.org
+1
If I may add, point (f) should be a priority. i/o performance is severely hampered by the constant mutex acquisitions. At a first approximation, each individual write should stop writing one character at a time (with a mutex lock each time). Having full control of whether a mutex is used at all is even better, as it is almost always the case that a single thread is reading/writing a port (exceptions being the std ports). The problem there is the way the i/o system i simplemented though, as the events are tied to condition variables and these in turn tied to mutexes to work reliably.
PS: I owe you some coroutines :)