From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,4fbd260da735f6f4 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews.google.com!o5g2000hsb.googlegroups.com!not-for-mail From: Adam Beneschan Newsgroups: comp.lang.ada Subject: Re: Reading and writing a big file in Ada (GNAT) on Windows XP Date: 4 May 2007 13:04:34 -0700 Organization: http://groups.google.com Message-ID: <1178309074.426785.157110@o5g2000hsb.googlegroups.com> References: <0hj5339mjmond132qhbn2o01unurs61lbj@4ax.com> <1178091967.392381.282510@o5g2000hsb.googlegroups.com> <1178224048.034635.39010@l77g2000hsb.googlegroups.com> NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1178309074 26357 127.0.0.1 (4 May 2007 20:04:34 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Fri, 4 May 2007 20:04:34 +0000 (UTC) In-Reply-To: User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.7.12-1.3.1,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: o5g2000hsb.googlegroups.com; posting-host=66.126.103.122; posting-account=cw1zeQwAAABOY2vF_g6V_9cdsyY_wV9w Xref: g2news1.google.com comp.lang.ada:15538 Date: 2007-05-04T13:04:34-07:00 List-Id: On May 3, 4:01 pm, "Randy Brukardt" wrote: > The big expense in Index is the mapping set or function, not the actual > compare. Yeah, but I'd assume that a high proportion of uses of Index would use the default parameter for mapping (Maps.Identity), which an implementation should be able to test for and choose a faster implementation in that case. Which is what I assumed you did. > For Janus/Ada, I had seen a similar problem (a big deal as Index > was used to look for spam patterns), and finally special-cased a number of > common cases (no mapping, single character patterns, and so on). I also > spent a bit of time on the code generator, figuring that this sort of string > manipulation code is common enough that it might as well be generated well. > The updates helped a lot, although they don't quite generate a single > instruction such as is possible. (OTOH, Intel used to recommend avoiding the > block move and compare instructions because they fouled up the pipeline and > thus slowed the overall execution. I don't know if that is still true, but > ifi it is, there might be less benefit to hand-coded assembler than you are > thinking...) Sigh... I've been in the computer business too long. I started out with processors that execute the instruction you tell it to execute and then go to the next one, so I still tend to think in those terms, even though I now have to deal with processors that look ahead to schedule instructions and try to execute instructions in parallel and even have "branch delays" so that if you tell the computer to branch, it will sit there and not budge until you give it five more instructions, which seems WAY too much like dealing with my 8-year-old son. But yes, these days I need to be more careful about my assumptions about what kinds of machine instructions will execute the fastest. -- Adam