clipka <nomail@nomail> wrote:
> Who is Orchid? Have I missed something...?

  Not much, really.

  (Sorry Andrew. I *had* to. ;) )

-- 
                                                          - Warp

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> "nemesis" <nam### [at] gmailcom> wrote:
> > Damn!  Isn't it exciting to see this much talk about actual povray code and
> > improvement rather than just read Orchid's blog posts all day?  No offense,
> > Andrew! :D
>
> Who is Orchid? Have I missed something...?

Heh, our resident mascot.  He seems to only roam around in off-topic and
bork.bork.bork... I suggest you keep on with your fine work and don't go there
yet, otherwise you might find yourself posting more than coding... ;)

Post a reply to this message

Warp wrote:
> Thorsten Froehlich <tho### [at] trfde> wrote:
>> You are mistaken. All modern x86 compilers (gcc,icc,vc) can use it instead 
>> of the x87 FPU. I think since versions 3.2, 8, and 7.1 respectively.
> 
>   "Can use" doesn't really tell how effectively they can use it.

This is not about semantics. I suggest you check yourself, Intel has plenty 
of information available.

	Thorsten

Post a reply to this message

Warp wrote:
>   If you are only going to use SSE as a direct substitute for the FPU,
> I assume that would be possible, but you probably won't get any significant
> speed benefit (perhaps even the contrary). In order to truely get benefit
> from SSE, you need to vectorize the calculations so that you can calculate
> many things in parallel. This is extremely hard, if not impossible for a
> compiler to do with random C/C++ code.

Warp, could you stop theorizing and actually *use* the information already 
out there, supplied by Intel and plenty of other sources? SSE != SIMD

	Thorsten

Post a reply to this message

clipka wrote:
> It doesn't seem to be very difficult with software like POV-ray: The Intel C++
> compiler keeps spitting out lots of "code was VECTORIZED" at me every time I
> compile the POV source code. Which is the compiler's way to say that it
> inserted an SSE2 instruction.

Please check out the current Intel information what SSE2 is actually 
supposed to be used for. I am not talking about vectorized code or 
auto-vectorization.

	Thorsten

Post a reply to this message

clipka wrote:
> Thorsten Froehlich <tho### [at] trfde> wrote:
>> clipka wrote:
>>> Don't expect all these to be "naive hardware implementation" in the same sense
>>> as, say, an integer addition, shift, bit-wise AND/OR/XOR or whatever.
>> Exactly that is why you ought to be looking at the SSE2/3 floating-point
>> registers and associated hardware support. The x87 FPU is only there for
>> legacy support and rather inefficient.
> 
> Hah! Say that again...
> 


> SSE3, SSSE3 to SSE4 is rather primitive compared to what the x87 FPU can do -
> except when it comes to bulk add, subtract, multiply or divide. Which is what
> they're designed for: Vectors and matrices. That's why they're called Streaming
> SIMD (= Single Instruction Multiple Data) Extensions.
> 
> Search for trigonometric or logarithmic functions - you'll not find any in the
> SSE2 or SSE3 sections. You'll probably find that these still rely on good old
> x87 FPU instructions.

You are looking at the wrong manual. This manual does not tell you how to do 
something but what is available.  I admit the Intel documentation is not 
clear, but x87 usage is deprecated. This is documented for x86-64 mode in OS 
vendor information because the x86-64 ABIs even use the SSE registers for 
argument passing (no more x87 FPU stack or memory mapped argument passing). 
But googling for that information is difficult. One of the top-most useful 
links I found was 
<http://msdn.microsoft.com/en-us/library/bb147385.aspx#ID0EBEAA> - you will 
have to look up the remaining information yourself. I guess AMD might have 
more info, as they came up with x86-64.....

	Thorsten

Post a reply to this message

>   They should be compiled with all the same options, except for SSE2
> optimizations in order for the measurement to be reliable.

	How about that one?  http://pov4grasp.free.fr/articles/fastpov1/

	(Gee, that's already 4 years old... Yet I never found the time to actually
write down the second part that heavily deals with profile-guided optimization
*sigh*)

	- NC

Post a reply to this message

Thorsten Froehlich wrote:
> You are looking at the wrong manual. This manual does not tell you how 
> to do something but what is available.  I admit the Intel documentation 
> is not clear, but x87 usage is deprecated. This is documented for x86-64 
> mode in OS vendor information because the x86-64 ABIs even use the SSE 
> registers for argument passing (no more x87 FPU stack or memory mapped 
> argument passing). But googling for that information is difficult. One 
> of the top-most useful links I found was 
> <http://msdn.microsoft.com/en-us/library/bb147385.aspx#ID0EBEAA> - you 
> will have to look up the remaining information yourself. I guess AMD 
> might have more info, as they came up with x86-64.....

I guess it would help if M$ would not call x86-64 "AMD64" in older documents...
<http://download.microsoft.com/download/5/b/5/5b5bec17-ea71-4653-9539-204a672f11cf/AMD64_PortApp.doc>
<http://developer.amd.com/pages/62720069_4.aspx>

Some ABI changes exist on Linux and Mac OS X. Thus, it is SSE all the way 
everywhere.

	Thorsten

Post a reply to this message

clipka wrote:
> "nemesis" <nam### [at] gmailcom> wrote:
>> Damn!  Isn't it exciting to see this much talk about actual povray code
>> and
>> improvement rather than just read Orchid's blog posts all day?  No
>> offense, Andrew! :D
> 
> Who is Orchid? Have I missed something...?

Have a quick look at povray.off-topic group. (but don't stay in there for
too long, it's bad for your sanity; get back to radiosity! :D)

Post a reply to this message

Nicolas Calimet <pov### [at] freefr> wrote:
> >   They should be compiled with all the same options, except for SSE2
> > optimizations in order for the measurement to be reliable.

>         How about that one?  http://pov4grasp.free.fr/articles/fastpov1/

  On a related note, it would be cool if it was updated to contain the
results for the latest gcc 4.x line which, AFAIK, contains many additional
optimization tricks up its sleeve.

-- 
                                                          - Warp

Post a reply to this message