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,23c85e456e18d6b5 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!news.tele.dk!feed118.news.tele.dk!news.tele.dk!small.news.tele.dk!newsfeed.bahnhof.se!195.197.54.117.MISMATCH!feeder1.news.jippii.net!reader1.news.jippii.net!53ab2750!not-for-mail From: Tapio Kelloniemi Subject: Re: The Computer Language Shootout Benchmarks References: <1146668114.965364.116600@j33g2000cwa.googlegroups.com> Newsgroups: comp.lang.ada Message-ID: <4v56g.9384$0B.2009@reader1.news.jippii.net> Date: Wed, 03 May 2006 17:11:28 GMT NNTP-Posting-Host: 217.30.176.187 X-Complaints-To: newsmaster@saunalahti.com X-Trace: reader1.news.jippii.net 1146676288 217.30.176.187 (Wed, 03 May 2006 20:11:28 EEST) NNTP-Posting-Date: Wed, 03 May 2006 20:11:28 EEST Organization: Saunalahti Customer Xref: g2news2.google.com comp.lang.ada:4048 Date: 2006-05-03T17:11:28+00:00 List-Id: "Matthew Heaney" wrote: >Tapio Kelloniemi wrote: >> "Matthew Heaney" wrote: >> >And why do you assume that??? >> >> Because GNAT.[Dynamic_]HTable has been designed to be extremely efficient. > >And why do you assume that Ada.Containers.Hashed_Maps aren't also >designed to be extremely efficient? Why would the designer do it any >other way? To support some Ada features (such as controlled types) or to increase safety with additional run-time checks. This is of course how a standard library implementation must behave, but some particular hash table implemetation could drop support for controlled types and suppress all checks, if such features woudn't be required (or were considered to be too expensive). >> Note that this is just an assumption, I have not read the code of GNAT's >> HTable implementation, > >If you haven't read the sources, then how do you know? I expected that they had taken the same aggressive approach with Htables as with Tables, but diving into the code reveals that this is not the case (at least not with the Simple_Htable). However, the Static_Htable can be more efficient than Ada.Containers.Hashed_Maps, depending on the situation. Sorry for misinforming. >> it allows >> direct access to the data structure > >Again, this is a specious argument, since having access to the >underlying data structure is irrelevant. It's direct access to an >element that's important. > >The standard library provides something very close to direct access: it >allows in situ access to elements via Query_Element and Update_Element. But if we want to get every microsecond out of it, though generally we don't want to. >> and it uses realloc to resize the table. > >Well obviously this will only work if the element type isn't >controlled. So you're comparing apples to oranges, since the standard >containers must support any non-limited type, including controlled type >and discriminated types. I was considering something that could be used in the shootout tests and I think that support for controlled types is not needed there. But this is now unrelevant since GNAT.HTable does not use realloc as I thought, so the only benefit gained by using GNAT.HTable is that it reduces the number of lines of code when there is no need to include the hash table implementation in the code (LOCs are also measured in shootout). -- Tapio