The Stack Overflow podcast is back! Listen to an interview with our new CEO.
8 added 219 characters in body
source | link

In that case the copying overhead could prevent opportunities for effective parallelism, because it might be difficult to parallelize physics and rendering effectively without locking and bottlenecking each other if physics is mutating the scene that the renderer is simultaneously trying to draw, while simultaneously having physics deep copy the entire game scene around just to output one frame with physics applied might be equally ineffective. However, if the physics system was 'pure' in the sense that it merely inputted a scene and outputted a new one with physics applied, and such purity did not come at the cost of astronomical copying overhead, it could safely operate in parallel with the renderer without one waiting on the other.

So the ability to cheaply copy the really hefty data of your application state around and output new, modified versions with minimal cost to processing and memory use can really open up new doors for purity and effective parallelism, and there I find lots of lessons to learn from how persistent data structures are implemented. But whatever we create using such lessons don'tdoesn't have to be strictlyfully persistent, or offer immutable interfaces (it might use copy-on-write, for example, or a "builder/transient"), to achieve this ability to be dirt cheap to copy around and modify just sections of the copy without doubling up memory use and memory access in our quest for parallelism and purity in our functions/systems/pipeline.

But I have found, once you get that sort of copying and ability to output partially-modified versions of hefty structures dirt cheap, as you would get with persistent data structures as an example, it does often open up lots of doors and opportunities you might not have thought about before to parallelize code that can run completely independently of each other in a strict I/O sort of parallel pipeline. Even if some parts of the algorithm have to be serial in nature, you might defer that processing to a single thread but find that leaning on these concepts has opened up doors to easily, and without worry, parallelize 90% of the hefty work, e.g.

In that case the copying overhead could prevent opportunities for effective parallelism, because it might be difficult to parallelize physics and rendering effectively without locking and bottlenecking each other if physics is mutating the scene that the renderer is simultaneously trying to draw, while simultaneously having physics copy the entire game scene around just to output one frame with physics applied might be equally ineffective. However, if the physics system was 'pure' in the sense that it merely inputted a scene and outputted a new one with physics applied, and such purity did not come at the cost of astronomical copying overhead, it could safely operate in parallel with the renderer without one waiting on the other.

So the ability to cheaply copy the really hefty data of your application state around and output new, modified versions with minimal cost to processing and memory use can really open up new doors for purity and effective parallelism, and there I find lots of lessons to learn from how persistent data structures are implemented. But whatever we create using such lessons don't have to be strictly persistent, or offer immutable interfaces (it might use copy-on-write, for example, or a "builder/transient"), to achieve this ability to be dirt cheap to copy around and modify just sections of the copy without doubling up memory use and memory access in our quest for parallelism and purity in our functions/systems/pipeline.

But I have found, once you get that sort of copying and ability to output partially-modified versions of hefty structures dirt cheap, as you would get with persistent data structures as an example, it does often open up lots of doors and opportunities you might not have thought about before to parallelize code that can run completely independently of each other in a strict I/O sort of parallel pipeline.

In that case the copying overhead could prevent opportunities for effective parallelism, because it might be difficult to parallelize physics and rendering effectively without locking and bottlenecking each other if physics is mutating the scene that the renderer is simultaneously trying to draw, while simultaneously having physics deep copy the entire game scene around just to output one frame with physics applied might be equally ineffective. However, if the physics system was 'pure' in the sense that it merely inputted a scene and outputted a new one with physics applied, and such purity did not come at the cost of astronomical copying overhead, it could safely operate in parallel with the renderer without one waiting on the other.

So the ability to cheaply copy the really hefty data of your application state around and output new, modified versions with minimal cost to processing and memory use can really open up new doors for purity and effective parallelism, and there I find lots of lessons to learn from how persistent data structures are implemented. But whatever we create using such lessons doesn't have to be fully persistent, or offer immutable interfaces (it might use copy-on-write, for example, or a "builder/transient"), to achieve this ability to be dirt cheap to copy around and modify just sections of the copy without doubling up memory use and memory access in our quest for parallelism and purity in our functions/systems/pipeline.

But I have found, once you get that sort of copying and ability to output partially-modified versions of hefty structures dirt cheap, as you would get with persistent data structures as an example, it does often open up lots of doors and opportunities you might not have thought about before to parallelize code that can run completely independently of each other in a strict I/O sort of parallel pipeline. Even if some parts of the algorithm have to be serial in nature, you might defer that processing to a single thread but find that leaning on these concepts has opened up doors to easily, and without worry, parallelize 90% of the hefty work, e.g.

7 added 132 characters in body
source | link

But I find this the least interesting property because most objects I see as beneficial as being used temporarily, in mutable form, to implement a pure function (or even a broader concept, like a "pure system" which might be an object or series of functions with the ultimate effect of merely inputting something and outputting something new without touching anything else), and I think immutability taken to the extremities in a largely imperative language is a rather counter-productive goal. I'd apply it sparingly for the parts of the codebase where it really helps the most.

But I find this the least interesting property because most objects I see as beneficial as being used temporarily, in mutable form, to implement a pure function (or even a broader concept, like a "pure system"), and I think immutability taken to the extremities in a largely imperative language is a rather counter-productive goal. I'd apply it sparingly for the parts of the codebase where it really helps the most.

But I find this the least interesting property because most objects I see as beneficial as being used temporarily, in mutable form, to implement a pure function (or even a broader concept, like a "pure system" which might be an object or series of functions with the ultimate effect of merely inputting something and outputting something new without touching anything else), and I think immutability taken to the extremities in a largely imperative language is a rather counter-productive goal. I'd apply it sparingly for the parts of the codebase where it really helps the most.

6 added 29 characters in body
source | link

So the ability to cheaply copy the really hefty data of your application state around and output new, modified versions with minimal cost to processing and memory use can really open up new doors for purity and effective parallelism, and there I find lots of lessons to learn from how persistent data structures are implemented. But whatever we create using such lessons don't have to be strictly persistent, or offer immutable interfaces (it might use copy-on-write, for example, or a "builder/transient"), to achieve this ability to be dirt cheap to copy around and modify just sections of the copy without doubling up memory use and memory access in our quest for parallelism and purity in our functions/systems/pipeline.

But I find this the least interesting property because most objects I see as beneficial as being used temporarily, in mutable form, to implement a pure function (or even a broader concept, like a "pure system"), and I think immutability taken to the extremities in a largely imperative language is a rather counter-productive goal. I'd apply it sparingly for the parts of the codebase where it really helps the most.

So the ability to cheaply copy the really hefty data of your application state around and output new, modified versions with minimal cost to processing and memory use can really open up new doors for purity and effective parallelism, and there I find lots of lessons to learn from how persistent data structures are implemented. But whatever we create using such lessons don't have to be strictly persistent, or offer immutable interfaces (it might use copy-on-write, for example, or a "builder/transient"), to achieve this ability to be dirt cheap to copy around and modify just sections of the copy without doubling up memory use and memory access.

But I find this the least interesting property because most objects I see as beneficial as being used temporarily to implement a pure function, and I think immutability taken to the extremities in a largely imperative language is a rather counter-productive goal. I'd apply it sparingly for the parts of the codebase where it really helps the most.

So the ability to cheaply copy the really hefty data of your application state around and output new, modified versions with minimal cost to processing and memory use can really open up new doors for purity and effective parallelism, and there I find lots of lessons to learn from how persistent data structures are implemented. But whatever we create using such lessons don't have to be strictly persistent, or offer immutable interfaces (it might use copy-on-write, for example, or a "builder/transient"), to achieve this ability to be dirt cheap to copy around and modify just sections of the copy without doubling up memory use and memory access in our quest for parallelism and purity in our functions/systems/pipeline.

But I find this the least interesting property because most objects I see as beneficial as being used temporarily, in mutable form, to implement a pure function (or even a broader concept, like a "pure system"), and I think immutability taken to the extremities in a largely imperative language is a rather counter-productive goal. I'd apply it sparingly for the parts of the codebase where it really helps the most.

5 added 29 characters in body
source | link
4 added 34 characters in body
source | link
3 added 91 characters in body
source | link
2 added 1024 characters in body
source | link
1
source | link