 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Folks,
There is now a 3.7 linux beta (x86 only for now, sorry) available via the
beta download page (http://www.povray.org/beta/).
Followups to the beta group please.
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 29 Jul 2006 11:18:14 +1000, Chris Cason wrote:
> There is now a 3.7 linux beta (x86 only for now, sorry) available via the
> beta download page (http://www.povray.org/beta/).
Sweet, thanks, Chris. Downloading now - wish I still had the DP system I
had a year ago (had to give it back to work), but I'll play on my SUSE
10.1 system. :-)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson <nos### [at] nospam com> wrote:
> On Sat, 29 Jul 2006 11:18:14 +1000, Chris Cason wrote:
>
> > There is now a 3.7 linux beta (x86 only for now, sorry) available via the
> > beta download page (http://www.povray.org/beta/).
>
> Sweet, thanks, Chris. Downloading now - wish I still had the DP system I
> had a year ago (had to give it back to work), but I'll play on my SUSE
> 10.1 system. :-)
>
> Jim
hi, i know this is a little bit out of topic but i have to run a benchmark
on a linux system with povray under a dual-core system. I am currently
using povray-3.7 beta14 with suse linux 10.1. how can i use two cores? is
there a parameter?
thanks for your help!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 09 Aug 2006 07:57:58 -0400, scouti wrote:
> hi, i know this is a little bit out of topic but i have to run a benchmark
> on a linux system with povray under a dual-core system. I am currently
> using povray-3.7 beta14 with suse linux 10.1. how can i use two cores? is
> there a parameter?
> thanks for your help!
I thought my system only had one core, but in the test renders I've done
so far, it indicates two threads are being used.
Chris, does that indicate to you that my system is in fact dual core?
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scouti <nomail@nomail> wrote:
> how can i use two cores?
POV-Ray should automatically render in multithreaded mode without you
having to specify anything. Are you not seeing a considerable increase
in rendering speed (which would suggest it's rendering in one single
thread)?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson <nos### [at] nospamcom> wrote:
> Chris, does that indicate to you that my system is in fact dual core?
No, it just indicates that POV-Ray 3.7 by default uses cores*2 threads
to render.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 09 Aug 2006 15:52:12 -0400, Warp wrote:
> Jim Henderson <nos### [at] nospamcom> wrote:
>> Chris, does that indicate to you that my system is in fact dual core?
>
> No, it just indicates that POV-Ray 3.7 by default uses cores*2 threads
> to render.
Great - thanks. I wasn't aware that 3.7 used multiple threads per
processor or core; 3.6 didn't do that, did it?
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson <nos### [at] nospamcom> wrote:
> Great - thanks. I wasn't aware that 3.7 used multiple threads per
> processor or core; 3.6 didn't do that, did it?
That's the whole idea in 3.7.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 09 Aug 2006 17:04:27 -0400, Warp wrote:
> Jim Henderson <nos### [at] nospamcom> wrote:
>> Great - thanks. I wasn't aware that 3.7 used multiple threads per
>> processor or core; 3.6 didn't do that, did it?
>
> That's the whole idea in 3.7.
That's what I thought, just wanted to confirm. Thanks for that. :-)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> POV-Ray 3.7 by default uses cores*2 threads
> to render.
No, the actual default is 2 threads regardless of the number
of cpus or cores. Use the +wt command-line option or WorkThreads
INI setting to change this figure.
- NC
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Calimet <pov### [at] freefr> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 12 Aug 2006 17:56:42 -0400, Warp wrote:
> 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.
OK, no problem - just was trying to make a connection there, and wanted to
make sure I wasn't missing something. :-)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi Chris,
Would it be complicated to also provide a x86_64 Linux version for AMD ?
Thanks for good work.
Best regards,
-- François LE COAT
Author of Eureka 2.12 (2D Graph Describer, 3D Modeller)
http://eureka.atari.org
Chris Cason wrote :
> There is now a 3.7 linux beta (x86 only for now, sorry) available via t
he
> beta download page (http://www.povray.org/beta/).
>
> Followups to the beta group please.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Would it be complicated to also provide a x86_64 Linux version for AMD ?
Both x86 and x86_64 binaries will be released for the next beta.
- NC
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi Nicolas,
Nicolas Calimet wrote :
>> Would it be complicated to also provide a x86_64 Linux version for AMD
?
>
> Both x86 and x86_64 binaries will be released for the next beta.
Thanks. That's welcome.
Regards,
-- François LE COAT
Author of Eureka 2.12 (2D Graph Describer, 3D Modeller)
http://eureka.atari.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Calimet <pov### [at] freefr> wrote:
> > 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
Not to mention that a forced number of threads would eliminate the possibility
using Load Balancing clusters to cooperate. Thanks so much for making the
decision you did.
Even under windows and others, it may be useful to have an editable override in
the case of clusters. Both Windows and Mac OSX have packages to do this.
Perhaps on install it could detect the number of cpus and write it to the
application configuration file or so?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
fobbio wrote:
> Not to mention that a forced number of threads would eliminate the
> possibility
> using Load Balancing clusters to cooperate. Thanks so much for making the
> decision you did.
Nobody said anything about a *forced* number of threads. Even on Windows,
POV-Ray automatically detects the number of processors to use as a
*default* number of threads. It can always be changed if you want to.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Thanks so much for making the
> decision you did.
The default behavior has been changed since beta.25, i.e. the linux build
now assigns the number of threads as the number of cpus (cores) when detection
is possible, or 4 threads otherwise. Of course this default setting can be
overriden at the INI or command-line level.
- NC
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
