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,59c52143b2a1463b X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews.google.com!w12g2000yqj.googlegroups.com!not-for-mail From: Ludovic Brenta Newsgroups: comp.lang.ada Subject: Re: How many hardware threads? Date: Mon, 12 Jul 2010 04:04:12 -0700 (PDT) Organization: http://groups.google.com Message-ID: References: <4c3a65d7$0$2405$4d3efbfe@news.sover.net> NNTP-Posting-Host: 153.98.68.197 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: posting.google.com 1278932653 5951 127.0.0.1 (12 Jul 2010 11:04:13 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 12 Jul 2010 11:04:13 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: w12g2000yqj.googlegroups.com; posting-host=153.98.68.197; posting-account=pcLQNgkAAAD9TrXkhkIgiY6-MDtJjIlC User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.4) Gecko/20100611 Firefox/3.6.4,gzip(gfe) Xref: g2news1.google.com comp.lang.ada:12336 Date: 2010-07-12T04:04:12-07:00 List-Id: I can see the value in having your program discover the number of hardware threads and starting one task on each. This value, however, is only for quick and dirty solutions. A proper, more long-term and Ada-like solution, takes into account a lot of factors: * if a single processor core provides several threads, these threads share execution units in the core, so assigning compute-intensive tasks to such threads is counter-productive; in contrast, assigning tasks that spend a lot of time waiting for external events to occur is a good idea. So, for your problem, you probably want at most one task per core, not one task per thread. * if hardware threads or cores share a common data cache, using too many tasks may result in cache contention and slow-downs. * each task will need virtual memory; possibly lots of it; and backed up by physical memory or you'll cause thrashing. So the number of tasks you can run is constrained not only by the amount of hardware threads and cores but also by the amount of physical memory you can allocate to your program. * finally, the system administrator must have the last word on how many tasks your program should use; they might choose to spare one processor core for the OS or interactive use while your program runs in the background; or they can run several programs concurrently and only allocate a fraction of the processors available to your program. So, having your program discover the number of threads (more usefully, cores) in the system should only provide a hint as to how many tasks you can start and you should also provide at least a command-line option for use by the administrator. HTH -- Ludovic Brenta.