![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <opr5brv9e1zjc5hb@news.povray.org> , Fredrik Eriksson
<noo### [at] nowhere com> 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] trf de
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Tue, 23 Mar 2004 18:37:01 +0100, Thorsten Froehlich <tho### [at] trf de>
wrote:
> In article <opr5brv9e1zjc5hb@news.povray.org> , Fredrik Eriksson
> <noo### [at] nowhere com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <opr5b0xzcvzjc5hb@news.povray.org> , Fredrik Eriksson
<noo### [at] nowhere com> 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] trf de
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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] ZenPsycho com>
> 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] vip bg
> TAG e-mail : pet### [at] tag povray org
>
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Tue, 23 Mar 2004 22:24:46 +0100, Thorsten Froehlich <tho### [at] trf de>
wrote:
> In article <opr5b0xzcvzjc5hb@news.povray.org> , Fredrik Eriksson
> <noo### [at] nowhere com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <Xns94B59926AB1ABZenZenPsychocom@203.29.75.35>,
Zen### [at] ZenPsycho com 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <406033ce@news.povray.org>,
"Thorsten Froehlich" <tho### [at] trf de> 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] earthlink net>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tag povray org>
http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <cjameshuff-8CAE9E.08563625032004@news.povray.org> , Christopher
James Huff <cja### [at] earthlink net> wrote:
> 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.
>
I never said you would not have to not to do any work. Oc course, to write
that code is really trivial anyway, so it is not an issue worth mentioning
at all. Thus, your whole point is pointless!
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trf de
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |