On Friday, 20 April 2012 at 04:37:32 UTC, Sean Cavanaugh wrote:
On 4/19/2012 10:00 PM, Jameson Ernst wrote:
On Thursday, 19 April 2012 at 00:07:45 UTC, Sean Kelly wrote:
On Apr 18, 2012, at 4:06 PM, Andrew Lauritzen wrote:
I'm still interested in if anyone has any suggested
workarounds or
experience using Win32 fibers in D2 as well.
The x32 Windows code should be pretty well tested. If this is
using
the x64 code though, that's all quite new. I'll give this a
try when I
find some time, but can't suggest a workaround offhand. It
almost
sounds alignment-related, which could be tricky.
Been following D for a while now, and fibers right in the std
lib are a
huge draw for me. I'm not an expert on them, but on the topic
of x64
fibers, I have some exposure to them trying to contribute x64
windows
support to bsnes, which uses its own home-grown
fiber/coroutine system.
Out of curiosity I took a look at the D fiber context code,
and noticed
that the x64 windows version doesn't seem to save the XMM6-15
registers
(unless I missed it), which is something I forgot to do also.
MSDN
indicates that they are nonvolatile, which could potentially
cause
problems for FP heavy code on x64 windows.
Not sure if I should file a bug for this, as I haven't tried
an x64
windows fiber in D yet to make sure it's actually a problem
first.
Fibers seem like a last resort to me. They are fairly
difficult to make bulletproof due to the thread local storage
issues and a few other problems with context switches. Win7
scheduling and management of real threads is a lot better than
in previous versions, and in x64 mode there is also user mode
scheduling (UMS) system and the library built on top of it
(ConcRT), which gets you almost all of the benefits of fibers
but you get to use 'real' threads, plus the added bonus of
being able to switch to another thread when you stall on a page
fault or block on a kernel object (something fiber's can't do).
To be precise, fibers in and of themselves aren't exacty what I
want, but are the best means to getting it that I've seen so far.
They enable efficient implementation of coroutines, which many
languages either cannot express at all, or can only express very
poorly by using the sledgehammer of a full-on kernel thread to
get it. A call stack is a very useful way to group logic, and
being forced to go outside the language and ask the OS for
another one is a shame.
Game logic is an area where this technique REALLY shines. Case in
point: Unity3D. The entire engine is built around C#'s iterator
method facility to implement coroutines to control entity logic.
Hundreds or even thousands of them can be active with very little
overhead compared to a full thread context switch. Unfortunately,
they're hamstrung by not being a true coroutine (you can only
yield from the top frame).
This capability makes C# very compelling for game development,
and we use it extensively at work on both the client and server
side. D could really eat its lunch by making fibers first-class
and portable.
