On Tue, Nov 27, 2012 at 1:45 PM, john skaller <skal...@users.sourceforge.net
> 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 .. don't forget mobile and embedded devices.
>
Will they ever need thousands of threads?
> > and it's not a big problem to support tens of thousands of OS threads on
> a single machine. A very simple test on my machine shows I can start up
> 160,000 threads without difficulty in a few seconds.
>
> What machine? You certainly cannot do that on Linux. Last I looked the
> default thread limit was 500 or something.
>
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.
>
> > The actual work being done by those threads would probably dominate
> their resource usage in most cases.
>
> Maybe not. Consider a game where EVERYTHING is a thread.
> All the actors, sprites, everything. All the time, not just when visible.
> [Simulation].
>
Sure, but that's a hypothetical. It may not be truly useful or practical
to build a video game in that manner. Until you have an actual project
being built wherein you can validate the idea that running a fiber for each
entity is really useful, it's all conjecture. In my experience, the "main
loop" of a given entity is fairly easy to write as a function that gets
called every frame. A.I. is being done using behavior trees which use a
strange sort of control flow that isn't particularly fiber like. The fiber
approach makes some things opaque that you might want to be transparent -
perhaps you want to persist the state of all entities to a "Save Game" but
if they are local variables or some other low-level construct the fiber
system hinders rather than helps.
I'm not necessarily saying fibers are clearly not useful, but I think their
usefulness is not clear enough to justify all the effort.
> >
> > For those few cases that this approach can't handle (scientific
> computing simulations or some video games or whatever) you really need a
> real-world test case to figure out if your proposed system is actually
> going to solve the problem.
>
> True. But remember the original design goal of Felix was a telco
> environment.
> Felix ran at 500K trx/sec. Where trx is creating a thread or sending one a
> message with
> zero content. (Sending C++ strings slows it down a lot due to copying).
>
Is that today's design goal, though?
------------------------------------------------------------------------------
Keep yourself connected to Go Parallel:
DESIGN Expert tips on starting your parallel project right.
http://goparallel.sourceforge.net
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
