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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,a3fe2aac201210c0 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!news.glorb.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local1.nntp.dca.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail NNTP-Posting-Date: Tue, 20 Jul 2004 19:17:04 -0500 Date: Tue, 20 Jul 2004 20:17:03 -0400 From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: reading a text file into a string References: <40f6bf21@dnews.tpgi.com.au> <40fb8c00$1_1@baen1673807.greenlnk.net> In-Reply-To: <40fb8c00$1_1@baen1673807.greenlnk.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: NNTP-Posting-Host: 24.147.90.114 X-Trace: sv3-4PmoBjIdEBmL90hiWhTXC754VqQDqxSVTgomX/VxfVLUU0pHZpBU3voaWSPKu9kzAI9Ln9cbaH2mbZm!oy/oXsRpBUuzZail9qm73306NyWHtohnrb5LrlHW0f8Vn9VSdxnNuxkseW5RWA== X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.1 Xref: g2news1.google.com comp.lang.ada:2296 Date: 2004-07-20T20:17:03-04:00 List-Id: Martin Dowie wrote: > Isn't there an arguement for defaulting to 250 characters/line? Can't > remember what it was off the top of my head but it is ringing a bell... There is, and it is probably worth spelling out for programmers... If you are buffering lines and want to avoid unintentional cache pressure, you should try to force buffers into a single cache line if possible. But what size to use to do that? Well first of all, Intel CPUs tend to have a 256-byte cache line. If a cache read is in progress when another read occurs, the CPU may cut the read off at 128 bytes. AMD processors (Athlon, Opteron, etc.) have 64-byte cache lines, but will normally read two lines on any memory read. So Intel asks for 256 bytes, but may take 128, and AMD asks for 128 but may take 64. So 128 or 256-bytes is a good size for objects to be fit in a single cache line. However, in Ada a String will have a descriptor associated with it. Also when a line is stored in a file, it will usually have some sort of decoration, either a length field, a line terminator, or an appended null. So what would like to do is: subtype Index is Integer range 0..250; type Buffer (Length: Index := 0) is record Contents: String(1..Length); end record; for Buffer'Alignment use 256; -- or 128 on Athlons. ;-) Language lawyer note: RM 13.3(32) says: "An implementation need not support specified Alignments that are greater than the maximum Alignment the implementation ever returns by default." This applies to subtypes, for stand-alone objects RM 13.3(35) says: "For stand-alone library-level objects of statically constrained subtypes, the implementation should support all Alignments supported by the target linker. For example, page alignment is likely to be supported for such objects, but not for subtypes." So in theory you may need to put the 'Alignment clause on buffer objects instead. GNAT however, won't even recognize those alignment clauses, which IMHO is a shame: ------------------------------------------------------ package Test_Align is subtype Index is Integer range 0..250; type Buffer (Length: Index := 0) is record Contents: String(1..Length); end record; Buff: Buffer; for Buff'Alignment use 256; end Test_Align; ------------------------------------------------------- gnatmake test_align gcc -c test_align.ads test_align.ads:10:27: largest supported alignment for "Buff" is 4 gnatmake: "test_align.ads" compilation error When the programmer can do something simple like this to improve program performance, it should be supported by all compilers. (Notice that this is an error, not a warning.) I can see not supporting the subtype case due to the (potential) requirement for either large stack frames or varying size stack frames. But for an object that can be allocated at link time, I don't see why it shouldn't be supported. -- Robert I. Eachus "The flames kindled on the Fourth of July, 1776, have spread over too much of the globe to be extinguished by the feeble engines of despotism; on the contrary, they will consume these engines and all who work them." -- Thomas Jefferson, 1821