5 ms·

For binary size you could use my hypothetical theorem prover ensuring a binary size below a certain point. That would come at some kind of compile time or effi

For binary size you could use my hypothetical theorem prover ensuring a binary size below a certain point. That would come at some kind of compile time or efficiency cost since you couldn’t anymore optimise for those but I’m sure that’s something one could opt for. I don’t think binary size matters though. Storage is very cheap these days.

wizzwizz4 5y ago
People keep saying that. I have 1.8 GiB available for all my build files, and that's only because I keep deleting the build files of my other projects (meaning they have to be recompiled whenever I go back to them). Storage matters for me. At least the prices are almost normal again, now that Chia's over.
- qualudeheart 5y ago
  Couldn’t you get 4x that much from a $3 usb stick? You could also have self modifying code such that the size of the binary automatically changes as needed. If you ship a lisp interpreter instead of rust, you can have the interpreter recode itself and any lisp files to a smaller size. You’d just implement a compression algorithm that preserves the functionality of the code compressed. I think you could do that with rust too with a self compiling binary. It’ll require some real technical skill but if you hire a real hacker you can pull it off. My cousin his solution for the competitive programming contest had something like that.
  - ithkuil 5y ago
    I doubt a $3 USB stick would perform decently enough to not become a bottleneck in rust compile and link times.
    - bbarnett 5y ago
      There are no bottlenecks in, or even arbitrarily related to rust.
  - wizzwizz4 5y ago
    > It’ll require some real technical skill but if you hire a real hacker you can pull it off. I do have a project a bit like that, but I'm not using Rust for it. I was trying to make my own language (like Rust, but more powerful and also smaller), but I'm probably just going to use a modified (safer) C. If I were to write it in Rust, I'd have to compile it in the first place… and if I could do that easily, I would simply use Rust.
    - qualudeheart 5y ago
      You have a project involving self resizing code? That’s awesome! Can you explain it more?
  - mlang23 5y ago
    Do people still know about upx these days? However, I think executable compression is besides the point of OP. Around 18 years ago, I was going through the codebase of a program I maintained as a Debian package, and as a udeb for the installer. Back then, I was trying to make it small enough to fit on the first floppy. I learnt about unnecessarily large datatypes in structs, packing, padding and alignment, and that adding "static" to module-local functions and data can really do things to the binary size. These times are over. Nobody cares about binary sizes anymore, the main argument against doing so is "we cant be bothered, we need to innovate."
- jhgb 5y ago
  A ramdisk wouldn't help there?
  - wizzwizz4 5y ago
    Not with 4GB of RAM. I already have to close Firefox to compile non-trivial programs.
    - jhgb 5y ago
      Ooops. 48GB here, regretting that I didn't get 64GB. (My excuse is that I needed it for osm2pgrouting which ate up to 90GB of paged memory on a country-sized input file. That hurt a lot.)
      - wizzwizz4 5y ago
        I have never been gladder that I abandoned my OSM data-processing project before I got that far. (I was planning on processing multiple country-sized input files for their road networks – on a friend's computer, but it only had 16GB, so that would be a lot of paging.)
        jhgb 5y ago
        I then jumped ship to OSRM, which did the same job in ~3GB of memory, AND several times faster, AND didn't return spurious routing results afterwards. (I was getting some routes with "hyperspace jumps" between points in the road network that weren't connected, and due to previous issues with memory I just decided to stop trying, so I didn't investigate the cause of those jumps.) So if you'll ever decide to do that again, just use OSRM. It "just works" (at least in my experience).
CommieBobDole 5y ago
Storage is indeed very cheap, but so are CPU cycles, for the same reason.

wizzwizz4 5y ago

People keep saying that. I have 1.8 GiB available for all my build files, and that's only because I keep deleting the build files of my other projects (meaning they have to be recompiled whenever I go back to them). Storage matters for me. At least the prices are almost normal again, now that Chia's over.

qualudeheart 5y ago
Couldn’t you get 4x that much from a $3 usb stick? You could also have self modifying code such that the size of the binary automatically changes as needed. If you ship a lisp interpreter instead of rust, you can have the interpreter recode itself and any lisp files to a smaller size. You’d just implement a compression algorithm that preserves the functionality of the code compressed. I think you could do that with rust too with a self compiling binary. It’ll require some real technical skill but if you hire a real hacker you can pull it off. My cousin his solution for the competitive programming contest had something like that.
- ithkuil 5y ago
  I doubt a $3 USB stick would perform decently enough to not become a bottleneck in rust compile and link times.
  - bbarnett 5y ago
    There are no bottlenecks in, or even arbitrarily related to rust.
- wizzwizz4 5y ago
  > It’ll require some real technical skill but if you hire a real hacker you can pull it off. I do have a project a bit like that, but I'm not using Rust for it. I was trying to make my own language (like Rust, but more powerful and also smaller), but I'm probably just going to use a modified (safer) C. If I were to write it in Rust, I'd have to compile it in the first place… and if I could do that easily, I would simply use Rust.
  - qualudeheart 5y ago
    You have a project involving self resizing code? That’s awesome! Can you explain it more?
- mlang23 5y ago
  Do people still know about upx these days? However, I think executable compression is besides the point of OP. Around 18 years ago, I was going through the codebase of a program I maintained as a Debian package, and as a udeb for the installer. Back then, I was trying to make it small enough to fit on the first floppy. I learnt about unnecessarily large datatypes in structs, packing, padding and alignment, and that adding "static" to module-local functions and data can really do things to the binary size. These times are over. Nobody cares about binary sizes anymore, the main argument against doing so is "we cant be bothered, we need to innovate."
jhgb 5y ago
A ramdisk wouldn't help there?
- wizzwizz4 5y ago
  Not with 4GB of RAM. I already have to close Firefox to compile non-trivial programs.
  - jhgb 5y ago
    Ooops. 48GB here, regretting that I didn't get 64GB. (My excuse is that I needed it for osm2pgrouting which ate up to 90GB of paged memory on a country-sized input file. That hurt a lot.)
    - wizzwizz4 5y ago
      I have never been gladder that I abandoned my OSM data-processing project before I got that far. (I was planning on processing multiple country-sized input files for their road networks – on a friend's computer, but it only had 16GB, so that would be a lot of paging.)
      - jhgb 5y ago
        I then jumped ship to OSRM, which did the same job in ~3GB of memory, AND several times faster, AND didn't return spurious routing results afterwards. (I was getting some routes with "hyperspace jumps" between points in the road network that weren't connected, and due to previous issues with memory I just decided to stop trying, so I didn't investigate the cause of those jumps.) So if you'll ever decide to do that again, just use OSRM. It "just works" (at least in my experience).

CommieBobDole 5y ago

Storage is indeed very cheap, but so are CPU cycles, for the same reason.