 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <slr### [at] fwi com> , ron### [at] povrayorg (Ron
Parker) wrote:
> Unfortunately, without the needle to push the dust out of the way,
> they also sound much worse.
Mount a small fan in fron of the optical reader ;-)
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3A777C01.EFB12667@pacbell.net> , Ken <tyl### [at] pacbellnet>
wrote:
> As someone who owns an Athlon machine I consider that a silly question :)
>
> Besides there are now more than just one person using this CPU. Lots of
> people are buying them.
Yes, but who handles all the support coming from more than _one_ version?
If you offer something like ten versions optimised for the ten (or more) x86
processors in common use today, and half of them are slow on another four
and do not run on the other five of the ten processors, you will have a lot
of confused users. Remember that not everybody knows what processor they
use - why should a user know?
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3a77e52a@news.povray.org> , Warp <war### [at] tagpovrayorg> wrote:
> I have done that, but didn't find anything easy to optimize.
>
> Perhaps I'll try it again some day.
>
> : P.S.: I once read some C code and asked myself who had been so idiot to
> : write it that way. After a few seconds, I remebered. It was me.... six
> : months before.
>
> This happens probably to almost everyone. In a half year you learn so much
> that you would have done the same code much better if you had known.
You are right, this happens to me all the time, too. Not to mention that
the quality of the code usually increases with the understanding of the
problem, which is usually better after one has worked on the problem for a
few month.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Yes, but who handles all the support coming from more than _one_ version?
> If you offer something like ten versions optimised for the ten (or more)
x86
> processors in common use today, and half of them are slow on another four
> and do not run on the other five of the ten processors, you will have a
lot
> of confused users. Remember that not everybody knows what processor they
> use - why should a user know?
>
>
> Thorsten
That is realy no problem! The program can find out which CPU is there and
load a DLL which renders the scene file. Or you can find out the processor
at instalation time and install the right exe.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 31 Jan 2001 15:19:24 +0100, Daniel Jungmann wrote:
>That is realy no problem! The program can find out which CPU is there and
>load a DLL which renders the scene file. Or you can find out the processor
>at instalation time and install the right exe.
What's a DLL? One of our primary goals is to keep the core code platform
independent. This doesn't bode well for big piles of #ifdefs and such,
and it pretty much nixes any idea of using dynamically loaded code, which
doesn't exist on every platform we support.
The detect-CPU-at-install method doesn't work if you upgrade your computer
a piece at a time (frex, the computer I have now is a K6-2/350, but three
months ago it was a K6/233, and a year or two before that it was a 486SLC2/66.
The hard drive has also been replaced, but not at the same time as either
of the processors.)
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3a781e9c@news.povray.org> , "Daniel Jungmann" <DSJ### [at] gmxnet>
wrote:
> That is realy no problem! The program can find out which CPU is there and
> load a DLL which renders the scene file.
So people would have to download 1.5*10 + 5 = 20 MB of files?
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> So people would have to download 1.5*10 + 5 = 20 MB of files?
1. You can compress these files.
2. You can choose wich you need for your processor.
3. PovRay would check every time you start the processor and it something
had changed it would tell you where you can get the "correct" version for
your processor.
That is realy no problem!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2001-01-30 15:04, Daniel Jungmann <DSJ### [at] gmxnet> wrote:
>> It is also a compiler problem. You didn't say which compiler you used or
>> how you got it to produce 3D!Now code. Essentially there are 3
>> possibilities:
>>
>> 1) You have a compiler which can generate 3D!Code out of "natural" C
>> code.
>>
>> 2) You have a compiler which can generate 3D!Now code, if the C code
>> follows a certain pattern.
>>
>> 3) You used inline assembly.
>
>The question is not 1, 2 or 3, the question is for answer 3 you need not
>verry mucht time, but answer 1 is also possible, but verry much more work!
>
I have trouble interpreting this sentence. Can you repeat in German? :-)
If I understood it correctly, quite the reverse is true.
For possibility 1 you need only the time to recompile the source - a
few minutes. (Unless you have to write the compiler first, but I didn't
think you did that).
For possibility 3 you need to analyse povray source code to see where
you can speed it up and replace C code by inline assembly. That's quite
a bit of work (you wrote something about 30 hours, IIRC), it must be
repeated for every CPU type (and possibly compiler), and everybody else
who is going to maintain that code in the future will have more work,
too.
hp
--
_ | Peter J. Holzer | All Linux applications run on Solaris,
|_|_) | Sysadmin WSR | which is our implementation of Linux.
| | | hjp### [at] wsracat |
__/ | http://www.hjp.at/ | -- Scott McNealy, Dec. 2000
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2001-01-31 15:15, Thorsten Froehlich <tho### [at] trfde> wrote:
>In article <3a781e9c@news.povray.org> , "Daniel Jungmann" <DSJ### [at] gmxnet>
>wrote:
>
>> That is realy no problem! The program can find out which CPU is there and
>> load a DLL which renders the scene file.
>
>So people would have to download 1.5*10 + 5 = 20 MB of files?
How did you compute that?
The code segment of povray for linux/intel is about 550 kB. Following
the rule of thumb that 90 percent of the time is spent in 10 % of the
code, a dll with the time critical routines would be about 55 kB. So for
each supported processor variant the executable package would increase
by about 55 kB.
Of course this assumes that the time critical routines can be moved to a
dll. It is possible that these code fragments are so short that function
calls (as opposed to inlining) add more overhead than can be saved by
carefully hand-crafting them in assembler.
I am also ignoring the trouble of generating and loading dlls on
different platforms since these optimizations are platform dependent
anyway.
hp
--
_ | Peter J. Holzer | All Linux applications run on Solaris,
|_|_) | Sysadmin WSR | which is our implementation of Linux.
| | | hjp### [at] wsracat |
__/ | http://www.hjp.at/ | -- Scott McNealy, Dec. 2000
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <slr### [at] tealhhjpat> ,
hjp### [at] SiKituwsracat (Peter J. Holzer) wrote:
> The code segment of povray for linux/intel is about 550 kB. Following
> the rule of thumb that 90 percent of the time is spent in 10 % of the
> code, a dll with the time critical routines would be about 55 kB. So for
> each supported processor variant the executable package would increase
> by about 55 kB.
pvengine.exe (at least the VC 6 one) is 1622016 bytes. On the Mac you get
about the same size.
> Of course this assumes that the time critical routines can be moved to a
> dll. It is possible that these code fragments are so short that function
> calls (as opposed to inlining) add more overhead than can be saved by
> carefully hand-crafting them in assembler.
The question is how much overhead does calling DLL function introduce? At
least on Macs a shared library call is done by addressing the function via a
table. In total about 10 instructions. For simple operations this would
eliminate the benefit. Plus, vector and color math are not done with
functions in POV-Ray (they are C macros). This benefit together with the
compiler optimisations that come along with it would be lost.
> I am also ignoring the trouble of generating and loading dlls on
> different platforms since these optimizations are platform dependent
> anyway.
True.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
