In article <41101157$1@news.povray.org> , Nicolas Calimet 
<pov### [at] freefr>  wrote:

>> You are aware that the official POV-Ray for Mac OS does include a
>> just-in-time compiler, aren't you?
>
>  It's very likely Wolfgang never tried the Mac OS version  ;-)

That is true, but using the core code SYS_FUNCTIONS macro family would have
made integration of a JIT compiler possible without hacking fnpovfpu.cpp.
In particular because they are documented to exist exactly for that purpose.
Would at least have made the whole implementation easier...

>  Sounds like a cool patch anyway !

Certainly!  On the other hand, calling gcc is overkill to make JIT
compilation possible :-)

    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

haven't tried it myself, but........ wow!

Post a reply to this message

otherwise encorporate the whole gcc thing in pov-ray. probably impossible
because of licensing issues.

Post a reply to this message

Wolfgang Wieser wrote:
> Hello all...
> 
> the last two days, I wrote a patch for UNIX POVRay-3.6. to speed 
> up user-functions as used e.g. in isosurfaces. 
> 
> Instead of interpreting the functions as done by the POV VM, this 
> patch does just-in-time compilation of the function using the system 
> compiler -- all that on-the-fly completely transparent for the user. 
> 

I think the work probably would have been better invested in 
implementing an internal JIT compiler using the existing hooks as 
Thorsten explained.  This would work on all x86 systems (and for Mac an 
implementation already exists).

BTW your page does not say which optimizations you used for compiling 
the patched version.  To me it seems quite unlikely that you always get 
a speedup, there is also some overhead introduced by calling an external 
library.

None the less an interesting idea of course.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 06 Jul. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

Christoph Hormann wrote:
> I think the work probably would have been better invested in
> implementing an internal JIT compiler using the existing hooks as
> Thorsten explained.  This would work on all x86 systems (and for Mac an
> implementation already exists).
> 
Sounded interesting. I'll have a look at that. 
Why didn't anybody put that on a publically available todo list? ;) 

> BTW your page does not say which optimizations you used for compiling
> the patched version. 
>
Well, this actually does not matter much. As pointed out on my home page, 
I used the same compiler flags for the patched and the unpatched version 
to make sure that the timings can be compared. And of course, I used the 
best ones I know. 
-O2 -ffast-math -march=athlon-xp -Wno-multichar -finline-functions 
-funit-at-a-time -fno-rtti -mfpmath=387

> To me it seems quite unlikely that you always get 
> a speedup, there is also some overhead introduced by calling an external
> library.
> 
This is correct. An external no-op function called via a pointer takes 
about 10 times as long as an internal no-op function. 
No-op function means: 
  int foo(int x)  {  return(x);  }

But we should not forget that the huge swith-case construct in the main VM 
takes some time, too. And this switch is effectively eliminated by JITC. 

Wolfgang

Post a reply to this message

Thorsten Froehlich wrote:

> In article <41100d82@news.povray.org> , Wolfgang Wieser
> <wwi### [at] nospamgmxde>  wrote:
> 
>> - The patch is Linux-specific. Probably Minor efford porting to other

> 
> You are aware that the official POV-Ray for Mac OS does include a
> just-in-time compiler, aren't you?
> 
Actually, I was not aware of that! I'll have a look. 
Thanks for the hint. 

Wolfgang

Post a reply to this message

On Wed, 04 Aug 2004 11:28:22 +0200, Wolfgang Wieser <wwi### [at] nospamgmxde>
wrote:
> Christoph Hormann wrote:
> > I think the work probably would have been better invested in
> > implementing an internal JIT compiler using the existing hooks as
> > Thorsten explained.  This would work on all x86 systems (and for Mac an
> > implementation already exists).
> 
> Sounded interesting. I'll have a look at that. 
> Why didn't anybody put that on a publically available todo list? ;) 

I have considered this task for the future versions of MegaPOV thought I would
be veeeeery happy if you could be faster :-)

ABX

Post a reply to this message

Thorsten Froehlich wrote:

> In article <41101157$1@news.povray.org> , Nicolas Calimet
> <pov### [at] freefr>  wrote:
> 
>>> You are aware that the official POV-Ray for Mac OS does include a
>>> just-in-time compiler, aren't you?
>>
>>  It's very likely Wolfgang never tried the Mac OS version  ;-)
> 
> That is true, but using the core code SYS_FUNCTIONS macro family would
> have made integration of a JIT compiler possible without hacking
> fnpovfpu.cpp. In particular because they are documented to exist exactly
> for that purpose. 
>
Well, "they are documented to..." is little exaggeration. 
All I have found in the sources about these macros were a couple 
of lines which described just what I already knew from reading the 
code and one "cryptic" allusion that it can be used somehow to allow 
JIT compilation. And that sounded to me like "we could some time 
use that for JIT if we finally find the time to do so"...

> Would at least have made the whole implementation 
> easier...
> 
Okay... could somebody please make the POVRay-for-MacOS 
source code available in a file format which I can read?

Or, alternatively, point me to a _working_ .sit unpacker for Linux. 

The last time I was using the stuffit expander, I sweared to ban it from 
my HD: First, I unpacked the archive which took quite long for just 
some hundret kb. The binaries were okay but I saw that it messed up 
the newlines in the text. So, I un-packed it again with changed flags 
which really took _ages_ now and finally the text files were okay but 
the binaries were corrupt. Oh dear...

> Certainly!  On the other hand, calling gcc is overkill to make JIT
> compilation possible :-)
> 
I wonder how the Mac version does it...

Wolfgang

Post a reply to this message

ABX wrote:

> On Wed, 04 Aug 2004 11:28:22 +0200, Wolfgang Wieser
> <wwi### [at] nospamgmxde> wrote:
>> Christoph Hormann wrote:
>> > I think the work probably would have been better invested in
>> > implementing an internal JIT compiler using the existing hooks as
>> > Thorsten explained.  This would work on all x86 systems (and for Mac an
>> > implementation already exists).
>> 
>> Sounded interesting. I'll have a look at that.
>> Why didn't anybody put that on a publically available todo list? ;)
> 
> I have considered this task for the future versions of MegaPOV thought I
> would be veeeeery happy if you could be faster :-)
> 
IMO, in the present stage, this patch is not suitable for inclusion into 
MegaPOV. Need to get rid of some unclean "hacks" first. 

Or, maybe better, use the existing SYS_ macros if I manage to figure out 
how to use them. 

BTW, will the features from MLPov be included in the next MegaPOV version?

Wolfgang

Post a reply to this message

On Wed, 04 Aug 2004 11:58:19 +0200, Wolfgang Wieser <wwi### [at] nospamgmxde>
wrote:
> BTW, will the features from MLPov be included in the next MegaPOV version?

Well... we try to be trendy ;-)

ABX

Post a reply to this message