Hi all!
Henry raised the point about non.descriptive bug reports earlier. I would like to bring this to everyone's mind again and add some additional thoughts: We are seeing a lot of issues reported right now, and a lot of pull requests opened right now, for issues that are not really a problem. There are many places in the code, where one could write things slightly different. Some of these slightly different variations may look slightly more efficient at a first glance, but are not anywhere on a hot code path, so they actually do not really make any difference. However, every of those changes introduces the possibility of new bugs. Quite a few of the proposed fixes had actually changed the semantics, with the result that they would have broken the system instead of improving anything. This has been famously summed up by Donald Knuth in his quote: "*Premature optimization is the root of all evil"* Before changing a line of code in the attempt to do one comparison less, please check whether the change is actually worth it: - Better more checks than fewer checks, if the code path is not hot. Catching bugs better / earlier is worth a lot. - On modern processors, performance of non-I/O code is almost always limited by memory access delays (cache / TLB misses). Arithmetic and checks are comparatively cheap, meaning that that optimizing it usually matters only in arithmetic loops, or the hottest code paths. - Good fixes are still all fixes that address any form of resource leak, or forgotten closing of streams, clients, ... - Performance critical in Flink's runtime are mainly the Serializer code, the hash/sort algorithms, the network/disk code, the driver loops for the operators. - On the JobManager, the number and dependencies of deployment messages, and the complexity of the graph traversal dominate all other computation. - Correctness and safety are always more critical than the last 1% of performance. This was my personal view on things, please write if you agree or disagree. Greetings, Stephan |
I agree!
A good place to start would be to write an extensive JIRA guidelines page, an example would be https://cwiki.apache.org/confluence/display/SPARK/Contributing+to+Spark. This is quite crisp and clear. Further, right now the corresponding guidelines for Flink are on the cwiki page, but the main README links to http://flink.apache.org/how-to-contribute.html. We should perhaps merge the cwiki page content here. Regards Sachin -- Sachin Goel Computer Science, IIT Delhi m. +91-9871457685 On Sun, Aug 16, 2015 at 9:21 PM, Stephan Ewen <[hidden email]> wrote: > Hi all! > > Henry raised the point about non.descriptive bug reports earlier. I would > like to bring this to everyone's mind again and add some additional > thoughts: > > We are seeing a lot of issues reported right now, and a lot of pull > requests opened right now, for issues that are not really a problem. > > There are many places in the code, where one could write things slightly > different. Some of these slightly different variations may look slightly > more efficient at a first glance, but are not anywhere on a hot code path, > so they actually do not really make any difference. > > However, every of those changes introduces the possibility of new bugs. > Quite a few of the proposed fixes had actually changed the semantics, with > the result that they would have broken the system instead of improving > anything. > > This has been famously summed up by Donald Knuth in his quote: > > "*Premature optimization is the root of all evil"* > > Before changing a line of code in the attempt to do one comparison less, > please check whether the change is actually worth it: > > - Better more checks than fewer checks, if the code path is not hot. > Catching bugs better / earlier is worth a lot. > > - On modern processors, performance of non-I/O code is almost always > limited by memory access delays (cache / TLB misses). Arithmetic and checks > are comparatively cheap, meaning that that optimizing it usually matters > only in arithmetic loops, or the hottest code paths. > > - Good fixes are still all fixes that address any form of resource leak, > or forgotten closing of streams, clients, ... > > - Performance critical in Flink's runtime are mainly the Serializer code, > the hash/sort algorithms, the network/disk code, the driver loops for the > operators. > > - On the JobManager, the number and dependencies of deployment messages, > and the complexity of the graph traversal dominate all other computation. > > - Correctness and safety are always more critical than the last 1% of > performance. > > > This was my personal view on things, please write if you agree or disagree. > > > Greetings, > Stephan > |
+1 from me as well.
I'd like to add that there are many relevant issues in listed in JIRA that report bugs or describe interesting / important improvements of the system. Working on one of these issues would be a great contribution to Flink. Cheers, Fabian 2015-08-16 18:30 GMT+02:00 Sachin Goel <[hidden email]>: > I agree! > A good place to start would be to write an extensive JIRA guidelines page, > an example would be > https://cwiki.apache.org/confluence/display/SPARK/Contributing+to+Spark. > This is quite crisp and clear. > Further, right now the corresponding guidelines for Flink are on the cwiki > page, but the main README links to > http://flink.apache.org/how-to-contribute.html. We should perhaps merge > the > cwiki page content here. > > Regards > Sachin > > -- Sachin Goel > Computer Science, IIT Delhi > m. +91-9871457685 > > On Sun, Aug 16, 2015 at 9:21 PM, Stephan Ewen <[hidden email]> wrote: > > > Hi all! > > > > Henry raised the point about non.descriptive bug reports earlier. I would > > like to bring this to everyone's mind again and add some additional > > thoughts: > > > > We are seeing a lot of issues reported right now, and a lot of pull > > requests opened right now, for issues that are not really a problem. > > > > There are many places in the code, where one could write things slightly > > different. Some of these slightly different variations may look slightly > > more efficient at a first glance, but are not anywhere on a hot code > path, > > so they actually do not really make any difference. > > > > However, every of those changes introduces the possibility of new bugs. > > Quite a few of the proposed fixes had actually changed the semantics, > with > > the result that they would have broken the system instead of improving > > anything. > > > > This has been famously summed up by Donald Knuth in his quote: > > > > "*Premature optimization is the root of all evil"* > > > > Before changing a line of code in the attempt to do one comparison less, > > please check whether the change is actually worth it: > > > > - Better more checks than fewer checks, if the code path is not hot. > > Catching bugs better / earlier is worth a lot. > > > > - On modern processors, performance of non-I/O code is almost always > > limited by memory access delays (cache / TLB misses). Arithmetic and > checks > > are comparatively cheap, meaning that that optimizing it usually matters > > only in arithmetic loops, or the hottest code paths. > > > > - Good fixes are still all fixes that address any form of resource leak, > > or forgotten closing of streams, clients, ... > > > > - Performance critical in Flink's runtime are mainly the Serializer > code, > > the hash/sort algorithms, the network/disk code, the driver loops for the > > operators. > > > > - On the JobManager, the number and dependencies of deployment > messages, > > and the complexity of the graph traversal dominate all other computation. > > > > - Correctness and safety are always more critical than the last 1% of > > performance. > > > > > > This was my personal view on things, please write if you agree or > disagree. > > > > > > Greetings, > > Stephan > > > |
+1 as well.
This is a great follow-up from my previous email about adding details in JIRA, which also being echoed by Fabian. - Henry On Sun, Aug 16, 2015 at 3:45 PM, Fabian Hueske <[hidden email]> wrote: > +1 from me as well. > > I'd like to add that there are many relevant issues in listed in JIRA that > report bugs or describe interesting / important improvements of the system. > Working on one of these issues would be a great contribution to Flink. > > Cheers, Fabian > > 2015-08-16 18:30 GMT+02:00 Sachin Goel <[hidden email]>: > >> I agree! >> A good place to start would be to write an extensive JIRA guidelines page, >> an example would be >> https://cwiki.apache.org/confluence/display/SPARK/Contributing+to+Spark. >> This is quite crisp and clear. >> Further, right now the corresponding guidelines for Flink are on the cwiki >> page, but the main README links to >> http://flink.apache.org/how-to-contribute.html. We should perhaps merge >> the >> cwiki page content here. >> >> Regards >> Sachin >> >> -- Sachin Goel >> Computer Science, IIT Delhi >> m. +91-9871457685 >> >> On Sun, Aug 16, 2015 at 9:21 PM, Stephan Ewen <[hidden email]> wrote: >> >> > Hi all! >> > >> > Henry raised the point about non.descriptive bug reports earlier. I would >> > like to bring this to everyone's mind again and add some additional >> > thoughts: >> > >> > We are seeing a lot of issues reported right now, and a lot of pull >> > requests opened right now, for issues that are not really a problem. >> > >> > There are many places in the code, where one could write things slightly >> > different. Some of these slightly different variations may look slightly >> > more efficient at a first glance, but are not anywhere on a hot code >> path, >> > so they actually do not really make any difference. >> > >> > However, every of those changes introduces the possibility of new bugs. >> > Quite a few of the proposed fixes had actually changed the semantics, >> with >> > the result that they would have broken the system instead of improving >> > anything. >> > >> > This has been famously summed up by Donald Knuth in his quote: >> > >> > "*Premature optimization is the root of all evil"* >> > >> > Before changing a line of code in the attempt to do one comparison less, >> > please check whether the change is actually worth it: >> > >> > - Better more checks than fewer checks, if the code path is not hot. >> > Catching bugs better / earlier is worth a lot. >> > >> > - On modern processors, performance of non-I/O code is almost always >> > limited by memory access delays (cache / TLB misses). Arithmetic and >> checks >> > are comparatively cheap, meaning that that optimizing it usually matters >> > only in arithmetic loops, or the hottest code paths. >> > >> > - Good fixes are still all fixes that address any form of resource leak, >> > or forgotten closing of streams, clients, ... >> > >> > - Performance critical in Flink's runtime are mainly the Serializer >> code, >> > the hash/sort algorithms, the network/disk code, the driver loops for the >> > operators. >> > >> > - On the JobManager, the number and dependencies of deployment >> messages, >> > and the complexity of the graph traversal dominate all other computation. >> > >> > - Correctness and safety are always more critical than the last 1% of >> > performance. >> > >> > >> > This was my personal view on things, please write if you agree or >> disagree. >> > >> > >> > Greetings, >> > Stephan >> > >> |
+1, there is no point in arguing with Knuth.
On Mon, Aug 17, 2015 at 1:07 AM, Henry Saputra <[hidden email]> wrote: > +1 as well. > > This is a great follow-up from my previous email about adding details > in JIRA, which also being echoed by Fabian. > > - Henry > > On Sun, Aug 16, 2015 at 3:45 PM, Fabian Hueske <[hidden email]> wrote: > > +1 from me as well. > > > > I'd like to add that there are many relevant issues in listed in JIRA > that > > report bugs or describe interesting / important improvements of the > system. > > Working on one of these issues would be a great contribution to Flink. > > > > Cheers, Fabian > > > > 2015-08-16 18:30 GMT+02:00 Sachin Goel <[hidden email]>: > > > >> I agree! > >> A good place to start would be to write an extensive JIRA guidelines > page, > >> an example would be > >> https://cwiki.apache.org/confluence/display/SPARK/Contributing+to+Spark > . > >> This is quite crisp and clear. > >> Further, right now the corresponding guidelines for Flink are on the > cwiki > >> page, but the main README links to > >> http://flink.apache.org/how-to-contribute.html. We should perhaps merge > >> the > >> cwiki page content here. > >> > >> Regards > >> Sachin > >> > >> -- Sachin Goel > >> Computer Science, IIT Delhi > >> m. +91-9871457685 > >> > >> On Sun, Aug 16, 2015 at 9:21 PM, Stephan Ewen <[hidden email]> wrote: > >> > >> > Hi all! > >> > > >> > Henry raised the point about non.descriptive bug reports earlier. I > would > >> > like to bring this to everyone's mind again and add some additional > >> > thoughts: > >> > > >> > We are seeing a lot of issues reported right now, and a lot of pull > >> > requests opened right now, for issues that are not really a problem. > >> > > >> > There are many places in the code, where one could write things > slightly > >> > different. Some of these slightly different variations may look > slightly > >> > more efficient at a first glance, but are not anywhere on a hot code > >> path, > >> > so they actually do not really make any difference. > >> > > >> > However, every of those changes introduces the possibility of new > bugs. > >> > Quite a few of the proposed fixes had actually changed the semantics, > >> with > >> > the result that they would have broken the system instead of improving > >> > anything. > >> > > >> > This has been famously summed up by Donald Knuth in his quote: > >> > > >> > "*Premature optimization is the root of all evil"* > >> > > >> > Before changing a line of code in the attempt to do one comparison > less, > >> > please check whether the change is actually worth it: > >> > > >> > - Better more checks than fewer checks, if the code path is not hot. > >> > Catching bugs better / earlier is worth a lot. > >> > > >> > - On modern processors, performance of non-I/O code is almost always > >> > limited by memory access delays (cache / TLB misses). Arithmetic and > >> checks > >> > are comparatively cheap, meaning that that optimizing it usually > matters > >> > only in arithmetic loops, or the hottest code paths. > >> > > >> > - Good fixes are still all fixes that address any form of resource > leak, > >> > or forgotten closing of streams, clients, ... > >> > > >> > - Performance critical in Flink's runtime are mainly the Serializer > >> code, > >> > the hash/sort algorithms, the network/disk code, the driver loops for > the > >> > operators. > >> > > >> > - On the JobManager, the number and dependencies of deployment > >> messages, > >> > and the complexity of the graph traversal dominate all other > computation. > >> > > >> > - Correctness and safety are always more critical than the last 1% of > >> > performance. > >> > > >> > > >> > This was my personal view on things, please write if you agree or > >> disagree. > >> > > >> > > >> > Greetings, > >> > Stephan > >> > > >> > |
big +1
On Tue, Aug 18, 2015 at 10:43 AM, Till Rohrmann <[hidden email]> wrote: > +1, there is no point in arguing with Knuth. > > On Mon, Aug 17, 2015 at 1:07 AM, Henry Saputra <[hidden email]> > wrote: > > > +1 as well. > > > > This is a great follow-up from my previous email about adding details > > in JIRA, which also being echoed by Fabian. > > > > - Henry > > > > On Sun, Aug 16, 2015 at 3:45 PM, Fabian Hueske <[hidden email]> > wrote: > > > +1 from me as well. > > > > > > I'd like to add that there are many relevant issues in listed in JIRA > > that > > > report bugs or describe interesting / important improvements of the > > system. > > > Working on one of these issues would be a great contribution to Flink. > > > > > > Cheers, Fabian > > > > > > 2015-08-16 18:30 GMT+02:00 Sachin Goel <[hidden email]>: > > > > > >> I agree! > > >> A good place to start would be to write an extensive JIRA guidelines > > page, > > >> an example would be > > >> > https://cwiki.apache.org/confluence/display/SPARK/Contributing+to+Spark > > . > > >> This is quite crisp and clear. > > >> Further, right now the corresponding guidelines for Flink are on the > > cwiki > > >> page, but the main README links to > > >> http://flink.apache.org/how-to-contribute.html. We should perhaps > merge > > >> the > > >> cwiki page content here. > > >> > > >> Regards > > >> Sachin > > >> > > >> -- Sachin Goel > > >> Computer Science, IIT Delhi > > >> m. +91-9871457685 > > >> > > >> On Sun, Aug 16, 2015 at 9:21 PM, Stephan Ewen <[hidden email]> > wrote: > > >> > > >> > Hi all! > > >> > > > >> > Henry raised the point about non.descriptive bug reports earlier. I > > would > > >> > like to bring this to everyone's mind again and add some additional > > >> > thoughts: > > >> > > > >> > We are seeing a lot of issues reported right now, and a lot of pull > > >> > requests opened right now, for issues that are not really a problem. > > >> > > > >> > There are many places in the code, where one could write things > > slightly > > >> > different. Some of these slightly different variations may look > > slightly > > >> > more efficient at a first glance, but are not anywhere on a hot code > > >> path, > > >> > so they actually do not really make any difference. > > >> > > > >> > However, every of those changes introduces the possibility of new > > bugs. > > >> > Quite a few of the proposed fixes had actually changed the > semantics, > > >> with > > >> > the result that they would have broken the system instead of > improving > > >> > anything. > > >> > > > >> > This has been famously summed up by Donald Knuth in his quote: > > >> > > > >> > "*Premature optimization is the root of all evil"* > > >> > > > >> > Before changing a line of code in the attempt to do one comparison > > less, > > >> > please check whether the change is actually worth it: > > >> > > > >> > - Better more checks than fewer checks, if the code path is not > hot. > > >> > Catching bugs better / earlier is worth a lot. > > >> > > > >> > - On modern processors, performance of non-I/O code is almost > always > > >> > limited by memory access delays (cache / TLB misses). Arithmetic and > > >> checks > > >> > are comparatively cheap, meaning that that optimizing it usually > > matters > > >> > only in arithmetic loops, or the hottest code paths. > > >> > > > >> > - Good fixes are still all fixes that address any form of resource > > leak, > > >> > or forgotten closing of streams, clients, ... > > >> > > > >> > - Performance critical in Flink's runtime are mainly the Serializer > > >> code, > > >> > the hash/sort algorithms, the network/disk code, the driver loops > for > > the > > >> > operators. > > >> > > > >> > - On the JobManager, the number and dependencies of deployment > > >> messages, > > >> > and the complexity of the graph traversal dominate all other > > computation. > > >> > > > >> > - Correctness and safety are always more critical than the last 1% > of > > >> > performance. > > >> > > > >> > > > >> > This was my personal view on things, please write if you agree or > > >> disagree. > > >> > > > >> > > > >> > Greetings, > > >> > Stephan > > >> > > > >> > > > |
Free forum by Nabble | Edit this page |