Re: [fonc] Physics Simulation (Re: Everything You Know (about Parallel Programming) Is Wrong!: A Wild Screed about the Future)

On 4/3/2012 9:29 PM, Miles Fidelman wrote: BGB wrote: On 4/3/2012 10:47 AM, Miles Fidelman wrote: Hah. You've obviously never been involved in building a CGF simulator (Computer Generated Forces) - absolute spaghetti code when you have to have 4 main loops, touch 2000 objects (say 2000 tan

Re: [fonc] Everything You Know (about Parallel Programming) Is Wrong!: A Wild Screed about the Future

On Tue, Apr 3, 2012 at 7:55 PM, Miles Fidelman wrote: > >> You seem to be starting from the assumption that process per object is a >> good thing. >> > > absolutely - I come from a networking background - you spawn a process for > everything - it's conceptually simpler all around - and as far as I

Re: [fonc] Physics Simulation (Re: Everything You Know (about Parallel Programming) Is Wrong!: A Wild Screed about the Future)

BGB wrote: On 4/3/2012 10:47 AM, Miles Fidelman wrote: Hah. You've obviously never been involved in building a CGF simulator (Computer Generated Forces) - absolute spaghetti code when you have to have 4 main loops, touch 2000 objects (say 2000 tanks) every simulation frame. Comparatively

[fonc] Physics Simulation (Re: Everything You Know (about Parallel Programming) Is Wrong!: A Wild Screed about the Future)

(changed subject, as this was much more about physics simulation than about concurrency). yes, this is a big long "personal history dump" type thing, please ignore if you don't care. On 4/3/2012 10:47 AM, Miles Fidelman wrote: David Barbour wrote: Control flow is a source of much implicit

Re: [fonc] Everything You Know (about Parallel Programming) Is Wrong!: A Wild Screed about the Future

David Barbour wrote: On Tue, Apr 3, 2012 at 5:17 PM, Miles Fidelman mailto:mfidel...@meetinghouse.net>> wrote: But there are good architectures that won't become spaghetti code in these circumstances. If you pipelined 2000 tank data objects through four processes each

Re: [fonc] Everything You Know (about Parallel Programming) Is Wrong!: A Wild Screed about the Future

On Tue, Apr 3, 2012 at 5:17 PM, Miles Fidelman wrote: > >> But there are good architectures that won't become spaghetti code in >> these circumstances. If you pipelined 2000 tank data objects through four >> processes each instant, for example (i.e. so tanks 1-100 are in the last >> process of f

Re: [fonc] Everything You Know (about Parallel Programming) Is Wrong!: A Wild Screed about the Future

On 4/3/2012 9:46 AM, Miles Fidelman wrote: David Barbour wrote: On Tue, Apr 3, 2012 at 8:25 AM, Eugen Leitl > wrote: It's not just imperative programming. The superficial mode of human cognition is sequential. This is the problem with all of mathematics and

Re: [fonc] Everything You Know (about Parallel Programming) Is Wrong!: A Wild Screed about the Future

David Barbour wrote: On Tue, Apr 3, 2012 at 10:47 AM, Miles Fidelman mailto:mfidel...@meetinghouse.net>> wrote: Hah. You've obviously never been involved in building a CGF simulator (Computer Generated Forces) - absolute spaghetti code when you have to have 4 main loops, touch 2

Re: [fonc] Everything You Know (about Parallel Programming) Is Wrong!: A Wild Screed about the Future

On Tue, Apr 3, 2012 at 10:47 AM, Miles Fidelman wrote: > Hah. You've obviously never been involved in building a CGF simulator > (Computer Generated Forces) - absolute spaghetti code when you have to have > 4 main loops, touch 2000 objects (say 2000 tanks) every simulation frame. > Comparatively

Re: [fonc] Everything You Know (about Parallel Programming) Is Wrong!: A Wild Screed about the Future

David Barbour wrote: On Tue, Apr 3, 2012 at 9:46 AM, Miles Fidelman mailto:mfidel...@meetinghouse.net>> wrote: And for that matter, driving a car, playing a sport, walking and chewing gum at the same time :-) Would this be a Flintstones racecar? I can think of a lot of

Re: [fonc] Everything You Know (about Parallel Programming) Is Wrong!: A Wild Screed about the Future

On Tue, Apr 3, 2012 at 10:22 AM, David Barbour wrote: > I think the parallel programming models of the future will look more like > Dedalus, Bloom, synchronous reactive, or concurrent constraint programming. > Or my reactive demand programming. Dataflows, with lots of isolation for > modularity a

Re: [fonc] Everything You Know (about Parallel Programming) Is Wrong!: A Wild Screed about the Future

On Tue, Apr 3, 2012 at 9:46 AM, Miles Fidelman wrote: > > And for that matter, driving a car, playing a sport, walking and chewing > gum at the same time :-) Would this be a Flintstones racecar? > > >> I can think of a lot of single-threaded interfaces that put people in a >> universe of pain.

Re: [fonc] Everything You Know (about Parallel Programming) Is Wrong!: A Wild Screed about the Future

David Barbour wrote: On Tue, Apr 3, 2012 at 8:25 AM, Eugen Leitl > wrote: It's not just imperative programming. The superficial mode of human cognition is sequential. This is the problem with all of mathematics and computer science as well. Perhaps human a

Re: [fonc] Everything You Know (about Parallel Programming) Is Wrong!: A Wild Screed about the Future

On Tue, Apr 3, 2012 at 8:25 AM, Eugen Leitl wrote: > It's not just imperative programming. The superficial mode of human > cognition is sequential. This is the problem with all of mathematics > and computer science as well. > Perhaps human attention is basically sequential, as we're only able to

Re: [fonc] Everything You Know (about Parallel Programming) Is Wrong!: A Wild Screed about the Future

Eugen Leitl wrote: On Tue, Apr 03, 2012 at 08:19:53AM -0700, David Barbour wrote: That said, I also disagree with Tom, there: design complexity doesn't need to increase with parallelism. The tradeoff between complexity vs. parallelism is more an artifact of sticking with imperative programming.

Re: [fonc] Everything You Know (about Parallel Programming) Is Wrong!: A Wild Screed about the Future

On Tue, Apr 03, 2012 at 08:19:53AM -0700, David Barbour wrote: > That said, I also disagree with Tom, there: design complexity doesn't need > to increase with parallelism. The tradeoff between complexity vs. > parallelism is more an artifact of sticking with imperative programming. It's not just

Re: [fonc] Everything You Know (about Parallel Programming) Is Wrong!: A Wild Screed about the Future

On Tue, Apr 3, 2012 at 8:02 AM, Miles Fidelman wrote: > On Tue, Apr 3, 2012 at 7:23 AM, Tom Novelli wrote: > >> Even if there does turn out to be a simple and general way to do parallel >> >>> programming, there'll always be tradeoffs weighing against it - energy >> usage >> and design complexity

Re: [fonc] Everything You Know (about Parallel Programming) Is Wrong!: A Wild Screed about the Future

Steven Robertson wrote: On Tue, Apr 3, 2012 at 7:23 AM, Tom Novelli wrote: Even if there does turn out to be a simple and general way to do parallel programming, there'll always be tradeoffs weighing against it - energy usage and design complexity, to name two obvious ones. To design complexit

Re: [fonc] Everything You Know (about Parallel Programming) Is Wrong!: A Wild Screed about the Future

On Tue, Apr 3, 2012 at 7:23 AM, Tom Novelli wrote: > Even if there does turn out to be a simple and general way to do parallel > programming, there'll always be tradeoffs weighing against it - energy usage > and design complexity, to name two obvious ones. Not necessarily. As to the former, not

Re: [fonc] Everything You Know (about Parallel Programming) Is Wrong!: A Wild Screed about the Future

Is Ungar focusing on general-purpose computing or just high-performance computing? Unless he's strictly talking about HPC, he could be way off the mark. For the past 5-10 years there's been a general assumption that massive parallelism will be necessary as CPU speeds max out. But then there's ta