[Pharo-project] Pharo suffers internal Traffic Jams ...
Hi guys! Please first first have a look at that simulation: http://www.youtube.com/watch?v=EmMY1nq_tgI Surprisingly the architecture of pharo looks very much this. Message sends, "information flow" through a dynamic ambience of "living objects" cause serious "hangs" Unpredictable traffic jams occurr, depending on load, e.g. Seaside, during GC, Image sync, subtile timeouts or countdows, waiting for resources to be freed, network timeouts, database lookups, e.t.c. Those can much easier be identified, when you downclock your machine to good old 50MHz of ancient times of squeak and develop/profile then. Design flows pretty soon become visible then, that are not visible when you proudly use always the newest Apple machine for development.
From advanced Software architects of a new old Smalltalk OS i expect to know about such dynamic phenomenons, having deep insight into analytically identifying such normally difficult to indentifying problems, that always should be part of TDD ...
Tnx for reading and understanding. Have fun! Guido Stepken
Guido, Interesting. On the subject of traffic, that simulation is not realistic :) First, you need the college kid in a $50k sport car (complete with lights underneath it, noise-enhancing exhaust and custom rims) talking on a cell phone instead of driving. You also need to add an old lady with her turn signal blinking for miles. Looking at other links, this one caught my eye: http://www.youtube.com/watch?NR=1&v=goVjVVaLe10 I was caught in a jam like they describe, but on a small scale. There is one thing they forgot to mention: people sitting a standstill at the front of the line of traffic and paying NO attention to when they might be able to make forward progress. You had to see this one to believe it - trust me. Back to software, EXCELLENT point about slow machines revealing defects. 50MHz might be overkill, but the point is well taken. This (and some of its links) might be of interest: http://lists.canonical.org/pipermail/kragen-tol/2007-March/000850.html My guess is that the system itself should do very little based on time itself; things should happen based on events. Decisions about what is fast/slow or critical/nonnegotiable are probably best made at the application level. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Guido Stepken [gstepken@googlemail.com] Sent: Sunday, November 06, 2011 9:05 AM To: Pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] Pharo suffers internal Traffic Jams ... Hi guys! Please first first have a look at that simulation: http://www.youtube.com/watch?v=EmMY1nq_tgI Surprisingly the architecture of pharo looks very much this. Message sends, "information flow" through a dynamic ambience of "living objects" cause serious "hangs" Unpredictable traffic jams occurr, depending on load, e.g. Seaside, during GC, Image sync, subtile timeouts or countdows, waiting for resources to be freed, network timeouts, database lookups, e.t.c. Those can much easier be identified, when you downclock your machine to good old 50MHz of ancient times of squeak and develop/profile then. Design flows pretty soon become visible then, that are not visible when you proudly use always the newest Apple machine for development.
From advanced Software architects of a new old Smalltalk OS i expect to know about such dynamic phenomenons, having deep insight into analytically identifying such normally difficult to indentifying problems, that always should be part of TDD ...
Tnx for reading and understanding. Have fun! Guido Stepken
Am 06.11.2011 um 15:05 schrieb Guido Stepken <gstepken@googlemail.com>:
Hi guys!
Please first first have a look at that simulation:
http://www.youtube.com/watch?v=EmMY1nq_tgI
Surprisingly the architecture of pharo looks very much this. Message sends, "information flow" through a dynamic ambience of "living objects" cause serious "hangs"
Unpredictable traffic jams occurr, depending on load, e.g. Seaside, during GC, Image sync, subtile timeouts or countdows, waiting for resources to be freed, network timeouts, database lookups, e.t.c.
Those can much easier be identified, when you downclock your machine to good old 50MHz of ancient times of squeak and develop/profile then. Design flows pretty soon become visible then, that are not visible when you proudly use always the newest Apple machine for development.
From advanced Software architects of a new old Smalltalk OS i expect to know about such dynamic phenomenons, having deep insight into analytically identifying such normally difficult to indentifying problems, that always should be part of TDD ...
Tnx for reading and understanding.
Reading was not a problem. But I have problems to understand what I am supposed to understand? Norbert
Reading was not a problem. But I have problems to understand what I am supposed to understand?
Norbert
You are just coder, no software architect, right? Ever tried Pharo 1.3 on a older machine, e.g. P75 with 32 MBytes RAM, some load on Seaside? Funny effects occurring... machine hangs, crashes, spends lots of time in useless functions, unneccessarily locking resouces, memory pumping, eating up resources while waiting for e.g. database answer, spending increasing amount of time (up to 98%) in removing garbage .... It's a good way of identifying unmatured software designs. Colliding mental models (e.g. event driven vs. polling) Such things happen, when all members are just coding, fixing, refactoring, without bothering about algorithms, that still work reliable at low memory and high load. Pharo at the moment is still very unreliable. Sorry to say that! Think about, why FreeBSD works reliably even at a load of 50, whereas other OS stop working. regards, Guido Stepken
Hi guido I never saw saying anything positive in this mailing-list. May be you should pay attention to you and breath a bit and try another system if pharo is so bad. You are not forced to us it. There is a VisualWorks new license or even other languages. Give a try to them, may be you will like them and do not hurt yourselves like that. Life is short and good for positive energy. Stef On Nov 7, 2011, at 12:00 AM, Guido Stepken wrote:
Reading was not a problem. But I have problems to understand what I am supposed to understand?
Norbert
You are just coder, no software architect, right?
Ever tried Pharo 1.3 on a older machine, e.g. P75 with 32 MBytes RAM, some load on Seaside? Funny effects occurring... machine hangs, crashes, spends lots of time in useless functions, unneccessarily locking resouces, memory pumping, eating up resources while waiting for e.g. database answer, spending increasing amount of time (up to 98%) in removing garbage ....
It's a good way of identifying unmatured software designs.
Colliding mental models (e.g. event driven vs. polling) Such things happen, when all members are just coding, fixing, refactoring, without bothering about algorithms, that still work reliable at low memory and high load.
Pharo at the moment is still very unreliable.
Sorry to say that! Think about, why FreeBSD works reliably even at a load of 50, whereas other OS stop working.
regards, Guido Stepken
Life is short and good for positive energy.
Stef
How do i code that "positive energy" in Pharo without periodically crashing the systen? "FreeHugsClass" with extra positive energy spending methods? Have fun! Guido
On Nov 7, 2011, at 12:00 AM, Guido Stepken wrote:
Reading was not a problem. But I have problems to understand what I am supposed to understand?
Norbert
You are just coder, no software architect, right?
Ever tried Pharo 1.3 on a older machine, e.g. P75 with 32 MBytes RAM, some load on Seaside? Funny effects occurring... machine hangs, crashes, spends lots of time in useless functions, unneccessarily locking resouces, memory pumping, eating up resources while waiting for e.g. database answer, spending increasing amount of time (up to 98%) in removing garbage ....
It's a good way of identifying unmatured software designs.
Colliding mental models (e.g. event driven vs. polling) Such things happen, when all members are just coding, fixing, refactoring, without bothering about algorithms, that still work reliable at low memory and high load.
Pharo at the moment is still very unreliable.
Sorry to say that! Think about, why FreeBSD works reliably even at a load of 50, whereas other OS stop working.
regards, Guido Stepken
Am 07.11.2011 um 00:25 schrieb Guido Stepken:
Life is short and good for positive energy.
Stef
How do i code that "positive energy" in Pharo without periodically crashing the systen? "FreeHugsClass" with extra positive energy spending methods?
That's a lesson you have to tackle on your own, my young apprentice! Norbert
On Nov 7, 2011, at 12:00 AM, Guido Stepken wrote:
Reading was not a problem. But I have problems to understand what I am supposed to understand?
Norbert
You are just coder, no software architect, right?
Ever tried Pharo 1.3 on a older machine, e.g. P75 with 32 MBytes RAM, some load on Seaside? Funny effects occurring... machine hangs, crashes, spends lots of time in useless functions, unneccessarily locking resouces, memory pumping, eating up resources while waiting for e.g. database answer, spending increasing amount of time (up to 98%) in removing garbage ....
It's a good way of identifying unmatured software designs.
Colliding mental models (e.g. event driven vs. polling) Such things happen, when all members are just coding, fixing, refactoring, without bothering about algorithms, that still work reliable at low memory and high load.
Pharo at the moment is still very unreliable.
Sorry to say that! Think about, why FreeBSD works reliably even at a load of 50, whereas other OS stop working.
regards, Guido Stepken
Am 07.11.2011 um 00:00 schrieb Guido Stepken:
Reading was not a problem. But I have problems to understand what I am supposed to understand?
Norbert
You are just coder, no software architect, right?
What is the difference?
Ever tried Pharo 1.3 on a older machine, e.g. P75 with 32 MBytes RAM, some load on Seaside? Funny effects occurring... machine hangs, crashes, spends lots of time in useless functions, unneccessarily locking resouces, memory pumping, eating up resources while waiting for e.g. database answer, spending increasing amount of time (up to 98%) in removing garbage ....
I need to think a little while to come up with a single reason why I should do this. I'll come back to you if I find some. But don't wait for it.
It's a good way of identifying unmatured software designs.
Yes, and spending most of your time on non-realistic cases and yagni makes you just a bad developer.
Colliding mental models (e.g. event driven vs. polling) Such things happen, when all members are just coding, fixing, refactoring, without bothering about algorithms, that still work reliable at low memory and high load.
Ok, how clever are you if you design your machines to have too low memory and suffer from high load? If I recap you are saying that the reason you need to be a good software architect is because you are a bad system architect? If that's right why you don't just learn a little bit about system architecture?
Pharo at the moment is still very unreliable.
Sorry to say that! Think about, why FreeBSD works reliably even at a load of 50, whereas other OS stop working.
Explain it to me, please! Norbert
Norbert, Guido has a point on one front: slow machines can sometimes expose problems that might not otherwise be apparent. It could be as simple as highlighting inefficiency or as involved as changing the fraction of time the machine spends doing various things. Testing under extreme loads has value, and one way to create "load" is to (if only artificially) hobble a machine. I will distance myself from personal attacks on Stef and blanket smears of the processes and hard work that have brought Pharo to its current state. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Norbert Hartl [norbert@hartl.name] Sent: Sunday, November 06, 2011 6:32 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Pharo suffers internal Traffic Jams ... Am 07.11.2011 um 00:00 schrieb Guido Stepken:
Reading was not a problem. But I have problems to understand what I am supposed to understand?
Norbert
You are just coder, no software architect, right?
What is the difference?
Ever tried Pharo 1.3 on a older machine, e.g. P75 with 32 MBytes RAM, some load on Seaside? Funny effects occurring... machine hangs, crashes, spends lots of time in useless functions, unneccessarily locking resouces, memory pumping, eating up resources while waiting for e.g. database answer, spending increasing amount of time (up to 98%) in removing garbage ....
I need to think a little while to come up with a single reason why I should do this. I'll come back to you if I find some. But don't wait for it.
It's a good way of identifying unmatured software designs.
Yes, and spending most of your time on non-realistic cases and yagni makes you just a bad developer.
Colliding mental models (e.g. event driven vs. polling) Such things happen, when all members are just coding, fixing, refactoring, without bothering about algorithms, that still work reliable at low memory and high load.
Ok, how clever are you if you design your machines to have too low memory and suffer from high load? If I recap you are saying that the reason you need to be a good software architect is because you are a bad system architect? If that's right why you don't just learn a little bit about system architecture?
Pharo at the moment is still very unreliable.
Sorry to say that! Think about, why FreeBSD works reliably even at a load of 50, whereas other OS stop working.
Explain it to me, please! Norbert
Bill, don't take my email too serious. I just tried to meet the same level when replying to the original author. Am 07.11.2011 um 01:18 schrieb Schwab,Wilhelm K:
Norbert,
Guido has a point on one front: slow machines can sometimes expose problems that might not otherwise be apparent. It could be as simple as highlighting inefficiency or as involved as changing the fraction of time the machine spends doing various things. Testing under extreme loads has value, and one way to create "load" is to (if only artificially) hobble a machine.
So you are doing it right, Bill. You say it "can" expose problems. That's true because you change the environmental parameters of the running program which has the potential to destabilize it. So you might identify a problem in that scale. What you don't get is an easy conclusion how this applies to your modern hardware. Assuming that all machines are equal and just move on the scale slow-fast is a bit naive. Only if you are like that you can compare an old computer with high load. Architectures change and the odds are high that you identified a problem which will never happen if you try it on a different hardware. There are optimizations that make things just faster. But a lot of optimizations are based on resource shortage. As much as these optimizations make a system more usable/reliable on a certain hardware generation as much they might destabilize the overall system. And some only bring you the gain in a single hardware generation. So my response is more targetted to the fact that the author is capable of demanding things from this community to care about a problem he made up based on his own weak assumptions. No prove, nothing concrete to talk about. Just complains and demands for weird things like the need to "analytically identifying" "unpredictable" things??? Come on!
I will distance myself from personal attacks on Stef and blanket smears of the processes and hard work that have brought Pharo to its current state.
Agreed. To build a community you need to get rid of some of your own ego effects. Maybe that's a reason why ego based mails have a huge potential to harm such a community. Hmmm, but then I didn't do any better in replying :) Rats! Norbert
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Norbert Hartl [norbert@hartl.name] Sent: Sunday, November 06, 2011 6:32 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Pharo suffers internal Traffic Jams ...
Am 07.11.2011 um 00:00 schrieb Guido Stepken:
Reading was not a problem. But I have problems to understand what I am supposed to understand?
Norbert
You are just coder, no software architect, right?
What is the difference?
Ever tried Pharo 1.3 on a older machine, e.g. P75 with 32 MBytes RAM, some load on Seaside? Funny effects occurring... machine hangs, crashes, spends lots of time in useless functions, unneccessarily locking resouces, memory pumping, eating up resources while waiting for e.g. database answer, spending increasing amount of time (up to 98%) in removing garbage ....
I need to think a little while to come up with a single reason why I should do this. I'll come back to you if I find some. But don't wait for it.
It's a good way of identifying unmatured software designs.
Yes, and spending most of your time on non-realistic cases and yagni makes you just a bad developer.
Colliding mental models (e.g. event driven vs. polling) Such things happen, when all members are just coding, fixing, refactoring, without bothering about algorithms, that still work reliable at low memory and high load.
Ok, how clever are you if you design your machines to have too low memory and suffer from high load? If I recap you are saying that the reason you need to be a good software architect is because you are a bad system architect? If that's right why you don't just learn a little bit about system architecture?
Pharo at the moment is still very unreliable.
Sorry to say that! Think about, why FreeBSD works reliably even at a load of 50, whereas other OS stop working.
Explain it to me, please!
Norbert
Norbert Hartl wrote:
Guido has a point on one front: slow machines can sometimes expose problems that might not otherwise be apparent. It could be as simple as highlighting inefficiency or as involved as changing the fraction of time the machine spends doing various things. Testing under extreme loads has value, and one way to create "load" is to (if only artificially) hobble a machine.
So you are doing it right, Bill. You say it "can" expose problems. That's true because you change the environmental parameters of the running program which has the potential to destabilize it. So you might identify a problem in that scale. What you don't get is an easy conclusion how this applies to your modern hardware. Assuming that all machines are equal and just move on the scale slow-fast is a bit naive. Only if you are like that you can compare an old computer with high load. Architectures change and the odds are high that you identified a problem which will never happen if you try it on a different hardware. There are optimizations that make things just faster. But a lot of optimizations are based on resource shortage. As much as these optimizations make a system more usable/reliable on a certain hardware generation as much they might destabilize the overall system. And some only bring you the gain in a single hardware generation.
As Igor pointed out above, a testbed is needed. It seems to me that similar situation to hobbling up a machine can appear if there is a lot of concurrent high-load applications running in parallel with Pharo (like 'node -e "for(;;){}"' run on each core). So maybe the question is how is Pharo behaving in such scenarios. On intel Core Duo+ / AMD Athlon 64 X2+. -- View this message in context: http://forum.world.st/Pharo-suffers-internal-Traffic-Jams-tp3995791p3998327.... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Guido Stepken wrote:
You are just coder, no software architect, right?
Eh?! I am really shocked. I would never imagine that something like this can happen. But it obviously did. What about career change? You may earn a million by teaching courses of Arrogant Pride, won't you? -- View this message in context: http://forum.world.st/Pharo-suffers-internal-Traffic-Jams-tp3995791p3997047.... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Guido, I doubt anyone here would say that Pharo is perfect, but "very unreliable???" That is simply not true. There is polling, and there should not be - I am probably as outspoken as any on that point. Overall, Pharo works very well and is being improved on multiple fronts. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Guido Stepken [gstepken@googlemail.com] Sent: Sunday, November 06, 2011 6:00 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Pharo suffers internal Traffic Jams ...
Reading was not a problem. But I have problems to understand what I am supposed to understand?
Norbert
You are just coder, no software architect, right? Ever tried Pharo 1.3 on a older machine, e.g. P75 with 32 MBytes RAM, some load on Seaside? Funny effects occurring... machine hangs, crashes, spends lots of time in useless functions, unneccessarily locking resouces, memory pumping, eating up resources while waiting for e.g. database answer, spending increasing amount of time (up to 98%) in removing garbage .... It's a good way of identifying unmatured software designs. Colliding mental models (e.g. event driven vs. polling) Such things happen, when all members are just coding, fixing, refactoring, without bothering about algorithms, that still work reliable at low memory and high load. Pharo at the moment is still very unreliable. Sorry to say that! Think about, why FreeBSD works reliably even at a load of 50, whereas other OS stop working. regards, Guido Stepken
Squeak 1.0 was released in 1996. In 1995 i puschased my first PC with 150MHz CPU! So, clearly, it was never targeted for platform with such low clock rate. I think even if you take Squeak 1.0 (the root ancestor of Pharo), you will experience problems running it on 50 MHz CPU. Saying that, i don't deny that there are places which can be improved. But we need two things for that: - a motive - a testbed for it you stated the problem(s) but not motives. Even today's handheld devices running at 1GHz clock rate. Also, who should provide a testbed with such constrained environment? Any ideas? As Marcus practically proved: everything which is not tested is broken. So, either we will have testing platform for issues you listed and strong motivation to fix that, or we just keep expanding our own sandbox in direction we see fit :) On 7 November 2011 00:00, Guido Stepken <gstepken@googlemail.com> wrote:
Reading was not a problem. But I have problems to understand what I am supposed to understand?
Norbert
You are just coder, no software architect, right?
Ever tried Pharo 1.3 on a older machine, e.g. P75 with 32 MBytes RAM, some load on Seaside? Funny effects occurring... machine hangs, crashes, spends lots of time in useless functions, unneccessarily locking resouces, memory pumping, eating up resources while waiting for e.g. database answer, spending increasing amount of time (up to 98%) in removing garbage ....
It's a good way of identifying unmatured software designs.
Colliding mental models (e.g. event driven vs. polling) Such things happen, when all members are just coding, fixing, refactoring, without bothering about algorithms, that still work reliable at low memory and high load.
Pharo at the moment is still very unreliable.
Sorry to say that! Think about, why FreeBSD works reliably even at a load of 50, whereas other OS stop working.
regards, Guido Stepken
-- Best regards, Igor Stasenko.
participants (6)
-
Guido Stepken -
Herby VojÄÃk -
Igor Stasenko -
Norbert Hartl -
Schwab,Wilhelm K -
Stéphane Ducasse