On Sunday, 8 January 2017 at 09:18:19 UTC, Suliman wrote:
Simply picking a worker thread + worker fiber when task is
assigned and sticking to it until finished should work good
enough. It is also important to note though that "fiber" is
not the same as "task". Former is execution context
On Sun, 2017-01-08 at 09:18 +, Suliman via Digitalmars-d wrote:
> > Simply picking a worker thread + worker fiber when task is
> > assigned and sticking to it until finished should work good
> > enough. It is also important to note though that "fiber" is not
> > the same as "task". Former
On Sunday, 8 January 2017 at 09:18:19 UTC, Suliman wrote:
Simply picking a worker thread + worker fiber when task is
assigned and sticking to it until finished should work good
enough. It is also important to note though that "fiber" is
not the same as "task". Former is execution context
On Sun, 08 Jan 2017 09:18:19 +, Suliman wrote:
>> Simply picking a worker thread + worker fiber when task is assigned and
>> sticking to it until finished should work good enough. It is also
>> important to note though that "fiber" is not the same as "task". Former
>> is execution context
"The type of concurrency used when logical threads are created is
determined by the Scheduler selected at initialization time. The
default behavior is currently to create a new kernel thread per
call to spawn, but other schedulers are available that multiplex
fibers across the main thread or
Simply picking a worker thread + worker fiber when task is
assigned and sticking to it until finished should work good
enough. It is also important to note though that "fiber" is not
the same as "task". Former is execution context primitive,
latter is scheduling abstraction. In fact, heavy
On 04/16/2016 03:45 PM, maik klein wrote:
> Here is an interesting talk from Naughty Dog
>
> http://www.gdcvault.com/play/1022186/Parallelizing-the-Naughty-Dog-Engine
>
> They move Fibers between threads.
>
> A rough overview:
>
> You create task A that depends on task B. The task is submitted
Here is an interesting talk from Naughty Dog
http://www.gdcvault.com/play/1022186/Parallelizing-the-Naughty-Dog-Engine
They move Fibers between threads.
A rough overview:
You create task A that depends on task B. The task is submitted
as a fiber and executed by a thread. Now task A has to
On Friday, 5 June 2015 at 18:25:26 UTC, Chris wrote:
On Friday, 5 June 2015 at 17:28:39 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 5 June 2015 at 14:51:05 UTC, Chris wrote:
I agree, but I dare doubt that a slight performance edge will
make the difference. There are load of factors (knowledge
On Saturday, 6 June 2015 at 18:49:30 UTC, Shachar Shemesh wrote:
Since we are talking about several tens of thousands of
threads, each random fluctuation in the load resulted in the
Using an unlikely workload that the kernel has not been designed
and optimized for is in general a bad idea.
On 05/06/15 16:44, Dmitry Olshansky wrote:
* You seem to assume the same. Fine assumption given that OS usually
tries to keep the same cores working on the same threads, for the
similar reasons I believe.
I see that people already raised the point that the OS does allow you to
pin a thread
On Friday, 5 June 2015 at 19:21:32 UTC, Steven Schveighoffer
wrote:
I didn't, actually. Your arguments seem well crafted and
persuasive, but I've seen so many arguments based on theory
that don't always pan out. I like to see hard data. That's what
Liran's experience provides. Perhaps you have
For the record : I am fully with Liran on this case.
On Friday, 5 June 2015 at 06:03:13 UTC, Dicebot wrote:
For the record : I am fully with Liran on this case.
+1 also for me.
At work we are using fibers when appropriate, and I see no
advantages in moving them.
/P
On 05-Jun-2015 14:29, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
On Thursday, 4 June 2015 at 22:28:52 UTC, Jonathan M Davis wrote:
anyone give a reason why we need to. deadalnix talked about load
balancing that way, but you gave good reasons as to why that
On 6/5/15 7:29 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
On Thursday, 4 June 2015 at 22:28:52 UTC, Jonathan M Davis wrote:
anyone give a reason why we need to. deadalnix talked about load
balancing that way, but you gave good reasons as to why that
On Friday, 5 June 2015 at 13:44:16 UTC, Dmitry Olshansky wrote:
If there is affinity and we assume that OS schedules threads on
the same cores* then each core has it's cache loaded with
(some of) stacks of its fibers. If we assume sharing fibers
across all cores, then each core will have to
On Friday, 5 June 2015 at 13:20:27 UTC, Steven Schveighoffer
wrote:
I think I'll go with Liran's experience over your hypothetical
anecdotes. You seem to have a lot of academic knowledge, but
I'd rather see what actually happens. If you have that data,
please share.
There is absolutely no
On Friday, 5 June 2015 at 14:51:05 UTC, Chris wrote:
I agree, but I dare doubt that a slight performance edge will
make the difference. There are load of factors (knowledge base,
infrastructure, complacency, C++-Guruism, marketing etc.) why D
is an underdog.
But everybody loves the underdog
On Friday, 5 June 2015 at 15:18:59 UTC, Dan Olson wrote:
On TLS and migrating Fibers - these were posted elsewhere, and
want to
make sure that when you read TLS Fiber problem here, it is
understood to
be something that could be solved by compiler solution.
What I meant is that I don't have a
On Friday, 5 June 2015 at 15:06:04 UTC, Dmitry Olshansky wrote:
You choose to ignore the point about duplicating the same
memory in each core's cache. To me it seems like throwing
Not sure what you mean by this. 3rd level cache is shared.
Die-level cache is shared. Primary caches are small
On Friday, 5 June 2015 at 17:28:39 UTC, Ola Fosheim Grøstad wrote:
On Friday, 5 June 2015 at 14:51:05 UTC, Chris wrote:
I agree, but I dare doubt that a slight performance edge will
make the difference. There are load of factors (knowledge
base, infrastructure, complacency, C++-Guruism,
On Thursday, 4 June 2015 at 22:28:52 UTC, Jonathan M Davis wrote:
anyone give a reason why we need to. deadalnix talked about
load balancing that way, but you gave good reasons as to why
that didn't make sense,
What good reasons?
By the time you get response from your shared memcache or
On 05-Jun-2015 17:04, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
On Friday, 5 June 2015 at 13:44:16 UTC, Dmitry Olshansky wrote:
If there is affinity and we assume that OS schedules threads on the
same cores* then each core has it's cache loaded with (some
Ola Fosheim Grøstad\ ola.fosheim.grostad+dl...@gmail.com writes:
No, there were no performance related reasons, only TLS (which is a
questionable feature to begin with).
On TLS and migrating Fibers - these were posted elsewhere, and want to
make sure that when you read TLS Fiber problem here,
On 6/5/15 10:17 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
ola.fosheim.grostad+dl...@gmail.com wrote:
On Friday, 5 June 2015 at 13:20:27 UTC, Steven Schveighoffer wrote:
I think I'll go with Liran's experience over your hypothetical
anecdotes. You seem to have a lot of academic knowledge, but I'd
On Friday, 5 June 2015 at 14:17:35 UTC, Ola Fosheim Grøstad wrote:
On Friday, 5 June 2015 at 13:20:27 UTC, Steven Schveighoffer
wrote:
I think I'll go with Liran's experience over your hypothetical
anecdotes. You seem to have a lot of academic knowledge, but
I'd rather see what actually
On Thursday, 4 June 2015 at 13:16:48 UTC, Steven Schveighoffer
wrote:
On 6/3/15 9:51 PM, Joakim wrote:
Your entire argument seems based on fibers moving between
threads
breaking your reactor IO model. If there was an option to
disable fibers moving or if you had to explicitly ask for a
On Wednesday, 3 June 2015 at 18:34:34 UTC, Liran Zvibel wrote:
As we see, there is nothing to gain and lots to lose by moving
fibers between threads.
Given that it sounds like LLVM _can't_ implement moving fibers
(or if it can, it'll really hurt performance), I think that we
need a really
Dmitry Olshansky dmitry.o...@gmail.com writes:
On 03-Jun-2015 21:34, Liran Zvibel wrote:
Hi,
[snip]
There are two main reasons why it does not make sense to move fibers
between threads:
For me language being TLS by default is enough to not even try this
madness. If we allow moves a
On Thursday, 4 June 2015 at 13:42:41 UTC, Liran Zvibel wrote:
If you assume that new jobs always come in (and then you
schedule new jobs to the more-empty fibers), there is no need
to balance old jobs (That will finish very soon anyway).
That assumes that the tasks don't do much work but just
On Thursday, 4 June 2015 at 01:51:25 UTC, Joakim wrote:
Your entire argument seems based on fibers moving between
threads
breaking your reactor IO model. If there was an option to
disable fibers moving or if you had to explicitly ask for a
fiber
to move, your argument is moot.
I have no dog
On Thursday, 4 June 2015 at 07:24:48 UTC, Liran Zvibel wrote:
Since I think you won't come up with a very good case to moving
them between threads on that other popular programming model,
INCOMING WORKLOAD (__ denotes yield+delay):
aaaa
bbb
c
On Thu, Jun 04, 2015 at 07:24:47AM +, Liran Zvibel wrote:
If you can come up with another programming model that leverages
fibers (and is popular), and moving fibers between threads makes
sense in that model, then I think the discussion should be how
stronger that other model is with
I mostly agree with what you wrote, but I'd like to point out
that it's probably safe to move some kinds of fibers across
threads:
If the fiber's main function is pure and its parameters have no
mutable indirection (i.e. if the function is strongly pure),
there should be no way to get data
On 03-Jun-2015 21:34, Liran Zvibel wrote:
Hi,
[snip]
There are two main reasons why it does not make sense to move fibers
between threads:
For me language being TLS by default is enough to not even try this
madness. If we allow moves a typical fiber will see different globals
depending
On 6/3/15 9:51 PM, Joakim wrote:
Your entire argument seems based on fibers moving between threads
breaking your reactor IO model. If there was an option to
disable fibers moving or if you had to explicitly ask for a fiber
to move, your argument is moot.
I have no dog in this fight, just
On Thursday, 4 June 2015 at 08:43:31 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 4 June 2015 at 07:24:48 UTC, Liran Zvibel wrote:
Since I think you won't come up with a very good case to
moving them between threads on that other popular programming
model,
INCOMING WORKLOAD (__ denotes
Hi,
We discussed (not) moving fibers between threads on DConf last
week, and later it was discussed in the announce group, I think
this matter is important enough to get a thread of it's own.
Software fibers/coroutines were created to make asynchronous
programming using a Reactor (or
On Wednesday, 3 June 2015 at 18:34:34 UTC, Liran Zvibel wrote:
There are two main reasons why it does not make sense to move
fibers between threads:
1. You'll start having concurrency issues. Lets assume we have
a main fiber that received some request, and it spawns 3 fibers
looking into
40 matches
Mail list logo
