 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Calimet <pov### [at] free fr> wrote:
> No, the actual default is 2 threads regardless of the number
> of cpus or cores.
And you base this info on what?
Unless that has changed (for whatever obscure reason) or povray is not
getting the number of cpus correctly (for whatever reason), it uses
2*cores threads. Chris has said this and it works like that on my
computer.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> And you base this info on what?
The source code :-)
> Unless that has changed (for whatever obscure reason) or povray is not
> getting the number of cpus correctly (for whatever reason), it uses
> 2*cores threads.
As Thorsten mentioned in another thread, your observation is only valid
under Windows and Mac OS, not under Linux (and later under any other Unix).
Besides, having POV-Ray automatically decide how many threads it should
use depending on the number of processors/cores is not necessarily the best
choice, especially under unix environments.
- NC
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Calimet <pov### [at] freefr> wrote:
> As Thorsten mentioned in another thread, your observation is only valid
> under Windows and Mac OS, not under Linux (and later under any other Unix).
I see. I didn't know that the linux beta worked differently in this matter.
> Besides, having POV-Ray automatically decide how many threads it should
> use depending on the number of processors/cores is not necessarily the best
> choice, especially under unix environments.
I don't really understand why not. Why in windows it's ok for povray
to automatically use all available CPUs but in linux it's not?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 10 Aug 2006 12:17:13 -0400, Warp wrote:
> Why in windows it's ok for povray
> to automatically use all available CPUs but in linux it's not?
The thing that I would be led to wonder is if using /proc/cpuinfo is an
x86 thing or if that's portable for Linux across all the platforms the
kernel can be built on. Does S/390 support providing that info? PPC?
zSeries?
I don't know the answer to that - but I'd suspect if it's not portable
across platforms, that might be the reason why.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson wrote:
>> Why in windows it's ok for povray
>> to automatically use all available CPUs but in linux it's not?
>
> The thing that I would be led to wonder is if using /proc/cpuinfo is an
> x86 thing or if that's portable for Linux across all the platforms the
> kernel can be built on. Does S/390 support providing that info? PPC?
> zSeries?
It is not just Linux, it is the other Unix variants as well. Remember that
while there is a binary distributed for Linux, the same source code is
portable across most Unix variants. If you Google for it, you will quickly
find that there is no universally common way of detecting this in such a
case. Sad but true.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I don't really understand why not. Why in windows it's ok for povray
> to automatically use all available CPUs but in linux it's not?
The following points were considered when deciding to not make
the Linux version able to detect the available number of cpus/cores:
1) Portability: there is no Linux-specific version per se, but a Unix one
(for now). Making the Linux executable detect the number of cores is surely
possible, but there will be many operating systems for which we won't be able
to do the same (nor even to test whether the detection does work). Instead,
a well-defined, documented behavior for all unix-based systems is IMHO
preferred. The default of 2 threads, easily changed at the command-line
or INI level, is probably good enough for most SMP (including dual-core)
as well as non-SMP machines available nowadays.
2) Unix (Linux) machines may generally be used by several people at once:
resource sharing is a concern that should not be left alone to a single
application, especially with the upcoming multi-core machines.
3) Nothing says (yet) that 2 threads per core are always optimal.
- NC
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 10 Aug 2006 18:39:02 +0200, Thorsten Froehlich wrote:
> It is not just Linux, it is the other Unix variants as well. Remember that
> while there is a binary distributed for Linux, the same source code is
> portable across most Unix variants. If you Google for it, you will quickly
> find that there is no universally common way of detecting this in such a
> case. Sad but true.
It's easy to forget that from a POV-Ray development standpoint (at least
for me as someone who has built it on Linux but not spent a lot of time
looking at the code) that the same codebase is used for all *nix
platforms. If I had a vote, I'd say that leaving it like that would be
best, because it makes maintenance easier.
The company I work for does cross-platform development and while I'm not
one of the developers, I know that at least some of the code in question
is maintained differently for different versions of Unix and Linux (for
example, using different memory management libraries on different versions
of Unix, even) and that does increase testing complexity. While the
product in question does leverage the functinalities on different
platforms for specific reasons, I don't see that it's really necessary for
POV-Ray to do so (there'd have to be a strong use case, IMHO, to offset
the extra development and testing needs).
Of course, those of you who do the development are in a much better than
me to appreciate the maintenance issues, but I just wanted to say that
this makes sense to me. :-)
Thanks for that information.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Can someone give a good argument why precisely 2 threads is a good default
for unix povray?
Personally I would use 4. Usually there's no penalty in using more
threads (well, at least based on my experiments with winpov), so in
single-processor-single-core systems it won't matter, but in dual-core
systems the performance might be slightly better than with just 2 threads.
And since quad systems are becoming very soon, 4 threads will then
automatically use all the 4 cores (perhaps not at *maximum* efficiency,
but very close to it at least). 2 threads would not achieve this.
Computers with more than 4 CPU cores are so rare that it's not
unreasonable to expect the user to specify more threads by hand if he
happens to be rendering in one.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 12 Aug 2006 17:05:27 -0400, Warp wrote:
> Can someone give a good argument why precisely 2 threads is a good default
> for unix povray?
Well, I certainly can't; Nicholas answered this by saying that there was
no reason to believe that it was or wasn't an optimal default. I
interpret that to mean that there's an insufficient amount of data to
support that hypothesis. Given the newness of the software (certainly in
my hands), I'd tend to agree that more data is needed in order to make
that assertion.
But I don't know what that has to do with my comments, honestly. My
comments were more directed at maintainability in a cross-platform
development environment, which is something I've been exposed to in a
corporate development environment. :-)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson <nos### [at] nospamcom> wrote:
> But I don't know what that has to do with my comments
Nothing. It was just a continuation on the same subject, not really
a direct answer to your post.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
