[M3commit] CVS Update: cm3
jay.krell at cornell.edu
Wed Sep 12 03:01:02 CEST 2012
Blech, looking at the change:
Generally size optimizations beat speed optimizations.
Those lookup tables are wasteful. And tedious to read/write
for a human, vs., the clear compact logic I put in.And as I said, division/mod by a constant is efficient, at least on 32bit systems with 64bit operations.Hm. I tried 64bit div and that was still optimized into a multiplication.The code size for that is going to be much smaller than the tables.And the affects on cache probably better too.
Generally I find "if (variable relation constant)"
easier to read than "if (constant relation variable)".
I understand the isomorphisms, but it is still more
usual to state the first.
2K is a pretty small buffer size these days.
Even 64K that I chose is small.
Yes I know I'm arguing both sides of size here.
One is code size, the other is buffer size.
Integer to text has been implemented countless times.
I suspect my way with one table is way more common
than your way with three tables.
> Date: Tue, 4 Sep 2012 16:43:27 +0000
> To: m3commit at elegosoft.com
> From: hosking at elego.de
> Subject: [M3commit] CVS Update: cm3
> CVSROOT: /usr/cvs
> Changes by: hosking at birch. 12/09/04 16:43:27
> Modified files:
> cm3/m3-sys/m3middle/src/: M3Buf.m3
> Log message:
> ChunkSize was exposed elsewhere. I agree with Jay that it may be better to be
> consistent, but leave the rest as was for efficiency.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the M3commit