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,e19b5ae33edaea7c X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail NNTP-Posting-Date: Thu, 15 Sep 2005 16:43:08 -0500 From: tmoran@acm.org Newsgroups: comp.lang.ada Subject: Re: puzzled re hyperthreaded performance References: X-Newsreader: Tom's custom newsreader Message-ID: Date: Thu, 15 Sep 2005 16:43:08 -0500 NNTP-Posting-Host: 24.6.102.223 X-Trace: sv3-j7Gs7iAagQ2WY2nMuRHM1r23CEFkf6nRS7C/2clF6khxHqiE63gG6bNU8sWXIKBt935PMXuVB1E9Pi/!JvvliaWxrK97RrAo/h55PP0pI9y+IsjDK82kNbQvrAifTqTnKbxl+/yng8K75FN85+4yYHSNyCZ/ 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.3.32 Xref: g2news1.google.com comp.lang.ada:4760 Date: 2005-09-15T16:43:08-05:00 List-Id: Further data: > Cache thrashing certainly comes to mind as a possible problem with > multi-threading. But the program at hand is small. I cut the problem > size so there are at most two simultaneous hash tables of Length 4091 for > 6 character Strings, which, assuming 20 bytes/entry would be 2*4000*20 or > 160K, plus 50K input String = 210K which I would think would fit well > inside the cache without thrashing. But it's still slower (about 10%) to > run multithreaded than sequential. Since this used exclusively 6 character Strings, I changed from Ada.Containers.Indefinite_Hashed_Maps to Ada.Containers.Hashed_Maps Now the parallel version runs 30% faster than the sequential one. Increasing the string (and thus hash table) size to more probably thrash the cache brings it back to parallel being slower than sequential. So part of the problem is cache thrashing, but there's still some remaining problem when using Indefinite_Hashed_Maps.