On Tue, Nov 27, 2012 at 3:38 PM, Dobes Vandermeer wrote:
>> > Sure, but that's a hypothetical.
>> Yes, its a design. Clearly hypothetical because game developers
>> didn't have Felix before :)
> Felix isn't the first system to support lightweight threads, though.
please do note all the video game
On Tue, Nov 27, 2012 at 2:23 PM, john skaller wrote:
>
> On 28/11/2012, at 9:09 AM, Dobes Vandermeer wrote:
> >
> > On my Windows 7 machine I ran that test as I composed my reply and
> started 160,000 threads. I would assume a modern version of linux is
> capable of the same.
>
> OSX, macbook pr
On 28/11/2012, at 9:09 AM, Dobes Vandermeer wrote:
>
> On my Windows 7 machine I ran that test as I composed my reply and started
> 160,000 threads. I would assume a modern version of linux is capable of the
> same.
I doubt it.
OSX, macbook pro:
~/felix>ulimit -a
core file size (blo
On Tue, Nov 27, 2012 at 2:10 PM, Raoul Duke wrote:
> > Is that today's design goal, though?
>
> sounds like a very good question. :-)
>
Heh, thanks ... I try!
--
Keep yourself connected to Go Parallel:
DESIGN Expert tip
> Is that today's design goal, though?
sounds like a very good question. :-)
--
Keep yourself connected to Go Parallel:
DESIGN Expert tips on starting your parallel project right.
http://goparallel.sourceforge.net
__
On Tue, Nov 27, 2012 at 1:45 PM, john skaller wrote:
>
> On 28/11/2012, at 7:52 AM, Dobes Vandermeer wrote:> Unless you are very
> concerned about supporting 32-bit architectures, it may be wise to forget
> about fibers for the time being. 64-bit is the way of the future,
>
> Do not be so sure .
On 28/11/2012, at 7:55 AM, Raoul Duke wrote:
> and (clueless question here) is not part of the problem also that if
> you ever want C/++ to be calling into Felix-generated stuff, and it
> doesn't follow standard C/++ calling, then things could be busted?
Yes precisely. Felix is designed to reta
On Tue, Nov 27, 2012 at 1:45 PM, john skaller
> Maybe not. Consider a game where EVERYTHING is a thread.
> All the actors, sprites, everything. All the time, not just when visible.
> [Simulation].
>
> Most of those objects need almost no state and use no resources.
> True. But remember the original
On 28/11/2012, at 7:52 AM, Dobes Vandermeer wrote:
> Trampoling means that control flow is implemented by returning a continuation
> closure in order to transfer control. This approach of returning a closure
> can be used instead of "goto" and you'll have many small functions instead of
> one
and (clueless question here) is not part of the problem also that if
you ever want C/++ to be calling into Felix-generated stuff, and it
doesn't follow standard C/++ calling, then things could be busted?
--
Keep yourself c
Well the problem as I understand it is that you want to transfer control
without pushing anything onto the stack.
Currently you generate one big function and use goto to move between
states. However, these big functions aren't handled well by C++ compilers
that expect functions to be small and us
On 27/11/2012, at 2:17 PM, Dobes Vandermeer wrote:
> One interesting approach to stack handling they suggested in the "Cheney on
> the MTA" paper was using "alloca" with a negative parameter to *deallocate*
> stack space. In their case it was relatively safe because they know that all
> the s
One interesting approach to stack handling they suggested in the "Cheney on
the MTA" paper was using "alloca" with a negative parameter to *deallocate*
stack space. In their case it was relatively safe because they know that
all the stack frames are dead, but in your case you might be able to make
On 26/11/2012, at 4:19 PM, Dobes Vandermeer wrote:
> Interesting restriction. I was curious so I googled the problem and found
> that you can kind of handle it using tail calls (i.e. a tail call is a kind
> of goto as long as you pass everything along).
Yes, but the standard C calling convent
Interesting restriction. I was curious so I googled the problem and found
that you can kind of handle it using tail calls (i.e. a tail call is a kind
of goto as long as you pass everything along).
LLVM also makes interoperating with C++ compiled object files tricky. If
you comply with the clang
On 28/08/2009, at 9:04 AM, Erick Tryzelaar wrote:
>
> I've just committed a [LLVM](http://llvm.org) code generator for
> `flxc`.
That's pretty nice!
--
john skaller
skal...@users.sourceforge.net
--
Let Crystal R
16 matches
Mail list logo
