Show HN: Work for Performance – Open performance issues on open-source | Hacker News Reader

Show HN: Work for Performance – Open performance issues on open-source

workforperformance.com

103 pointsfn122 comments

> 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.

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.

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...

Jevon's paradox

https://en.m.wikipedia.org/wiki/Jevons_paradox

If this fits here then it maybe it really just means performance matters for adoption?

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.

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?

> 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…

> 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.

YYYY.MM.DD or YYYY-MM-DD is unambiguous if you would like to improve it.

ISO 8601 - https://xkcd.com/1179/

Because it's sorted better: https://www.reddit.com/r/ISO8601/comments/lkusca/improved_vi...

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.

All of the "performance improvements" I've seen (only few TBF) were either not real improvements at all (think of, "I read once that in JS inverting the for() order is faster", without any benchmark) or true but very marginal improvements while making the code impossible to maintain (think a blob of 10 lines of bit shifting/impossible regexp).

From this we can clearly see that using C, C++, or Rust results in open source projects without performance issues.

I have added more languages. C++ scraping does not work yet for some reason.

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

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.

Neat idea! There's no C, C++, Perl, or MATLAB entry though, so my ability to help is limited... :/

Surely there's a need for "implement <foo> in better machine code" work, in other languages and projects, no?

Interesting idea. Will you be adding other languages?

Perhaps add "slow" to the regex?

I have added "slow".

Some links to jump directly to the programming language of choice would be great.

Interesting initiative.

Reply on news.ycombinator.com