[HN Gopher] Show HN: Work for Performance - Open performance iss...
___________________________________________________________________
Show HN: Work for Performance - Open performance issues on open-
source
Author : fn1
Score : 82 points
Date : 2021-10-06 13:54 UTC (9 hours ago)
(HTM) web link (www.workforperformance.com)
(TXT) w3m dump (www.workforperformance.com)
| syastrov wrote:
| I thought of this idea as well, but don't think this is really
| the right approach. Many of these issues relate to specific
| features which developers subsequently avoid using. I think these
| types of initiatives should be more broadly targeted and probably
| curated by the maintainers/users of the software. E.g. the
| faster-cpython project is focusing on improving general Python
| interpreter performance: https://github.com/faster-cpython/ideas
| vlovich123 wrote:
| From this we can clearly see that using C, C++, or Rust results
| in open source projects without performance issues.
| the_lonely_road wrote:
| This one is curious. The website appears to suggest that the list
| of open issues being presented was generated over 4 months ago.
| That made me assume it was someone stumbling upon it and then
| sticking it on HN, but the github name on the submission and the
| HN name on here are close enough it is probably the same person.
|
| Shouldn't you regenerate the list at least nightly to be up to
| date so people are not reading over issues potentially closed
| months ago?
|
| My second question is what is driving the short list of
| technologies? You include Typescript and Javascript as seperate
| entries but no Ruby, Rust or C++ all of which jumped out to me
| but no doubt there is a much wider list of relevant technologies
| I am not thinking about as well.
| david_for_you wrote:
| Given that today is 6th Oct, I am gonna guess 06-10-2021 means
| today, and not the 10th of June. More often than not American
| dates would use a 06/10/2021 format, I think?
| deathanatos wrote:
| > _More often than not American dates would use a 06
| /10/2021_
|
| No, we use the nonsense MM/DD/YYYY ordering (usually without
| leading 0s). 6 Oct would be 10/6/2021.
|
| ISO/RFC 3339 YYYY-MM-DD is really the way to go...
| fn1 wrote:
| > This one is curious. The website appears to suggest that the
| list of open issues being presented was generated over 4 months
| ago.
|
| It was generated today. 6.10, not 10.6. Fixed it.
|
| > My second question is what is driving the short list of
| technologies?
|
| I will add more languages.
| euphoria wrote:
| YYYY.MM.DD or YYYY-MM-DD is unambiguous if you would like to
| improve it.
| voiper1 wrote:
| ISO 8601 - https://xkcd.com/1179/
|
| Because it's sorted better: https://www.reddit.com/r/ISO860
| 1/comments/lkusca/improved_vi...
| [deleted]
| fabiospampinato wrote:
| Personally I haven't had a great experience with opening
| performance-related issues, a lot of the times people don't care
| enough about performance, pretty often they feel kind of insulted
| that you are saying that something they have written is slow and
| should be made faster.
|
| A lot of the times, especially if the library is small, I find it
| more useful to just rewrite the whole thing. Or forking it with
| the performance patches and submit a PR, trying to convince
| people to make something faster with an issue doesn't work very
| well in my experience.
| jvilalta wrote:
| Interesting idea. Will you be adding other languages?
| X6S1x6Okd1st wrote:
| > Because climate-change is eating the world. CPUs need power.
| Less CPU-usage equals less power-consumption.
|
| Faster code might result in more CPU-usage not less, because the
| amount of real world value derived by the same amount of
| electricity increases.
|
| That being said I'm all for more efficient & faster code.
| matsemann wrote:
| Jevon's paradox
|
| https://en.m.wikipedia.org/wiki/Jevons_paradox
| imoverclocked wrote:
| If this fits here then it maybe it really just means
| performance matters for adoption?
| verdverm wrote:
| Yea, I was thinking you can't really make a generalization like
| that.
|
| 1. Companies may do more with the same amount of CPU, more
| data, more calculations, despite per evaluation being faster.
|
| 2. Improved performance may make usage within reach of more end
| users
|
| 3. Improving widely used packages could reduce, especially
| those that are used in heavy calculations. With ML, we often
| see more improvement (reduced learning time) through algorithm
| research, so library improvements are only part of the story.
| Of course advances like Capsule Networks and encrypted learning
| sit in the queue because they are too expensive to compute
| today, but have great benefit to the outcomes.
| bee_rider wrote:
| Also depends on what we're doing. Lots of computational tasks
| in engineering will take as many flops as you've got and
| produce a more accurate simulation. The hope would be that
| the end result would be a somehow better device (better fluid
| dynamics -> more aerodynamic car). On the other hand, we have
| things like advertisement which are more of a zero sum
| competition, don't produce anything useful for society as a
| whole, and don't really need to be optimized overall.
| Somewhere in between you have stuff like analysis for
| investing, which is mostly about beating the other guy, but
| does in some nebulous way apparently help allocate resources
| more efficiently...
| dboreham wrote:
| Perhaps add "slow" to the regex?
| tecleandor wrote:
| Some links to jump directly to the programming language of choice
| would be great.
|
| Interesting initiative.
| adsharma wrote:
| The biggest performance problems with python involve the GIL,
| highly dynamic runtime and an extension API that exposes
| internals.
|
| I believe moving python towards a more static type system,
| functional programming and transpilation to other languages is a
| good direction.
___________________________________________________________________
(page generated 2021-10-06 23:01 UTC)