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,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.megapath.net!news.megapath.net.POSTED!not-for-mail NNTP-Posting-Date: Wed, 28 Jul 2004 19:52:56 -0500 From: "Randy Brukardt" Newsgroups: comp.lang.ada References: <40f6bf21@dnews.tpgi.com.au> <40fb8c00$1_1@baen1673807.greenlnk.net> Subject: Re: reading a text file into a string Date: Wed, 28 Jul 2004 19:53:33 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Message-ID: NNTP-Posting-Host: 64.32.209.38 X-Trace: sv3-hgKQOov38UHqbaRmErfk190i2eII0j6a0o03RlttNqS1M0RuSlsnxHRpAirxrfj03ngh4fd5TUgaLiG!Jvfo6s4v4MkXfomoFGeo2UHkUWZCXzDKM6U3k+NOs00449NG5l0rUnT/WuXVjQlD5pGKT5TTlr9H X-Complaints-To: abuse@megapath.net X-DMCA-Complaints-To: abuse@megapath.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.3.13 Xref: g2news1.google.com comp.lang.ada:2449 Date: 2004-07-28T19:53:33-05:00 List-Id: "Nick Roberts" wrote in message news:opsbspb4bep4pfvb@bram-2... ... > >> > I don't know precisely why they recommended that, but I don't > >> > claim to know better than Intel! > >> > >> Well, I don't think they ever did; maybe you need to do some > >> re-reading. > > > > That's it. That's the third time in the last few months that > > you've essentially called me a liar - or senile - and I'm done > > taking it without comment. Either we're going to talk without > > personal attacks, or we're not going to talk at all. OK? > > Well, that comes as a bolt out of the blue, Randy. > > Let me first assure you that neither this time nor at any time in > the past have I intended to imply that were lying or to make any > personal slight against you. > > On consideration, I feel that I should not have made the remark > "maybe you need to do some re-reading", and I do truly apologise > for it. It was intended to be lighthearted and to be taken in a > friendly manner. Usenet is a medium given to stripping away all > the extra cues that a different medium (such as a telephone call) > would convey that help to disambiguate communications. It is easy, > sometimes, to forget this, but I should have known better. For the record, I was most upset about the first part, not the second. I have no problem believing that the recommendations have changed - and you quoted some that are different (they seem rather old, but that's another story). But to say "I don't think that they ever did" recommend what I originally reported says that they *never* recommended what I remember and essentially that I was trying to mislead the conversation by saying that. Not good. Anyway, I accept your apology, and I'll try to be less sensitive next time. ... > > How do you undo this when you leave the scope? You have to > > save the ESP value somewhere and restore it to do that, and > > *that* is an extra overhead. > > Well, I don't think so. The usual thing is to do is to save > ESP in the EBP register at stack frame creation, and restore it > from EBP just prior to return. There is, I grant, a need for a > little care, in that one would (I guess) need to do the stack > alignment I suggested before pushing anything onto the stack > that you might want to pop off it afterwards. Otherwise, I > think the 'and' instruction is the only extra thing required. I realize that we're weird here, but EBP points at the bottom of the stack frame in Janus/Ada; that gives us positive stack offsets. We had a lot of trouble with negative ones in the early days, and I just gave up on that. In any case, we spend quite a bit of effort trying to avoid setting EBP at all. For small leaf subprograms, the overhead of writing then restoring EBP can be a significant percentage of the cost of the whole routine. Thus, we get rid of the stack frame with an Add, and that leaves us with no obvious way to do an alignment. (Alignment is not reflected in our intermediate code, as that is supposed to be done by the data layout earlier in the compiler. So it's either all or nothing - it has to be done for all stack frames or not supported; I suspect many other compilers are similar.) Anyway, my opinion these days is that spending a lot of effort making something run 2% faster is wasted effort. You're always better off changing to a different way of solving the problem. The most recent instance was in my web log analyzer. It was running too slow on the AdaIC site's logs, and I wasted a lot of time trying to improve it. But replacing the binary lookups (log N, N being around 200,000) by a hashed lookup (very similar to switching from Sorted _Sets to Hashed_Maps in the Containers library) improved the speed by a factor of 5 (a result I didn't expect, because I had to use an expensive hash function -- all of the cheap ones I tried didn't work well on the actual data -- and log N wasn't that large -- between 12 and 19 on the data I tested with). Moral: make sure you've exhausted algorithmic improvements before even thinking about squeezing a few extra percent out of the code. And when you think you've exhaused algorithmic improvements, try again, because sometimes non-obvious things work! (We hadn't originally used a hash because of the need to write sorted reports. But it turned out that using a hash and a quicksort on the report was faster than keeping the data sorted.) Randy. > I vaguely remember that I have actually used this technique, > but a long time ago. > > > > > ... > >> > Similarly, existing Windows linkers don't support > >> > alignments beyond 16 to my knowledge -- so again you would > >> > have to do something at runtime with a penalty. > >> > >> But then the point is that the linkers /should/ support other > >> alignments. It's no good saying "Oh, we can't do that because > >> the linker doesn't support it!" Obviously, you need to change > >> the linker. It's called not letting the tail wag the dog :-) > > > > You know as well I as do that you don't get to change your > > target system to your whim. You have to use the tools that > > users want to use, such as the Microsoft linker. > > > > But even if you wrote your own linker, I don't think that there > > is any guarentee of alignment in the loading of the parts of an > > .EXE file. So I don't know if any alignment that you have in > > your linker would actually be preserved. > > I can't quickly find information on the subject, but I rather > suspect that an .EXE or .DLL is likely to be loaded page > aligned. That would mean alignments up to the page size would > be safe. > > Also, I think possibly we're arguing at crossed purposes on > this point. I'm only arging that linkers and execution > environments /should/ support cache-line alignments. I accept > that many do not, in practice, and I accept that a compiler > targetting such a linker or environment cannot be expected > to so so either. I think this is how Robert's original comment > can be construed, also. > > -- > Nick Roberts