4 ms·

11k defines in gc is nothing, the files in the nbio dir are so big, github even refuses to parse many them: https://kernel.googlesource.com/pub/scm/linux/kerne

by cnst 1y ago

11k defines in gc is nothing, the files in the nbio dir are so big, github even refuses to parse many them: https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux/+/refs/heads/master/drivers/gpu/drm/amd/include/asic_reg/nbio/ https://kernel.googlesource.com/pub/scm/linux/kernel/git/tor... https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/amd/include/asic_reg/nbio/nbio_7_9_0_sh_mask.h https://github.com/torvalds/linux/blob/master/drivers/gpu/dr... The last file in nbio is a header file with 38900 lines — a single file of 3.92 MB. There's actually another one in nbio that's 16MB: https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/amd/include/asic_reg/nbio/nbio_7_7_0_sh_mask.h https://github.com/torvalds/linux/blob/master/drivers/gpu/dr...

burnt-resistor 1y ago
Brotli was able to crush it down to 229 KiB after about 30 seconds, but still, this is an absurd amount of unnecessary, low value bullshit.
- layla5alive 1y ago
  Clearly this is generated code. I have mixed feelings about this. On the one hand, I'm glad its a single file, as its faster to parse than if it'd been split up among a whole bunch of smaller files. And that it isn't generated during the build is a complexity advantage, even if it is huge. OTOH, no human is going to read this whole file, so I wonder if there was not a better way.
  - burnt-resistor 1y ago
    All other things being equal, I'd rather have a codegen step added to the build process for mechanical, non-human-maintained code rather than foist mega files on everyone if those were the only two choices.
    - beeflet 1y ago
      I suppose it depends on the portability of the mega-files. It could be an output from a complex non-portable program.
      - burnt-resistor 1y ago
        Don't make or allow complex, non-portable programs. There's no reason for this. Simplicity and Turing completeness means it can always be written in something understandable and maintainable.
        lunar-whitey 1y ago
        Simple portable programs that perform nontrivial tasks are expensive. Open source overcomes this where possible by socializing the cost.
        emchammer 1y ago
        I use open-source OpenBSD is because the entire source tree is small enough for me to understand and manipulate. I guess I expect that it is all human-generated. This unwieldy, proprietary chunk makes me want to ditch graphics support in order to keep my source tree significantly smaller.
        lunar-whitey 1y ago
        After cleaning up the sources, the whole chip would still be an unwieldy proprietary chunk - you would just be able to ignore it more easily.
    - cnst 1y ago
      If you look at the history of these files, they've basically changed at most once after being committed years ago. Regenerating such static data from some master source, would be completely pointless, and would add pointless extra dependencies to the build process, and in this specific case, may likely not even be possible because of the proprietary nature of the off-topic tooling that may be required for effective management of the initial files. --- In OpenBSD, NetBSD and other systems, there's actually a whole bunch of machine-generated files that are always part of the repository. Things like build manifests (lists of all the binary files in the shipping product, e.g., distrib/sets/lists/base/mi) and pcidevs/usbdevs, are things that immediately come to mind: https://github.com/search?q=repo%3Aopenbsd%2Fsrc+sync&type=commits https://github.com/search?q=repo%3Aopenbsd%2Fsrc+sync&type=c... https://github.com/search?q=repo%3Aopenbsd%2Fsrc+regen&type=commits https://github.com/search?q=repo%3Aopenbsd%2Fsrc+regen&type=... Avoiding bison/yacc parser generators as a build dependency, is another common case for the practice. Personally, I'm a huge proponent of the practice. It allows you to reduce the complexity of the build system, increase the transparency on the history of the changes, and allows people to have a better understanding of where things are coming from, because you can directly find those things in the respective pcidevs.h / usbdevs.h, instead of wondering what is going on, and where those things are defined. It's a HUGE advantage. I never understood why so many people are horrified at the idea of small amounts of the machine-generated code being manually committed straight into the repositories. It seems like they're incorrectly applying the general rule against such practice, ignoring the specific exceptions that are certainly most beneficial under the circumstances. One of my favourite other examples is the self-documenting code. E.g., man-pages or test results. For example, maybe you use Go, and your man-pages are automatically generated based on the inline documentation within each go file itself. Committing such human-readable artefacts into the repository is a great idea if that allows everyone to immediately see what's going on with regards to the documentation, instead of having to run the code to see how it works. This increases transparency and code review efficiency, make it easier to promote the changes, because it's very clear to everyone what's going on, without having to reverse-engineer the code, or apply the patches and recompile etc. Of course, if your whole idea is to hide things from management, and increase the complexity of the system to prevent the newcomers from catching up quickly, then such practices may indeed be detrimental.
hulitu 1y ago
> The last file in nbio is a header file with 38900 lines — a single file of 3.92 MB. Good programming practices gone extreme. We really need some low memory machines for developers.

by cnst 1y ago

burnt-resistor 1y ago

Brotli was able to crush it down to 229 KiB after about 30 seconds, but still, this is an absurd amount of unnecessary, low value bullshit.

layla5alive 1y ago
Clearly this is generated code. I have mixed feelings about this. On the one hand, I'm glad its a single file, as its faster to parse than if it'd been split up among a whole bunch of smaller files. And that it isn't generated during the build is a complexity advantage, even if it is huge. OTOH, no human is going to read this whole file, so I wonder if there was not a better way.
- burnt-resistor 1y ago
  All other things being equal, I'd rather have a codegen step added to the build process for mechanical, non-human-maintained code rather than foist mega files on everyone if those were the only two choices.
  - beeflet 1y ago
    I suppose it depends on the portability of the mega-files. It could be an output from a complex non-portable program.
    - burnt-resistor 1y ago
      Don't make or allow complex, non-portable programs. There's no reason for this. Simplicity and Turing completeness means it can always be written in something understandable and maintainable.
      - lunar-whitey 1y ago
        Simple portable programs that perform nontrivial tasks are expensive. Open source overcomes this where possible by socializing the cost.
        emchammer 1y ago
        I use open-source OpenBSD is because the entire source tree is small enough for me to understand and manipulate. I guess I expect that it is all human-generated. This unwieldy, proprietary chunk makes me want to ditch graphics support in order to keep my source tree significantly smaller.
        lunar-whitey 1y ago
        After cleaning up the sources, the whole chip would still be an unwieldy proprietary chunk - you would just be able to ignore it more easily.
  - cnst 1y ago
    If you look at the history of these files, they've basically changed at most once after being committed years ago. Regenerating such static data from some master source, would be completely pointless, and would add pointless extra dependencies to the build process, and in this specific case, may likely not even be possible because of the proprietary nature of the off-topic tooling that may be required for effective management of the initial files. --- In OpenBSD, NetBSD and other systems, there's actually a whole bunch of machine-generated files that are always part of the repository. Things like build manifests (lists of all the binary files in the shipping product, e.g., distrib/sets/lists/base/mi) and pcidevs/usbdevs, are things that immediately come to mind: https://github.com/search?q=repo%3Aopenbsd%2Fsrc+sync&type=commits https://github.com/search?q=repo%3Aopenbsd%2Fsrc+sync&type=c... https://github.com/search?q=repo%3Aopenbsd%2Fsrc+regen&type=commits https://github.com/search?q=repo%3Aopenbsd%2Fsrc+regen&type=... Avoiding bison/yacc parser generators as a build dependency, is another common case for the practice. Personally, I'm a huge proponent of the practice. It allows you to reduce the complexity of the build system, increase the transparency on the history of the changes, and allows people to have a better understanding of where things are coming from, because you can directly find those things in the respective pcidevs.h / usbdevs.h, instead of wondering what is going on, and where those things are defined. It's a HUGE advantage. I never understood why so many people are horrified at the idea of small amounts of the machine-generated code being manually committed straight into the repositories. It seems like they're incorrectly applying the general rule against such practice, ignoring the specific exceptions that are certainly most beneficial under the circumstances. One of my favourite other examples is the self-documenting code. E.g., man-pages or test results. For example, maybe you use Go, and your man-pages are automatically generated based on the inline documentation within each go file itself. Committing such human-readable artefacts into the repository is a great idea if that allows everyone to immediately see what's going on with regards to the documentation, instead of having to run the code to see how it works. This increases transparency and code review efficiency, make it easier to promote the changes, because it's very clear to everyone what's going on, without having to reverse-engineer the code, or apply the patches and recompile etc. Of course, if your whole idea is to hide things from management, and increase the complexity of the system to prevent the newcomers from catching up quickly, then such practices may indeed be detrimental.

hulitu 1y ago

> The last file in nbio is a header file with 38900 lines — a single file of 3.92 MB. Good programming practices gone extreme. We really need some low memory machines for developers.