From mboxrd@z Thu Jan 1 00:00:00 1970 References: <20130323100519.GA3980@polynum.com> <19750d1b50c54941f031f57dc4be456e@proxima.alt.za> <5099C9E8-C6E8-4B6B-A609-B5BDCA6C332F@lsub.org> <5C91EC08-2559-4DA8-B6F3-9293747EEFE8@gmail.com> <20130323173739.GA3314@polynum.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=utf-8 Message-Id: <9AA57655-9104-4AFC-80D3-88EA3B9D1E37@lsub.org> Content-Transfer-Encoding: quoted-printable From: Francisco J Ballesteros Date: Sun, 24 Mar 2013 09:49:20 +0100 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] gcc not an option for Plan9 Topicbox-Message-UUID: 32572b38-ead8-11e9-9d60-3106f5b1d025 andrey, I agreed the language is nice and that's why I also use it.=20 I just pointed out that binaries are one order of magnitude larger, as=20 you just proved.=20 perhaps I shouldn't have raised this.=20 I didn't want to bother anyone.=20 El Mar 24, 2013, a las 12:45 AM, andrey mirtchovski e= scribi=C3=B3: >> If you want real programs which are bigger that I (we) actually use that w= ill >> be (much) bigger in go: >>=20 >> ls, cp rm mv cat acid, I can go on. >>=20 >> Small programs are useful and important. >=20 > here's a representative set. the programs are identical in behaviour > and arguments to the Plan 9 set. the size is as reported by du, in > kilobytes: >=20 > 1456 ./date/date > 1460 ./cat/cat > 1564 ./cleanname/cleanname > 1564 ./tee/tee > 1736 ./echo/echo > 1764 ./cp/cp > 1772 ./uniq/uniq > 1780 ./cmp/cmp > 1780 ./freq/freq > 1780 ./wc/wc > 1792 ./comm/comm >=20 >> binaries are bigger and for example replacing the minimal sets of command= s of >> the system, this can make the >> minimal system at least 5 times bigger easy. >=20 > if that was a real issue you were trying to solve there are things you > can do to help yourself. most notably sticking everything in a single > binary and invoking the right function based on your argv0. it took me > less than 15 minutes to convert the above code to work as a single > binary and most of that was in handling clashing flags (it would've > been a non-issue if I had used flagsets when writing the original > programs). size at the very end: >=20 > $ date > test.txt > $ ln -s $GOPATH/bin/all cat > $ ln -s $GOPATH/bin/all wc > $ ./cat test.txt > Sat Mar 23 17:32:42 MDT 2013 > $ ./wc test.txt > 1 6 29 test.txt > $ du -k $GOPATH/bin/all > 1888 /Users/andrey/bin/all >=20 > the size of the original binaries on plan9 is 588k. what was a factor > of 30 is now a factor of 3. all tests still pass and it took less time > to complete than writing this email. >=20 > there's an even better solution, but it won't work on plan9 because > the go tool is slow there :)