gdalgorithms-list

Re: [Algorithms] General purpose task parallel threading approach

[Sebastian S. <seb...@gm...>]

On Sun, Apr 12, 2009 at 9:39 AM, Jarkko Lempiainen <al...@gm...>wrote:

>  Well, I see the good task prioritization as a dominating factor in task
> scheduling, e.g. if you save even 1ms shared across /all/ the threads due to
> better scheduling, you have already gained the overhead of executing ~5000
> tasks in a frame. But you seem to disagree that task prioritization gains
> you anything, am I right?
>
Sort of, Jon Watte demonstrated an example where vanilla work stealing could
lead to sub-optimal scheduling, so I agree in principle that it could
happen. But as I said later you'd have to be in a very specific circumstance
for that to actually lead to an issue in reality - you'd need to have all
your threads saturated when you start scheduling, and then you need to have
a bunch of thread idle right after the "high priority task" is scheduled
last. This seems unlikely, and benchmarks seem to show empirically that it's
uncommon enough to not be an issue.

So I agree that it could lead to an issue in principle, but I'm not sure it
actually happens in reality to the extent where it's worth spending cycles
up front to combat it. Benchmarks would convince me though!


> And then there are of course issues with the cache coherency and programmer
> productivity, so individual task overhead seems to pale in comparison when
> speaking of such a small differences (in cycles) and not something really
> worth optimizing further.
>
Yes, I would guess that scheduling based on cache coherency is probably
worthwhile, and I believe intel is doing this for their TBB.


-- 
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862

Re: [Algorithms] General purpose task parallel threading approach

[Jon W. <jw...@gm...>]

Adrian Bentley wrote:
>  However, I am very
> curious about making more general workloads run in 16 way SIMD.
> Sounds super fun.
>   

A preview of your future:

|vmadd231ps v0 {k1}, v5, [rbx+rcx*4] {4to16}

I remember when "LDA #10" was an advanced instruction :-)

Sincerely,

jw

|

Re: [Algorithms] General purpose task parallel threading approach

[Mat N. <mat...@bu...>]

> Which is what I've been trying to say all this time. If the scheduler can't handle dynamic code, then it's not really a general system.

That's like saying if you can't handle dynamic allocations your game isn't truly dynamic. Well, maybe not, but what Jon said does not necessarily lead to what you said. It simply means that any dynamic behavior changes what happens between frames, not within a frame. That does not necessarily restrict "dynamic" code from ever working, just the mechanisms through which it can work.

In other words, it moves the dynamic behavior to specific spots rather than allowing it anywhere. Which is a good thing in general(tm).

MSN
From: Sebastian Sylvan [mailto:seb...@gm...]
Sent: Monday, April 13, 2009 3:16 AM
To: Game Development Algorithms
Subject: Re: [Algorithms] General purpose task parallel threading approach


On Mon, Apr 13, 2009 at 4:17 AM, Jon Watte <jw...@gm...<mailto:jw...@gm...>> wrote:


Up front at the start of a frame, not up front at the start of the program.

Of course. Never thought you meant anything else.

>
> If you read more carefully I've given you two examples of how tasks
> using polymorphism can not be scheduled ahead of time either. Any kind
> of dynamic control flow needs an on-line scheduler.
Sure it can! You just have to say that polymorphism isn't allowed to
cause new tasks to get spawned synchronously.

Which is what I've been trying to say all this time. If the scheduler can't handle dynamic code, then it's not really a general system.

I've given you several examples of very mundane and common uses of dynamic control flow that wouldn't be possible for this reason, so I believe I've made my point pretty clear on why this is unlikely to be acceptable for me at least (especially since the benefits are requiring these restrictions are highly dubious, IMO).


--
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862

Re: [Algorithms] General purpose task parallel threading approach

[Sebastian S. <seb...@gm...>]

On Mon, Apr 13, 2009 at 5:30 PM, Mat Noguchi <mat...@bu...> wrote:

>  > Which is what I've been trying to say all this time. If the scheduler
> can't handle dynamic code, then it's not really a general system.
>
>
>
> That’s like saying if you can’t handle dynamic allocations your game isn’t
> truly dynamic. Well, maybe not, but what Jon said does not necessarily lead
> to what you said. It simply means that any dynamic behavior changes what
> happens between frames, not within a frame. That does not necessarily
> restrict “dynamic” code from ever working, just the mechanisms through which
> it can work.
>

This seems like a semantics argument, to be honest.
In my opinion a task system that places restrictions (fairly severe ones
IMO) on what kinds of code you can run in tasks can not reasonably be called
a "general" system. I don't find this to be an unreasonable definition.

This is more like "if you system can't handle dynamic allocations then it
can't run code that really needs to allocate dynamically, which means it's a
specialized, not general, system" which I would say is a fair, and even
obvious, description.

Being able to run a different statically known control flow from frame to
frame is not the same as being able to run dynamic control flow. I'm not
sure you realize the severity of the restrictions you must put up with if
the dependencies of a task must be known ahead of time - for example you
couldn't do this in a task:

void MyClass::MyTask()
{
   IFoo foo = GetFoo(m_dynamicData); // expensive, sequential
   foo.bar(); // virtual function call; who knows what this does?
}

If bar is a virtual function this just wouldn't work within a system where
the dependencies of MyTask have to be known up front before executing it,
because there is no way of knowing up front what code will run when you call
bar() (you have to run GetFoo to know what object you'll get back - you
don't even know its type, just that it implements IFoo), and that code may
have lots of dependencies that you simply can't know up front.
So for this code to work you'd have to guarantee that IFoo::bar() never
spawns any child tasks, which is a pretty severe restrictions for a task
parallel system (whose whole point is to facilitate running stuff in
parallel) don't you think?

This doesn't mean you can't work around it for certain specific scenarios
where dependencies are known up front, but it does mean that certain kinds
of code are impossible to write and you'll just have to make do without
them, which is not a characterization of a general system, IMO.

-- 
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862

Re: [Algorithms] General purpose task parallel threading approach

[Gregory J. <gj...@da...>]

Here's something you keep ignoring though, Sebastian - despite your fervent
belief otherwise, and the efforts of several rather enlightened individuals
thus far to educate you otherwise: there is no "Grand Unified Theory of
Computing"; no "One Size Fits All" approach that works optimally in all
cases. We don't write "general" code. In every single software system
implemented in the history of computing, it has been implemented to solve a
specific problem. 

 

This "general" case you speak of has no utility in practice.

 

Regards

Greg

 

From: Sebastian Sylvan [mailto:seb...@gm...] 
Sent: Monday, April 13, 2009 10:09 AM
To: Game Development Algorithms
Subject: Re: [Algorithms] General purpose task parallel threading approach

 

 

On Mon, Apr 13, 2009 at 5:30 PM, Mat Noguchi <mat...@bu...> wrote:

> Which is what I've been trying to say all this time. If the scheduler
can't handle dynamic code, then it's not really a general system.

 

That's like saying if you can't handle dynamic allocations your game isn't
truly dynamic. Well, maybe not, but what Jon said does not necessarily lead
to what you said. It simply means that any dynamic behavior changes what
happens between frames, not within a frame. That does not necessarily
restrict "dynamic" code from ever working, just the mechanisms through which
it can work.

 

This seems like a semantics argument, to be honest. 

In my opinion a task system that places restrictions (fairly severe ones
IMO) on what kinds of code you can run in tasks can not reasonably be called
a "general" system. I don't find this to be an unreasonable definition.

 

This is more like "if you system can't handle dynamic allocations then it
can't run code that really needs to allocate dynamically, which means it's a
specialized, not general, system" which I would say is a fair, and even
obvious, description. 

 

Being able to run a different statically known control flow from frame to
frame is not the same as being able to run dynamic control flow. I'm not
sure you realize the severity of the restrictions you must put up with if
the dependencies of a task must be known ahead of time - for example you
couldn't do this in a task:

 

void MyClass::MyTask()

{

   IFoo foo = GetFoo(m_dynamicData); // expensive, sequential

   foo.bar(); // virtual function call; who knows what this does?

}

 

If bar is a virtual function this just wouldn't work within a system where
the dependencies of MyTask have to be known up front before executing it,
because there is no way of knowing up front what code will run when you call
bar() (you have to run GetFoo to know what object you'll get back - you
don't even know its type, just that it implements IFoo), and that code may
have lots of dependencies that you simply can't know up front.

So for this code to work you'd have to guarantee that IFoo::bar() never
spawns any child tasks, which is a pretty severe restrictions for a task
parallel system (whose whole point is to facilitate running stuff in
parallel) don't you think?

 

This doesn't mean you can't work around it for certain specific scenarios
where dependencies are known up front, but it does mean that certain kinds
of code are impossible to write and you'll just have to make do without
them, which is not a characterization of a general system, IMO.

 

-- 
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862

Re: [Algorithms] General purpose task parallel threading approach

[Sebastian S. <seb...@gm...>]

On Mon, Apr 13, 2009 at 6:42 PM, Gregory Junker <gj...@da...> wrote:

>  Here’s something you keep ignoring though, Sebastian – despite your
> fervent belief otherwise, and the efforts of several rather enlightened
> individuals thus far to educate you otherwise: there is no “Grand Unified
> Theory of Computing”; no “One Size Fits All” approach that works optimally
> in all cases. We don’t write “general” code. In every single software system
> implemented in the history of computing, it has been implemented to solve a
> specific problem.
>

Oh come on!

1) Be professional. There's really no need for this attitude.
2) I've never claimed anything remotely close to what you say, I'm merely
pointing out the restrictions of one specific approach (and as I've said,
I'm using this approach myself right now!).
3) Software is quite often about trying to write components that are as
general as possible. It's called code-reuse and is usually thought of as a
good thing.


-- 
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862

Re: [Algorithms] General purpose task parallel threading approach

[Gregory J. <gj...@da...>]

Sebastian

 

First, what attitude? I am merely pointing out a flaw in your arguments.

 

Second, the components you write are *not* as general as possible - that
would create a useless system, as I (and others) have already pointed out.
You write components that are coded to do something specific, and because
they are restricted to doing something specific, when you need something
that does that specific something in the future, you can reuse that
component. That is what "reuse" means. 

 

You should know this, yet you continue to harp on this "general" theme
anytime anyone tries to explain to you what should be obvious about your use
of this term. One can only assume, from your responses and your behavior in
this topic, that you are simply being argumentative at this point.


Greg

 

From: Sebastian Sylvan [mailto:seb...@gm...] 
Sent: Monday, April 13, 2009 10:54 AM
To: Game Development Algorithms
Subject: Re: [Algorithms] General purpose task parallel threading approach

 

 

On Mon, Apr 13, 2009 at 6:42 PM, Gregory Junker <gj...@da...> wrote:

Here's something you keep ignoring though, Sebastian - despite your fervent
belief otherwise, and the efforts of several rather enlightened individuals
thus far to educate you otherwise: there is no "Grand Unified Theory of
Computing"; no "One Size Fits All" approach that works optimally in all
cases. We don't write "general" code. In every single software system
implemented in the history of computing, it has been implemented to solve a
specific problem.

 

Oh come on!

 

1) Be professional. There's really no need for this attitude.

2) I've never claimed anything remotely close to what you say, I'm merely
pointing out the restrictions of one specific approach (and as I've said,
I'm using this approach myself right now!).

3) Software is quite often about trying to write components that are as
general as possible. It's called code-reuse and is usually thought of as a
good thing.

 

 

-- 
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862

Re: [Algorithms] General purpose task parallel threading approach

[Sebastian S. <seb...@gm...>]

On Mon, Apr 13, 2009 at 8:54 PM, Gregory Junker <gj...@da...> wrote:

>  Sebastian
>
>
>
> First, what attitude?
>

You can't be serious.


>
> Second, the components you write are **not** as general as possible – that
> would create a useless system, as I (and others) have already pointed out.
> You write components that are coded to do something specific, and because
> they are restricted to doing something specific, when you need something
> that does that specific something in the future, you can reuse that
> component. That is what “reuse” means.
>
>
>
> You should know this, yet you continue to harp on this “general” theme
> anytime anyone tries to explain to you what should be obvious about your use
> of this term. One can only assume, from your responses and your behavior in
> this topic, that you are simply being argumentative at this point.
>

Who's being argumentative now? You're arguing that my point about a certain
system lacking generality/flexibility is pointless because if you take
generality to the absurd extreme you wouldn't get a useful system. When have
I ever said you should do that?

People write general systems all the time, criticizing a specific technique
for being restrictive is perfectly legitimate.

Again, I'm *using* this very system right now, clearly I'm perfectly happy
to make compromises on generality. If you want to argue, please do it with
me, rather than some straw man you've conjured up out of thin air.


-- 
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862

Re: [Algorithms] General purpose task parallel threading approach

[Gregory J. <gj...@da...>]

"People write general systems all the time"

 

Oh? Describe one. 

 

You continue to allude to this mythical "general system" - give us an
example of what you consider a "general system" that people write all the
time.

 

Greg 

 

 

  _____  

From: Sebastian Sylvan [mailto:seb...@gm...] 
Sent: Tuesday, April 14, 2009 12:12 AM
To: Game Development Algorithms
Subject: Re: [Algorithms] General purpose task parallel threading approach

 

 

On Mon, Apr 13, 2009 at 8:54 PM, Gregory Junker <gj...@da...> wrote:

Sebastian

 

First, what attitude?

 

You can't be serious.

 

 

Second, the components you write are *not* as general as possible - that
would create a useless system, as I (and others) have already pointed out.
You write components that are coded to do something specific, and because
they are restricted to doing something specific, when you need something
that does that specific something in the future, you can reuse that
component. That is what "reuse" means. 

 

You should know this, yet you continue to harp on this "general" theme
anytime anyone tries to explain to you what should be obvious about your use
of this term. One can only assume, from your responses and your behavior in
this topic, that you are simply being argumentative at this point.

 

Who's being argumentative now? You're arguing that my point about a certain
system lacking generality/flexibility is pointless because if you take
generality to the absurd extreme you wouldn't get a useful system. When have
I ever said you should do that?

 

People write general systems all the time, criticizing a specific technique
for being restrictive is perfectly legitimate.


Again, I'm *using* this very system right now, clearly I'm perfectly happy
to make compromises on generality. If you want to argue, please do it with
me, rather than some straw man you've conjured up out of thin air.

 


-- 
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862

Re: [Algorithms] General purpose task parallel threading approach

[Mat N. <mat...@bu...>]

I can describe one I've worked with. But it has the distinct advantage of also allowing for inspection so that you can beat it into something more special purpose.

MSN
From: Gregory Junker [mailto:gj...@da...]
Sent: Tuesday, April 14, 2009 8:29 AM
To: 'Game Development Algorithms'
Subject: Re: [Algorithms] General purpose task parallel threading approach

"People write general systems all the time"

Oh? Describe one.

You continue to allude to this mythical "general system" - give us an example of what you consider a "general system" that people write all the time.

Greg


________________________________
From: Sebastian Sylvan [mailto:seb...@gm...]
Sent: Tuesday, April 14, 2009 12:12 AM
To: Game Development Algorithms
Subject: Re: [Algorithms] General purpose task parallel threading approach


On Mon, Apr 13, 2009 at 8:54 PM, Gregory Junker <gj...@da...<mailto:gj...@da...>> wrote:

Sebastian



First, what attitude?

You can't be serious.




Second, the components you write are *not* as general as possible - that would create a useless system, as I (and others) have already pointed out. You write components that are coded to do something specific, and because they are restricted to doing something specific, when you need something that does that specific something in the future, you can reuse that component. That is what "reuse" means.



You should know this, yet you continue to harp on this "general" theme anytime anyone tries to explain to you what should be obvious about your use of this term. One can only assume, from your responses and your behavior in this topic, that you are simply being argumentative at this point.

Who's being argumentative now? You're arguing that my point about a certain system lacking generality/flexibility is pointless because if you take generality to the absurd extreme you wouldn't get a useful system. When have I ever said you should do that?

People write general systems all the time, criticizing a specific technique for being restrictive is perfectly legitimate.

Again, I'm *using* this very system right now, clearly I'm perfectly happy to make compromises on generality. If you want to argue, please do it with me, rather than some straw man you've conjured up out of thin air.


--
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862

Re: [Algorithms] General purpose task parallel threading approach

[Sebastian S. <seb...@gm...>]

On Tue, Apr 14, 2009 at 4:28 PM, Gregory Junker <gj...@da...> wrote:

>  “People write general systems all the time”
>
>
>
> Oh? Describe one.
>
>
>
> You continue to allude to this mythical “general system” – give us an
> example of what you consider a “general system” that people write all the
> time.
>

Honestly, you're just being difficult at this point.
A polymorphic linked list can be considered general in that it can store any
kind of data in it, if you only allowed PODs (say), or just a single
specific data type, it would be fair to say it's far more specialized. It
would also be fair to count this as a drawback of the linked list
implementation (not to say that there won't be specific instances where this
drawback is paid for by other properties - but rigidity and specilization go
in the "cons" column).

This clearly isn't a binary question where if something can't be used for
any imaginable usage case then you might as well give up and ignore
flexibility altogether.
Generality and flexibility are considered desirable features in most cases -
therefore pointing out the lack of flexibility in some aspect of a system is
an entirely valid criticism.


-- 
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862

Re: [Algorithms] General purpose task parallel threading approach

[Mat N. <mat...@bu...>]

Ø  Generality and flexibility are considered desirable features in most cases - therefore pointing out the lack of flexibility in some aspect of a system is an entirely valid criticism.

I think the whole point of the other side of this discussion is that generality and flexibility are not necessarily desirable features.

MSN
From: Sebastian Sylvan [mailto:seb...@gm...]
Sent: Tuesday, April 14, 2009 11:07 AM
To: Game Development Algorithms
Subject: Re: [Algorithms] General purpose task parallel threading approach


On Tue, Apr 14, 2009 at 4:28 PM, Gregory Junker <gj...@da...<mailto:gj...@da...>> wrote:

"People write general systems all the time"



Oh? Describe one.



You continue to allude to this mythical "general system" - give us an example of what you consider a "general system" that people write all the time.

Honestly, you're just being difficult at this point.
A polymorphic linked list can be considered general in that it can store any kind of data in it, if you only allowed PODs (say), or just a single specific data type, it would be fair to say it's far more specialized. It would also be fair to count this as a drawback of the linked list implementation (not to say that there won't be specific instances where this drawback is paid for by other properties - but rigidity and specilization go in the "cons" column).

This clearly isn't a binary question where if something can't be used for any imaginable usage case then you might as well give up and ignore flexibility altogether.
Generality and flexibility are considered desirable features in most cases - therefore pointing out the lack of flexibility in some aspect of a system is an entirely valid criticism.


--
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862

Re: [Algorithms] General purpose task parallel threading approach

[Sebastian S. <seb...@gm...>]

On Tue, Apr 14, 2009 at 7:14 PM, Mat Noguchi <mat...@bu...> wrote:

>  Ø  Generality and flexibility are considered desirable features in most
> cases - therefore pointing out the lack of flexibility in some aspect of a
> system is an entirely valid criticism.
>
>
>
> I think the whole point of the other side of this discussion is that
> generality and flexibility are not necessarily desirable features.
>

In what sense is less flexibility preferable? I mean, I get that in a
certain specific scenario you may go for a solution that is less flexible if
it offers, say, more performance, but that doesn't mean that everything else
being equal you wouldn't prefer to have the flexibility too.



-- 
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862

Re: [Algorithms] General purpose task parallel threading approach

[Mat N. <mat...@bu...>]

If the genericity or flexibility comes at the price of hiding information, then it's not as desirable. A useful attribute to consider is whether you have to run code in order to make reasonable assumptions of its behavior. If you do, it is less desirable than if you don't.

MSN
From: Sebastian Sylvan [mailto:seb...@gm...]
Sent: Tuesday, April 14, 2009 11:23 AM
To: Game Development Algorithms
Subject: Re: [Algorithms] General purpose task parallel threading approach


On Tue, Apr 14, 2009 at 7:14 PM, Mat Noguchi <mat...@bu...<mailto:mat...@bu...>> wrote:

>  Generality and flexibility are considered desirable features in most cases - therefore pointing out the lack of flexibility in some aspect of a system is an entirely valid criticism.



I think the whole point of the other side of this discussion is that generality and flexibility are not necessarily desirable features.

In what sense is less flexibility preferable? I mean, I get that in a certain specific scenario you may go for a solution that is less flexible if it offers, say, more performance, but that doesn't mean that everything else being equal you wouldn't prefer to have the flexibility too.



--
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862

Re: [Algorithms] General purpose task parallel threading approach

[Mat N. <mat...@bu...>]

And the corollary to that is most generic/flexible systems are implemented such that you cannot get useful information out of them without executing them.

MSN
From: Mat Noguchi [mailto:mat...@bu...]
Sent: Tuesday, April 14, 2009 11:48 AM
To: Game Development Algorithms
Subject: Re: [Algorithms] General purpose task parallel threading approach

If the genericity or flexibility comes at the price of hiding information, then it's not as desirable. A useful attribute to consider is whether you have to run code in order to make reasonable assumptions of its behavior. If you do, it is less desirable than if you don't.

MSN
From: Sebastian Sylvan [mailto:seb...@gm...]
Sent: Tuesday, April 14, 2009 11:23 AM
To: Game Development Algorithms
Subject: Re: [Algorithms] General purpose task parallel threading approach


On Tue, Apr 14, 2009 at 7:14 PM, Mat Noguchi <mat...@bu...<mailto:mat...@bu...>> wrote:

>  Generality and flexibility are considered desirable features in most cases - therefore pointing out the lack of flexibility in some aspect of a system is an entirely valid criticism.



I think the whole point of the other side of this discussion is that generality and flexibility are not necessarily desirable features.

In what sense is less flexibility preferable? I mean, I get that in a certain specific scenario you may go for a solution that is less flexible if it offers, say, more performance, but that doesn't mean that everything else being equal you wouldn't prefer to have the flexibility too.



--
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862

Re: [Algorithms] General purpose task parallel threading approach

[Sebastian S. <seb...@gm...>]

That's not the same as saying that flexibility isn't desirable, though. What
I said was that if you evaluate a certain system you would put "flexible"
and "general" in the "pros" column, and conversely you would put "rigid" and
"specialized" in the "cons" column. There may be a whole host of other
things going into the two columns which guide you to your final conclusion,
but that doesn't mean that flexibility in itself isn't a desirable trait,
nor that restrictions/rigidity is.
In the particular example in question the restrictions are severe - there
clearly are advantages too (not the least of which is lower implementation
complexity), and as I've said I use a similar system myself for various
reasons. However, that doesn't mean that the significant restrictions of how
you can use it, and non-general nature of the system aren't very real
drawbacks that are worth considering when evaluating it.

On Tue, Apr 14, 2009 at 7:47 PM, Mat Noguchi <mat...@bu...> wrote:

>  If the genericity or flexibility comes at the price of hiding
> information, then it’s not as desirable. A useful attribute to consider is
> whether you have to run code in order to make reasonable assumptions of its
> behavior. If you do, it is less desirable than if you don’t.
>
>
>
> MSN
>
> *From:* Sebastian Sylvan [mailto:seb...@gm...]
> *Sent:* Tuesday, April 14, 2009 11:23 AM
>
> *To:* Game Development Algorithms
> *Subject:* Re: [Algorithms] General purpose task parallel threading
> approach
>
>
>
>
>
> On Tue, Apr 14, 2009 at 7:14 PM, Mat Noguchi <mat...@bu...> wrote:
>
> Ø  Generality and flexibility are considered desirable features in most
> cases - therefore pointing out the lack of flexibility in some aspect of a
> system is an entirely valid criticism.
>
>
>
> I think the whole point of the other side of this discussion is that
> generality and flexibility are not necessarily desirable features.
>
>
>
> In what sense is less flexibility preferable? I mean, I get that in a
> certain specific scenario you may go for a solution that is less flexible if
> it offers, say, more performance, but that doesn't mean that everything else
> being equal you wouldn't prefer to have the flexibility too.
>
>
>
>
>
> --
> Sebastian Sylvan
> +44(0)7857-300802
> UIN: 44640862
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>



-- 
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862

Re: [Algorithms] General purpose task parallel threading approach

[Jarkko L. <al...@gm...>]

Hold on, are you actually arguing against polymorphism and encapsulation in
general?

 

 

Cheers, Jarkko

 

  _____  

From: Mat Noguchi [mailto:mat...@bu...] 
Sent: Tuesday, April 14, 2009 9:57 PM
To: Game Development Algorithms
Subject: Re: [Algorithms] General purpose task parallel threading approach

 

And the corollary to that is most generic/flexible systems are implemented
such that you cannot get useful information out of them without executing
them.

 

MSN

From: Mat Noguchi [mailto:mat...@bu...] 
Sent: Tuesday, April 14, 2009 11:48 AM
To: Game Development Algorithms
Subject: Re: [Algorithms] General purpose task parallel threading approach

 

If the genericity or flexibility comes at the price of hiding information,
then it's not as desirable. A useful attribute to consider is whether you
have to run code in order to make reasonable assumptions of its behavior. If
you do, it is less desirable than if you don't.

 

MSN

From: Sebastian Sylvan [mailto:seb...@gm...] 
Sent: Tuesday, April 14, 2009 11:23 AM
To: Game Development Algorithms
Subject: Re: [Algorithms] General purpose task parallel threading approach

 

 

On Tue, Apr 14, 2009 at 7:14 PM, Mat Noguchi <mat...@bu...> wrote:

*  Generality and flexibility are considered desirable features in most
cases - therefore pointing out the lack of flexibility in some aspect of a
system is an entirely valid criticism.

 

I think the whole point of the other side of this discussion is that
generality and flexibility are not necessarily desirable features.

 

In what sense is less flexibility preferable? I mean, I get that in a
certain specific scenario you may go for a solution that is less flexible if
it offers, say, more performance, but that doesn't mean that everything else
being equal you wouldn't prefer to have the flexibility too.

 



-- 
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862

Re: [Algorithms] General purpose task parallel threading approach

[Mat N. <mat...@bu...>]

No, but I am arguing that hiding information from everyone isn't necessarily a good idea either.

MSN
From: Jarkko Lempiainen [mailto:al...@gm...]
Sent: Tuesday, April 14, 2009 12:18 PM
To: 'Game Development Algorithms'
Subject: Re: [Algorithms] General purpose task parallel threading approach

Hold on, are you actually arguing against polymorphism and encapsulation in general?


Cheers, Jarkko

________________________________
From: Mat Noguchi [mailto:mat...@bu...]
Sent: Tuesday, April 14, 2009 9:57 PM
To: Game Development Algorithms
Subject: Re: [Algorithms] General purpose task parallel threading approach

And the corollary to that is most generic/flexible systems are implemented such that you cannot get useful information out of them without executing them.

MSN
From: Mat Noguchi [mailto:mat...@bu...]
Sent: Tuesday, April 14, 2009 11:48 AM
To: Game Development Algorithms
Subject: Re: [Algorithms] General purpose task parallel threading approach

If the genericity or flexibility comes at the price of hiding information, then it's not as desirable. A useful attribute to consider is whether you have to run code in order to make reasonable assumptions of its behavior. If you do, it is less desirable than if you don't.

MSN
From: Sebastian Sylvan [mailto:seb...@gm...]
Sent: Tuesday, April 14, 2009 11:23 AM
To: Game Development Algorithms
Subject: Re: [Algorithms] General purpose task parallel threading approach


On Tue, Apr 14, 2009 at 7:14 PM, Mat Noguchi <mat...@bu...<mailto:mat...@bu...>> wrote:

>  Generality and flexibility are considered desirable features in most cases - therefore pointing out the lack of flexibility in some aspect of a system is an entirely valid criticism.



I think the whole point of the other side of this discussion is that generality and flexibility are not necessarily desirable features.

In what sense is less flexibility preferable? I mean, I get that in a certain specific scenario you may go for a solution that is less flexible if it offers, say, more performance, but that doesn't mean that everything else being equal you wouldn't prefer to have the flexibility too.



--
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862

Re: [Algorithms] General purpose task parallel threading approach

[Conor S. <bor...@ya...>]

There is an important distinction between "seeing" information and "changing" information as well. It may not always be a good idea to hide it, but it's often a great idea to control it (and how it's presented). 

And controlling how it is presented is a great reason for encapsulation and polymorphism.

Cheers,
Conor  



________________________________
From: Mat Noguchi <mat...@bu...>
To: Game Development Algorithms <gda...@li...>
Sent: Wednesday, 15 April, 2009 4:14:05 AM
Subject: Re: [Algorithms] General purpose task parallel threading approach


No, but I am arguing that hiding information from everyone isn’t
necessarily a good idea either.
 
MSN
From:Jarkko Lempiainen
[mailto:al...@gm...] 
Sent: Tuesday, April 14, 2009 12:18 PM
To: 'Game Development Algorithms'
Subject: Re: [Algorithms] General purpose task parallel threading
approach
 
Hold on, are you actually arguing against polymorphism and
encapsulation in general?
 
 
Cheers, Jarkko
 

________________________________
 
From:Mat Noguchi
[mailto:mat...@bu...] 
Sent: Tuesday, April 14, 2009 9:57 PM
To: Game Development Algorithms
Subject: Re: [Algorithms] General purpose task parallel threading
approach
 
And the corollary to that is most generic/flexible systems are
implemented such that you cannot get useful information out of them without
executing them.
 
MSN
From:Mat Noguchi
[mailto:mat...@bu...] 
Sent: Tuesday, April 14, 2009 11:48 AM
To: Game Development Algorithms
Subject: Re: [Algorithms] General purpose task parallel threading
approach
 
If the genericity or flexibility comes at the price of hiding
information, then it’s not as desirable. A useful attribute to consider is
whether you have to run code in order to make reasonable assumptions of its
behavior. If you do, it is less desirable than if you don’t.
 
MSN
From:Sebastian Sylvan
[mailto:seb...@gm...] 
Sent: Tuesday, April 14, 2009 11:23 AM
To: Game Development Algorithms
Subject: Re: [Algorithms] General purpose task parallel threading
approach
 
 
On Tue, Apr 14, 2009 at 7:14 PM, Mat Noguchi <mat...@bu...> wrote:
Ø  Generality and flexibility are considered
desirable features in most cases - therefore pointing out the lack of
flexibility in some aspect of a system is an entirely valid criticism.
 
I think the whole point of the
other side of this discussion is that generality and flexibility are not
necessarily desirable features.
 
In what sense is less flexibility preferable? I mean, I get
that in a certain specific scenario you may go for a solution that is less
flexible if it offers, say, more performance, but that doesn't mean that
everything else being equal you wouldn't prefer to have the flexibility too.
 


-- 
Sebastian Sylvan
+44(0)7857-300802
UIN: 44640862


      Enjoy a safer web experience. Upgrade to the new Internet Explorer 8 optimised for Yahoo!7. Get it now.

Re: [Algorithms] General purpose task parallel threading approach

[<chr...@pl...>]

Sebastian Sylvan wrote:
> 3) Software is quite often about trying to write components that are
> as general as possible. It's called code-reuse and is usually
> thought of as a good thing.

Software is RARELY about writing components that are as general
as possible. As Jon and others already pointed out, software is
usually written to solve a very specific problem.

Also, there's a difference between academic best practices and
real world needs.

Christer Ericson, Director of Tools and Technology
Sony Computer Entertainment, Santa Monica

Re: [Algorithms] General purpose task parallel threading approach

[Conor S. <bor...@ya...>]

"Software is RARELY about writing components that are as general
as possible. As Jon and others already pointed out, software is
usually written to solve a very specific problem."

And it solves that very specific problem by composition of general components. Really it comes down to how much economic sense it makes to generalize something. Games development, especially console based games development, is on the esoteric end of the spectrum, where you are really solving specific problems (those needed to make your game work). It doesn't make as much sense to generalize things as it does for a large-project company that sells a customizable software framework (along with customization services) that is umpteen million lines, spans embedded devices to big iron servers and has a maintenance lifetime (including new customizations) on the order of 20 years.

Academic best practice usually comes from cases like this, partly because that's where the money is and partly because when someone actually gets it right it's a spectacle on the order of the second coming.

Cheers,
Conor


      The new Internet Explorer 8 optimised for Yahoo!7: Faster, Safer, Easier.

Re: [Algorithms] General purpose task parallel threading approach

[Gregory J. <gj...@da...>]

> 
> "Software is RARELY about writing components that are as general
> as possible. As Jon and others already pointed out, software is
> usually written to solve a very specific problem."
> 

Again, there is no such thing as a "general component". The moment you
define a component's interface, for example, it has become specific and
restricted. 

In order for a component to be "general", it would have to handle *any*
input and produce *any* output and maintain *any* internal state. It can't
be specific about anything, and you have to admit that is neither useful nor
realistic.

Greg

Re: [Algorithms] General purpose task parallel threading approach

[Jon O. <ze...@gm...>]

I think you just described the Human brain. ;) But I dare say that humans
are useful and realistic.
- Jon Olick

On Tue, Apr 14, 2009 at 10:33 AM, Gregory Junker <gj...@da...> wrote:

>
>
> >
> > "Software is RARELY about writing components that are as general
> > as possible. As Jon and others already pointed out, software is
> > usually written to solve a very specific problem."
> >
>
> Again, there is no such thing as a "general component". The moment you
> define a component's interface, for example, it has become specific and
> restricted.
>
> In order for a component to be "general", it would have to handle *any*
> input and produce *any* output and maintain *any* internal state. It can't
> be specific about anything, and you have to admit that is neither useful
> nor
> realistic.
>
> Greg
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> High Quality Requirements in a Collaborative Environment.
> Download a free trial of Rational Requirements Composer Now!
> http://p.sf.net/sfu/www-ibm-com
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>

Re: [Algorithms] General purpose task parallel threading approach

[Gregory J. <gj...@da...>]

 

 

  _____  

From: Jon Olick [mailto:ze...@gm...] 
Sent: Tuesday, April 14, 2009 8:42 AM
To: Game Development Algorithms
Subject: Re: [Algorithms] General purpose task parallel threading approach

 

I think you just described the Human brain. ;) But I dare say that humans
are useful and realistic. 

 

-      Jon Olick

 

But then, we aren't writing the human brain - we're writing video games. ;)

Re: [Algorithms] General purpose task parallel threading approach

[<chr...@pl...>]

Conor Stokes wrote:
>> "Software is RARELY about writing components that are as general
>> as possible. As Jon and others already pointed out, software is
>> usually written to solve a very specific problem."
>
> And it solves that very specific problem by composition of general
> components.

Other than classroom examples, software is NOT written through
composition of 'general components'. And even in the small subset
of software writing where your statement may hold true, writing
those components was a very small amount of work of the total.


Christer Ericson, Director of Tools and Technology
Sony Computer Entertainment, Santa Monica