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,cd86d70d109cd9b1 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.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: Wed, 27 Dec 2006 02:57:07 -0600 From: tmoran@acm.org Newsgroups: comp.lang.ada Subject: Re: multicore-multithreading benchmarks References: <459192a7$1@news.hcs.net> X-Newsreader: Tom's custom newsreader Message-ID: Date: Wed, 27 Dec 2006 02:57:08 -0600 NNTP-Posting-Host: 67.164.83.70 X-Trace: sv3-lDjgcnYsPZhRUNm3Jh8ro8ieAqwYbP7yUpFjEsRJk678igHFMEAl/2BwRTAEOsr878jG1QF32Rr1s63!CfPZwPK3I5G/JbsK0WRzz3eON9DL/81AgSKIRpuuMpxYGfpDave6w0yUGjrAnupDW8jW8uCUzpEX!6QM+NtfXeRBdZQ== 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: g2news2.google.com comp.lang.ada:8023 Date: 2006-12-27T02:57:08-06:00 List-Id: >wondering how a programmer should go about determining the number of >cores dynamicly in order to make the best guess as to how many tasks to >break his problem into? Is there a standard Ada library that would give >some system info on the number of cores, and/or, perhaps some info on how >heavily loaded the system is (perhaps if it's already heavily loaded you >wouldn't necessarily want to try to set a task going to each core?). The Windows API call GetProcessAffinityMap tells how many CPUs/cores are available. In this (sorting) case, one could give a lower priority to one of the tasks, so if multiple cores are available, you would have multitasking, while if only one core wasn't busy, it would run the tasks sequentially - essentially the same as if they weren't multitasked. The programmer of a library routine would ideally like to be able to ask "what's the current cost of CPU cycles, RAM, and cache space" and then decide how much multitasking to do, or dynamically how to make compute/memory tradeoffs, and he'd like to write his routines to change behavior when the relative costs/scarcities change. Pending that desirable situation, I just throw up my hands, include a CPUs_To_Use parameter to the sort routine, and let someone who knows more about the particular application and its likely environment make that decision.