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: Thu, 22 Jul 2004 17:34:21 -0500 Date: Thu, 22 Jul 2004 18:34:20 -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: 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-nJGRlz4J1fv8ekbcBJy6O3WsXBwGEXBNSCyNyhm03w5N41WzMoa5R8+QdMgiQ+poqHX/wpg1iTcHDlD!YtMWULsiKG8sEvqOaLIVQgeNQ+MGcoaQUVclgOIfRIItCoCLswm1M1Z+s/+w1Q== 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:2352 Date: 2004-07-22T18:34:20-04:00 List-Id: Randy Brukardt wrote: > "Robert I. Eachus" wrote in message > news:nM-dnegXLbmdK2DdRVn-hQ@comcast.com... > ... > >>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. > > > What's an object allocated at link time? I don't know of any such thing (you > can allocate segments at link time, but the number of those is quite > limited). Um, a compiler can (but most Ada compilers don't) allocate objects in library packages on the heap, in static storage, or even in code segments. But you are right that this is very definitely not the usual in x86 compilers and environments. > Similarly, do you know of *any* compiler for *any* language that supports > 256 byte alignment? I don't, at least on Windows. You are probably correct with regards to Windows. I do know of compilers that do support such alignments, but only for supercomputers. With the rate at which x86 chips are taking over the supercomputer market though, I'll have to check. But the real reason I posted all this is that Ada compilers for x86, including x86 Windows SHOULD support this alignment, even if it is relatively painful to do so. (Painful in terms of gaps in the stack, or doing the extra effort required when allocating space on the heap.) The case of a String buffer when reading files is a perfect case in point. If the buffer is 128 (AMD) or 256 (Intel) byte aligned when reading from a memory-mapped file, you will reduce the number of cache line misses during the execution of the program. (If the buffer is in a single cache line, then that line will stay resident in L1 cache. If the buffer is distributed over two (Intel) or more (AMD) cache lines, the lines that are not referenced every line may get paged out. This is much more likely on an Intel CPU, and is potentially much more painful when it happens. The 'exclusive' cache feature on AMD processors means that if the line gets replaced in L1, it will be copied back to L2. So it takes two cache line replacements to push the line out of cache entirely. With Intel the line can get moved to the much smaller L1 cache, then overwritten in L2 cache. When it is overwritten in L1, then it will have to be pulled in from main memory next time around. We may only be talking say, a 2 or 3% slowdown from such a misaligned text buffer. Not really worth going to all the trouble to align buffers for casual programming. But when I am working on a linear algebra code, I do go to the effort where it does pay off. (For example, if you represent the basis in a linear programming subroutine as a matrix and a series of pivots, it makes for a significant improvement in performance to start the pivot rows on the correct cache line boundary.) -- 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