Today most system have 2 or more processors so it make sense to add an API
to detect the number of CPUs in SDL, I’m quite sure SDL has not such a API
right now (at least grep didn’t found nothing relevant in 1.3 snapshot
headers 
)
The CPU number should include also partial CPU (hyperthreading and similar
tecnologies), and another API could be added to check if the CPU support
hyperthreading or not, it could make sense to have a consistent and flexible
api to change also the calls in SDL_cpuinfo.h to match the multicpu
enviroment:
SDL_HasHT(int cpuidx);
SDL_Has3DNow(int cpuidx);
SDL_HasAltivec(int cpuidx);
This will cover possible systems that include CPUs with different
tecnologies.
Maybe this situation is so unlikely that it doesn’t worth the effort to be
covered and the SDL_HasCPUfeature() calls should stay void…–
Bye,
Gabry
What would be the benefit of knowing the amount of cpus or cpu
features? SDL already has threads. I say let that deal with all the
nastiness involving threading.On Wed, Dec 17, 2008 at 6:39 AM, Gabriele Greco <gabriele.greco at darts.it> wrote:
Today most system have 2 or more processors so it make sense to add an API
to detect the number of CPUs in SDL, I’m quite sure SDL has not such a API
right now (at least grep didn’t found nothing relevant in 1.3 snapshot
headers )
The CPU number should include also partial CPU (hyperthreading and similar
tecnologies), and another API could be added to check if the CPU support
hyperthreading or not, it could make sense to have a consistent and flexible
api to change also the calls in SDL_cpuinfo.h to match the multicpu
enviroment:
SDL_HasHT(int cpuidx);
SDL_Has3DNow(int cpuidx);
SDL_HasAltivec(int cpuidx);
This will cover possible systems that include CPUs with different
tecnologies.
Maybe this situation is so unlikely that it doesn’t worth the effort to be
covered and the SDL_HasCPUfeature() calls should stay void…
–
Bye,
Gabry
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
What would be the benefit of knowing the amount of cpus or cpu
features? SDL already has threads. I say let that deal with all the
nastiness involving threading.
This is assuming, of course, that you’re using SDL threads and not
something else. I’d say the benefit is convenience: a few simple,
standardized API calls to give predictable results on any platform,
instead of having to look up the system API commands for each
different platform you’re developing for, and then clutter up your code
with conditionals.>----- Original Message ----
From: Pavel Dudrenov
Subject: Re: [SDL] SDL_GetCPUNum() in 1.3?
Hello !
What would be the benefit of knowing the amount of cpus or cpu
features? SDL already has threads. I say let that deal with all the
nastiness involving threading.
Additional it would be nice, if there is a GetNrCPUs function
then you should also be able to start threads on the CPUs you want
or let the OS decide it for you.
CU
What would be the benefit of knowing the amount of cpus or cpu
features? SDL already has threads. I say let that deal with all the
nastiness involving threading.
Additional it would be nice, if there is a GetNrCPUs function
then you should also be able to start threads on the CPUs you want
or let the OS decide it for you.
Getting the count of CPUs would allow to figure out how many worker
threads to run for CPU intensive processing. On platforms where we
don’t know, we can simply return -1, and that’s not much harm done (it
should probably be used as a hint rather than a hard rule anyway).
Processor affinity wouldn’t be so useful, IMHO, but hey, why not
(portability concerns?)…On Wed, Dec 17, 2008 at 12:04 PM, Torsten Giebl wrote:
–
http://pphaneuf.livejournal.com/
Hello, Pierre!
What would be the benefit of knowing the amount of cpus or cpu
features? SDL already has threads. I say let that deal with all the
nastiness involving threading.
Additional it would be nice, if there is a GetNrCPUs function
then you should also be able to start threads on the CPUs you want
or let the OS decide it for you.
PP> Getting the count of CPUs would allow to figure out how many worker
PP> threads to run for CPU intensive processing. On platforms where we
PP> don’t know, we can simply return -1, and that’s not much harm done (it
PP> should probably be used as a hint rather than a hard rule anyway).
Ok, then we need function which returns amount of active CPUs, or CPUs which
could be used by application instead of total amount. Personally I’m think
it is bad idea to have such functions related to CPUs enumeration.
With best regards, Mike Gorchak. E-mail: @Mike_Gorchak
Hello.
I don’t see why it should be a bad idea. If an application creates N
heavy duty worker threads then the OS will schedule other tasks around
them. The chances are if a user start such a heavy process (e.g. a
raytracer) they probably don’t expect great responsiveness from your
other applications in this case.
Regards,
Brian.
I can definitely see the advantage of GetCPUCount() or similar. I have
had use for such a function in the past (for the raytracer previously
alluded to =).On Thu, Dec 18, 2008 at 7:40 AM, Mike Gorchak wrote:
Ok, then we need function which returns amount of active CPUs, or CPUs which
could be used by application instead of total amount. Personally I’m think
it is bad idea to have such functions related to CPUs enumeration.
CPU affinity might also be interesting.
I don’t know how the Windows scheduler has changed through its versions, but
on
the NT 4.0 days it wasn’t that good. I had a case of the scheduler keeping
changing
the threads between CPUs, which lead to performance degradation. Our
solution at
the time was to tie a set of threads to a specific CPU.
Although I use Windows as an example, that is just because of my experience,
maybe
there are other OSs with similar issues.
Regards,
PauloOn Thu, Dec 18, 2008 at 3:29 PM, Brian <brian.ripoff at gmail.com> wrote:
Hello.
I don’t see why it should be a bad idea. If an application creates N
heavy duty worker threads then the OS will schedule other tasks around
them. The chances are if a user start such a heavy process (e.g. a
raytracer) they probably don’t expect great responsiveness from your
other applications in this case.
Regards,
Brian.
I can definitely see the advantage of GetCPUCount() or similar. I have
had use for such a function in the past (for the raytracer previously
alluded to =).
On Thu, Dec 18, 2008 at 7:40 AM, Mike Gorchak wrote:
Ok, then we need function which returns amount of active CPUs, or CPUs
which
could be used by application instead of total amount. Personally I’m
think
it is bad idea to have such functions related to CPUs enumeration.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL just allows you to create and manage threads. That’s not “dealing
with all the nastiness” in any way. SDL just wraps a suitable API, so
you don’t have to deal with the platform specific details.
Anyway, splitting work into multiple threads adds overhead, as well as
plenty of chances for the OS to introduce “hickups” in time critical
applications - and the latter gets worse with fewer CPUs/cores.
So, you may want to just do the classic single thread main loop thing
on single core machines, and use multiple threads only when there
actually is a chance of anything being parallelized. A single core
machine is “slow” enough without penalizing it with threading that
adds nothing but overhead and scheduling jitter.
//David Olofson - Programmer, Composer, Open Source Advocate
.------- http://olofson.net - Games, SDL examples -------.
| http://zeespace.net - 2.5D rendering engine |
| http://audiality.org - Music/audio engine |
| http://eel.olofson.net - Real time scripting |
’-- http://www.reologica.se - Rheology instrumentation --'On Wednesday 17 December 2008, Pavel Dudrenov wrote:
What would be the benefit of knowing the amount of cpus or cpu
features? SDL already has threads. I say let that deal with all the
nastiness involving threading.
2008/12/18 David Olofson :> On Wednesday 17 December 2008, Pavel Dudrenov wrote:
What would be the benefit of knowing the amount of cpus or cpu
features? SDL already has threads. I say let that deal with all the
nastiness involving threading.
My instinct is that if you’re getting into this level of optimisation,
then you’re going to be splitting-off into platform-specific code,
certainly when it comes to interrogating CPU features.
That said, if you’re going to provide a threading API at all, then it
should be as complete as need-be for most tasks. The problem with this
statement, is that if you expand it to be ‘complete’ it will simply
end up being a re-implementation of pthreads (or something so similar
as to make no difference).
If adding APIs, then perhaps these would cover what you need:
SDL_GetThreadUnitCount(); // To cover HyperThreading and Cell SPUs vs.
true multi-cpu.
SDL_GetThreadAttributes(SDL_thread_attrib*); // Inspired by pthreads;
Simple, flexible.
SDL_SetThreadAttributes(SDL_thread_attrib*); // Use for setting
priority & affinity or whatever else as CPU technology advances…
As I said earlier, I feel that providing APIs to interrogate processor
type & features (beyond endianness), goes against the spirit of SDL.
Eddy
Anyway, splitting work into multiple threads adds overhead, as well as
plenty of chances for the OS to introduce “hickups” in time critical
applications - and the latter gets worse with fewer CPUs/cores.
So, you may want to just do the classic single thread main loop thing
on single core machines, and use multiple threads only when there
actually is a chance of anything being parallelized. A single core
machine is “slow” enough without penalizing it with threading that
adds nothing but overhead and scheduling jitter.
What I’d recommend is something along just that, a very simple wrapper
around sysconf(_SC_NPROCESSORS_ONLN), so that you get just one number
to give you an idea whether you are on a single processor machine, a
dual-core machine, or one of those Mac Pro with dual quad-core CPUs
with 8 executions units (the new one will have hyper-threading too!).
I think it’s fine if you use two worker threads on a single-core
hyper-threaded CPU (it won’t be really twice as fast, but it’ll be a
bit faster than one thread, and it shouldn’t cause too much harm), you
just want to avoid silly situations like a single thread on those big
Mac Pro, or 8 threads on a single plain CPU.
You just want to be in the general ballpark, using enough without
overloading by too much, and let the OS figure out the details. The
important bit is treating it as a hint, so you could provide a
configuration file or console option to override it. If it gives -1,
you just use 1 or something.On Thu, Dec 18, 2008 at 9:53 AM, David Olofson wrote:
–
http://pphaneuf.livejournal.com/
Hi,
benchmarking is useful for detection a good number of threads or
processes to use. With pygame (SDL python binding) we use a short
benchmark function for figuring out the number of worker threads.
We find it works better, as given tasks run at different speeds.
Especially with things like hyper threading providing ‘fake’ cpus.
Unknown platforms are then also supported, without having to figure
out platform specific #cpu detection calls.
Another good thing to work out is number of worker threads for IO, and
keep those worker threads separate from cpu using threads. As IO
threads can be blocked easily – meaning you need more cpu threads.
cu,On Thu, Dec 18, 2008 at 4:26 AM, Pierre Phaneuf wrote:
On Wed, Dec 17, 2008 at 12:04 PM, Torsten Giebl wrote:
What would be the benefit of knowing the amount of cpus or cpu
features? SDL already has threads. I say let that deal with all the
nastiness involving threading.
Additional it would be nice, if there is a GetNrCPUs function
then you should also be able to start threads on the CPUs you want
or let the OS decide it for you.
Getting the count of CPUs would allow to figure out how many worker
threads to run for CPU intensive processing. On platforms where we
don’t know, we can simply return -1, and that’s not much harm done (it
should probably be used as a hint rather than a hard rule anyway).
Processor affinity wouldn’t be so useful, IMHO, but hey, why not
(portability concerns?)…
–
http://pphaneuf.livejournal.com/
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org