On 23 Mar 2004 05:51:36 -0500, Warp <war### [at] tagpovrayorg> wrote:
> andrel <a_l### [at] hotmailcom> wrote:
>> Wasn't that because they have to convert integer to double, do the
>> arithmetic and convert back?
>
>   That would be a quite stupid way of doing it, so I would be quite 
> surprised
> if it indeed was so.
>


That is, in fact, the way Pentium4 processors do integer multiplication.
It has little to do with stupidity, and everything to do with saving space 
on the die.

___
FE

Post a reply to this message

In article <opr5brv9e1zjc5hb@news.povray.org> , Fredrik Eriksson 
<noo### [at] nowherecom>  wrote:

> That is, in fact, the way Pentium4 processors do integer multiplication.

This is plain wrong. Integers are not converted to floating-point numbers.
They simply used the same multiplier hardware.

> It has little to do with stupidity, and everything to do with saving space
> on the die.

While in the first Pentium 4 processors the complex integer unit and the
floating-point unit did indeed share the multiplier hardware, this is no
longer the case in current processors of the Pentium 4 generation.  Sharing
the multiplier unit causes serious contention problems, and it definitely
cannot have been the preferred solution, only one Intel had to use until it
could afford an even larger die.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

On Tue, 23 Mar 2004 18:37:01 +0100, Thorsten Froehlich <tho### [at] trfde> 
wrote:
> In article <opr5brv9e1zjc5hb@news.povray.org> , Fredrik Eriksson
> <noo### [at] nowherecom>  wrote:
>
>> That is, in fact, the way Pentium4 processors do integer multiplication.
>
> This is plain wrong. Integers are not converted to floating-point 
> numbers.
> They simply used the same multiplier hardware.

Which, in reality, is virtually the same thing, and has the same effect:
Integer multiplies are slower than FP multiplies.
Even if the data is not actually converted, it still needs to be moved
back and forth.
Strictly speaking though, you are correct.


>> It has little to do with stupidity, and everything to do with saving 
>> space
>> on the die.
>
> While in the first Pentium 4 processors the complex integer unit and the
> floating-point unit did indeed share the multiplier hardware, this is no
> longer the case in current processors of the Pentium 4 generation.

True. An integer multiplier (along with some other goodies) was
introduced with Prescott.
Northwoods are still being sold though, and are available at the same
frequencies (and almost the same price) as Prescotts.

Nitpick: Not only the first, but also the second generation of P4s had
this "problem".


> Sharing
> the multiplier unit causes serious contention problems, and it definitely
> cannot have been the preferred solution, only one Intel had to use until 
> it could afford an even larger die.

Actually, they decreased the die size. The number of transistors was more
than doubled however.



This is getting awfully off-topic...

---
FE

Post a reply to this message

In article <opr5b0xzcvzjc5hb@news.povray.org> , Fredrik Eriksson 
<noo### [at] nowherecom>  wrote:

> Integer multiplies are slower than FP multiplies.

No, they aren't in general.  It all depends on the number of bits you
multiply (well, not really as an multiplication can be fully pipelined so
"only" latency increases), and thus a 32 bit integer multiplication will be
faster than the multiplications needed to handle 64 bit floats.

Anyway, you are right, we are a bit off-topic :-)

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thank you for clarifying what I already meant. 
I didn't mean for XML to be used to code directly a scene, but merely as 
an interim format which is easier to convert than plain povray. About any 
program that converts from povray, only goes up to version 2.2, before 
programming directives were added.

This always baffled me because it doesn't really look all that difficult 
to just recognize the directives and unroll the loops. in case of 
presence of a clock variable, you can generate a new file for each frame. 


As for how difficult xml is to parse, well, it doesn't look nearly as 
difficult to parse as the povray SDL. Once an XML parser is written, I 
have no idea why anyone would waste time writing it again and again and 
again for each project. Why not just use Libxml or something like that? 
Then all that happens is you read in an xml file, and you can then access 
the data in it through an object. That sounds pretty easy to me.

But of course, I may be wrong on some of those points due to lack of 
direct experience. 

something else that had me sort of interested is this note
http://www.w3.org/1999/06/NOTE-wbxml-19990624/

describing a binary format that could be derived from XML. In this case 
it's specifically meant to be applied to cell phones and other low 
powered platforms, but I see no reason why it couldn't be used to save 
parse time in other applications.  Maybe not this precise format, but 
maybe some similar heirarchal binary structure. I also liked the 
suggestion of compiling into opcodes for a vm, though that does sound a 
bit much for a 3x patch.

Though, I do see a lot of the points brought up, and see how using XML 
may not be the best solution.



> On 19 Mar 2004 18:15:39 -0500, Breton Slivka <Zen### [at] ZenPsychocom>
> wrote:
> 
>>So, I know that there's been much talk about using XML for povray
>>scene description language, and a lot of sunk in povray purists will
>>have none of it!
> 
> Since I am the one to blame for the latest bringing up the issue, I
> feel I should comment.
> 
> XML is definitely unsuitable for POV-Ray scene description. Most
> people hand-code and the overhead of XML is a needless pain in the
> behind. That's pretty much what most comments boil down to and my
> personal opinion follows the same route.
> 
> However, ...
> 
>>This would also bring the advantages that XML brings, of easy 
>>portability, parsing, and flexibility of presentation, eliminating the
>>difficulties involved in creating alternative rendering engines for
>>quick preview of povray scenes. 
> 
> ...I personally believe XML might be worth a try (unofficially) as a
> means to export already parsed POV-Ray scenes (prior to rendering) for
> the purpose of converting to other formats -- at least the parts that
> make sense. Surely it is not possible to convert the general POV-Ray
> scene because basically everything is procedural - 99% of the
> textures, and quite a lot of the objects (isos, julias, blobs to some
> extent etc.) But there are definitely cases where one can benefit a
> lot by some interoperation between POV and other packages, for example
> by generating a city in POV using Chris Colefax' macros, then render
> it in Terragen or even Radiance for the skies or lighting,
> respectively.
> 
>>Suppose then that a patch in povray would allow the automatic
>>translation between these 3 formats, and the direct parsing of the
>>formats into internal tokens. 
> 
> In any case if one decides to try to implement something along these
> lines, it should be in an unofficial version. First of all, the next
> version of POV (as of current development plans 4.0, release date as
> usually unknown :) ) plans some major rewrite. Who knows what state
> XML will be in by then? It might not make sense at all to use it
> because it might be practically dead by the time 4.0 is out.
> 
>>Anyways, I'd be interested in hearing why this is a stupid idea.
> 
> I don't think it's a stupid idea, but definitely one that needs a lot
> of thought and planning to be taken seriously.
> 
> 
> Peter Popov ICQ : 15002700
> Personal e-mail : pet### [at] vipbg
> TAG      e-mail : pet### [at] tagpovrayorg
>

Post a reply to this message

On Tue, 23 Mar 2004 22:24:46 +0100, Thorsten Froehlich <tho### [at] trfde> 
wrote:
> In article <opr5b0xzcvzjc5hb@news.povray.org> , Fredrik Eriksson
> <noo### [at] nowherecom>  wrote:
>> Integer multiplies are slower than FP multiplies.
>
> No, they aren't in general.  It all depends on the number of bits you
> multiply (well, not really as an multiplication can be fully pipelined so
> "only" latency increases), and thus a 32 bit integer multiplication will 
> be faster than the multiplications needed to handle 64 bit floats.

I'm not so sure.
Without any dependencies (i.e. we ignore latency), IMUL has a throughput
of either 3 or 5 (depending on the instruction form). FMUL has a throughput
of 2, making it the winnner here.
Taking dependencies into account, IMUL has a latency of 14-18 (again,
depending on instruction form). The latency of FMUL is 7.
Note that this is regardless of operand size. Only one form of IMUL is
listed as having variable latency: 15-18 for the implicit-operand form.

Integer multiplies simply have horrible performance on pre-Prescott P4s.


For those readers who are unfamiliar with the terminology used:
- Throughput is how many cycles it takes before another, similar 
instruction
can start executing.
- Latency is how many cycles it takes before the result of the operation
becomes available (i.e. the instruction completes).



> Anyway, you are right, we are a bit off-topic :-)

Then let's get back on topic...

How do the changes from Northwood to Prescott affect the performance of
POV-Ray?

First, check out http://www.anandtech.com/cpu/showdoc.html?i=1956&p=22
It shows Northwood beating Prescott when rendering with 3DSMax and
Lightwave, even with a handicap of 0.2 GHz.

Looking through the instruction timings, I see only a few instructions
being "faster" in Prescott: integer multiplies and bitwise shifts/rotates,
none of which (I assume) are significant for POV-Ray's performance.
All other instructions are either the same or slower, in some cases
a lot slower.
FMUL is a little slower (latency 8 instead of 7) with equal throughput.
Double precision FDIV is also slower, both in latency and throughput
(40 from 38).
FSQRT has the exact same timings as FDIV.
The corresponding SSE2 instructions have suffered the same fate,
i.e. latencies slightly increased, throughput the same or increased.

This all suggests that POV-Ray "suffers" from the changes in Prescott.
I very much doubt (and the link above strenghtens this doubt) that the
increased L2 cache size can make up for slower instructions.


Of course, this will all become moot once Prescott reaches 4 GHz and
above...


---
FE (who promises to try not to drift so off-topic in the future)

Post a reply to this message

In article <Xns94B59926AB1ABZenZenPsychocom@203.29.75.35>, 
Zen### [at] ZenPsychocom says...
> As for how difficult xml is to parse, well, it doesn't look nearly as 
> difficult to parse as the povray SDL. Once an XML parser is written, I 
> have no idea why anyone would waste time writing it again and again and 
> again for each project.

Actually that would be a misconception. Yes, XML parsers exist, however 
on the most basic level you get something like:

<...> = start tag.
</...> = end tag.
... = ... - attribute.

The specific nature of 'each' individual tag, which tags can or should be 
nested inside other tags, what attributes are actually valid, etc. must 
all be implemented by second level of the parser that *you* have to 
create. Most implementations of XML are all more or less used for the 
web, it is thus fairly trivial to add a few extra tags and some new 
attributes to it, but for something like POV-Ray you would be have to 
implement a completely unique set of tags and attributes. The parser can 
read those out and pass them to your code to decode, but you still end up 
designing your own parser anyway to make sure everything is correct and 
store the objects internally. XML only provides a framework that makes it 
easier for people to identify when related attributes are part of a 
single object and the pre-parser needs to only start and stop the *real* 
parser when the start and end tags appear. It can't describe or provide 
any way for a program to know what to do with any of that information, 
unless it knows what the attributes and sub-tags actually mean.

The fact is that looked at in those terms something like:

box {<-1,-1,-1>,<1,1,1> pigment{color rgb 1}}

becomes:

<box>
  <corners>
    corner1 = -1, -1, -1
    corner2 = 1,1,1
  </corners>
  <pigment>
    <color>
       rgb = 1
    </color>
  </pigment>
</box>

or something like that. All you really end up doing is replacing 'box {' 
or '}' with <box> and </box>, etc. The pre-parser and all the underlying 
code to figure out how to store and use this information is almost 100% 
identical, but the pre-parser that has to decide if/when a box or other 
item starts and ends just ends up reading more characters. The result is 
not any better than the original syntax. In fact, it royally messes up 
vectors, since XML and vectors both use <>, so you have to add a special 
rule that tells the parser to treat certain cases as values or variables 
instead of tags. But what if someone has <box2, 1, 2>? Is that a bad tag 
or a variable? The XML parser has absolutely know way of knowing what you 
intended or what error to return if it is wrong. You end up having to 
have it *guess* what was intended and we have all seen with HTML and some 
of its complicated quirks how well that works. You can 
successfully display pages in HTML that a validator would throw out 
dozens of errors from, because the validator assumes the most strict 
version, even if it can work, while the browser simply ignores anything 
it doesn't understand. We don't need people doing that with an object/SDL 
syntax.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Not really. That's called a DTD, or more recently an equivalent thing 
> that you express in XML itself (XSLT or some such TLA?).

  Don't confuse XML, DTD and XSLT because they are different things (even
though related to each other).

  DTD defines the valid syntax of a certain XML-type file. For example, if
you want to define the valid syntax for a MathML or an XHTML file, you use
a DTD file for that. It defines which tags (and hierarchy of tags) and
their attributes are valid.

  XSLT is a stylesheet language for XML-type files. It tells how to
convert the XML file to something else (eg. to HTML so that a browser
can show the XML file). In other words, it defines how the XML file
should be shown.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

Darren New wrote:
> 
> Yep. The point is that there is something that tells you more about XML 
> than "start tag" and "end tag". One is the DTD, and the other is the 
> XMLised version whose TLA I don't recall offhand.
> 

XML-Schema.

Dave

Post a reply to this message

In article <406033ce@news.povray.org>,
 "Thorsten Froehlich" <tho### [at] trfde> wrote:

> C and C++ have "long double".  Neither language specifies that "double"
> implies 64 bit IEEE 754 float either.  Apart from C and C++, Fortran
> supports more than 64 bit IEEE 754 floats as well.  Honestly, I am not aware
> of any other languages that really matter in the scientific computing
> community.

You still seem to be missing my point. C and C++ do not specify that 
"double" is a 64 bit IEEE 754 float. Thus, you can not rely on it being 
a 64 bit IEEE 754 float! At this point in time, it *probably* is one, 
but that's not good enough. If your file format uses 64 bit IEEE 754 
floats, you need to specifically write them in that format, or your code 
will create incompatible files or just break on a machine that uses a 
different format.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message