Orc-0.4.1 - The Oil Runtime Compiler

[David Schleef-2]

0.4.1
=====

This release introduces the orcc program, which parses .orc files and
outputs C source files to compile into a library or application.  The
main source file implements the functions described by the .orc source
code, by creating Orc programs and compiling them at runtime.  Another
source file that it outputs is a test program that can be compiled and
run to determine if Orc is generating code correctly.  In future
releases, the orcc tool will be expanded to output assembly code, as
well as make it easier to use Orc in a variety of ways.

Much of Schroedinger and GStreamer have been converted to use Orc
instead of liboil, as well as converting code that wasn't able to
use liboil.  To enable this in Schroedinger, use the --enable-orc
configure option.  The GStreamer changes are in the orc branch in
the repository at http://cgit.freedesktop.org/~ds/gstreamer

Scheduled changes for 0.4.2 include a 2-D array mode for converting
the remaining liboil functions used in Schroedinger and GStreamer.


Major changes:

 - Add the orcc compiler.  Generates C code that creates Orc programs
   from .orc source files.
 - Improved testing
 - Fixes in the C backend
 - Fix the MMX backend to emit 'emms' instructions.
 - Add a few rules to the SSE backend.


Links
=====

Download: http://www.schleef.org/orc/download/
GIT: http://cgit.freedesktop.org/~ds/orc
Documentation: http://www.schleef.org/orc/documentation/


ORC - The Oil Runtime Compiler
==============================

(and OIL stands for Optimized Inner Loops)

Entropy Wave Inc (http://entropywave.com/) presents Orc, the sucessor
to Liboil - The Library of Optimized Inner Loops.

Orc is a library and set of tools for compiling and executing
very simple programs that operate on arrays of data.  The "language"
is a generic assembly language that represents many of the features
available in SIMD architectures, including saturated addition and
subtraction, and many arithmetic operations.

At this point, developers interested in using Orc should look at the
examples and try out a few Orc programs in an experimental branch
of their own projects.  And provide feedback on how it works.  There
will likely be some major changes in ease of use from a developer's
perspective over the next few releases.

The 0.4 series of Orc releases will be API and ABI compatible, and
will be incompatible with the 0.5 series when it comes out.  It is
anticipated that 0.5 will follow in a few months.


Features:

 - Users can create, compile, and run simple programs that use the
   vector extensions of the CPU, all directly from an application.

 - Users can compile Orc programs to assembly source code to be
   compiled and used without linking against the Orc library.

 - The generic assembly language can be extended by an application
   by adding new opcodes.

 - An application can add rules for converting existing or new opcodes
   to binary code for a specific target.

 - Current targets: SSE, MMX, ARM, Altivec.  (ARM is very limited.)
   The NEON and TI c64x+ DSP targets are not open source and can be
   licensed separately from Entropy Wave.

 - Programs can optionally be emulated, which is useful for testing, or
   if no rules are available to convert Orc opcodes to executable code.


Questions and Answers:

 - Q: Why not let gcc vectorize my code?

   A: Two reasons: first, since Orc's assembly language is much more
   restrictive than C, Orc can generate better code than gcc, and
   second, Orc can generate code for functions you define at runtime.
   Many algorithms require gluing together several stages of operations,
   and if each stage has several options, the total amount of code to
   cover all combinations could be inconveniently large.

 - Q: Why not use compiler intrinsics for SIMD code?

   A: Compiler intrinsics only work for one target, and need to be
   hand written.  Plus, some compilers are very picky about source
   code that uses intrinsics, and will silently produce slow code.
   And, of course, you can't compile intrinsics at runtime.

 - Q: How big is the Orc library?

   A: Compiled with only one target (SSE), the library size is about
   86 kB uncompressed, or 30 kB compressed.  The goal is to keep the
   uncompressed size under about 100 kB.


Caveats (Known Bugs):

 - ?


Future directions:

 - Addition of more complex loop control and array structures.

 - Addition of an option to compile the Orc library with only the
   runtime features for a single target, e.g., for embedded systems.
 
 - Addition of rewrite rules, which convert an instruction that cannot
   be converted to binary code into a series of instructions that can.
   This is necessary since assembly instructions on most targets do
   not cover all the features of the Orc assembly language.
 

About Entropy Wave:

Entropy Wave creates tools that allow content producers and distributors
use open video technology.  Through use of open source software like
GStreamer and Dirac, Entropy Wave's customers save money on licensing
costs for encoding and streaming video on the web.  Entropy Wave was
founded in 2008 by long-time open source developer David Schleef.


------------------------------------------------------------------------------
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Sebastian Dröge-7]

Am Donnerstag, den 02.07.2009, 15:34 -0700 schrieb David Schleef:
>
> [...]
> Much of Schroedinger and GStreamer have been converted to use Orc
> instead of liboil, as well as converting code that wasn't able to
> use liboil.  To enable this in Schroedinger, use the --enable-orc
> configure option.  The GStreamer changes are in the orc branch in
> the repository at http://cgit.freedesktop.org/~ds/gstreamer

When do you plan to push this changes to the main GIT repository? Also,
will orc be an optional dependency?

And what will happen if orc is used on an architecture (mips, alpha, x86
without MMX and stuff)? Will orc simply fail then or is there a slow
fallback implementation?

Oh, and I saw you started to convert audioconvert to orc. If you want to
continue this just some notes:
- The dithering can also be done as a simple addition from some random
values array. This could be initialized once when the format changes and
be used as a read-only ring buffer, it just has to be large enough. This
should make it possible to also implement the dithering with orc.
- The multichannel conversion routines need some kind of matrix
operations. Is this what you mean with 2-D array mode?

> Scheduled changes for 0.4.2 include a 2-D array mode for converting
> the remaining liboil functions used in Schroedinger and GStreamer.

Will it also be possible at some point to write things like
for (i = 0; i < N; i+=2)
  d[i] = s[i] + s[i+1]
with orc?

------------------------------------------------------------------------------

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Sebastian Dröge-7]

Am Samstag, den 04.07.2009, 10:13 +0200 schrieb Sebastian Dröge:

> Am Donnerstag, den 02.07.2009, 15:34 -0700 schrieb David Schleef:
> >
> > [...]
> > Much of Schroedinger and GStreamer have been converted to use Orc
> > instead of liboil, as well as converting code that wasn't able to
> > use liboil.  To enable this in Schroedinger, use the --enable-orc
> > configure option.  The GStreamer changes are in the orc branch in
> > the repository at http://cgit.freedesktop.org/~ds/gstreamer
>
> When do you plan to push this changes to the main GIT repository? Also,
> will orc be an optional dependency?
>
> And what will happen if orc is used on an architecture (mips, alpha, x86
> without MMX and stuff)? Will orc simply fail then or is there a slow
> fallback implementation?
>
> Oh, and I saw you started to convert audioconvert to orc. If you want to
> continue this just some notes:
> - The dithering can also be done as a simple addition from some random
> values array. This could be initialized once when the format changes and
> be used as a read-only ring buffer, it just has to be large enough. This
> should make it possible to also implement the dithering with orc.
> - The multichannel conversion routines need some kind of matrix
> operations. Is this what you mean with 2-D array mode?
>
> > Scheduled changes for 0.4.2 include a 2-D array mode for converting
> > the remaining liboil functions used in Schroedinger and GStreamer.
>
> Will it also be possible at some point to write things like
> for (i = 0; i < N; i+=2)
>   d[i] = s[i] + s[i+1]
> with orc?

And something else, I saw that you only added a static "orc" target to
the gst Makefiles. Wouldn't it be better to have a rule like

gstorc.c gstorc.h: gstorc.orc
        orcc gstorc.orc
        mv out.c gstorc.c
        mv out.h gstorc.h

And then gstorc.c in the _SOURCES variable? A dependency on orc is
needed anyway for linking so orcc should be available and the above
would make sure that the C sources are regenerated when the ORC sources
change. Also it's a bit ugly to ship autogenerated code in the tarballs
later IMHO :)

------------------------------------------------------------------------------

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[David Schleef-2]

On Sat, Jul 04, 2009 at 10:13:14AM +0200, Sebastian Dröge wrote:
> When do you plan to push this changes to the main GIT repository?

Probably won't be pushed any time soon.  I'm not planning to write
or maintain #ifdef HAVE_ORC's everywhere, so it's probably not
appropriate for master until Orc gets more user testing, cross-platform
testing, and perhaps a few more features.

There are several hurdles that need to be addressed:

 - Whether Orc will be a required dependency *for users*.  Orc
   will probably grow features soon that makes this irrelevant.

 - Whether Orc will be a required dependency *for developers*.

 - Whether to make the .orc source the canonical description of
   the functions implemented.  Pro: orcc automatically generates
   test code.  Cons: yet more crap for developers to learn, plus
   the generated C code is not easy to understand.

 - Orc is still developing rapidly enough that it will either
   need an ABI bump soon or start accumulating crufty API.

The summit would be a convenient time to discuss such things.  I
don't really need to be involved.  I'm committed to making Orc a
useful tool for GStreamer,

I'm tentatively planning an ABI bump once Orc handles roughly all
the liboil functions that Schroedinger and GStreamer use, which
should be some time in September.  Hopefully there will have been
enough user testing by then that it can be an ABI that is stable
for several years.

> And what will happen if orc is used on an architecture (mips, alpha, x86
> without MMX and stuff)? Will orc simply fail then or is there a slow
> fallback implementation?

It uses the C backup function that orcc generates.

> - The multichannel conversion routines need some kind of matrix
> operations. Is this what you mean with 2-D array mode?

Partly.

> Will it also be possible at some point to write things like
> for (i = 0; i < N; i+=2)
>   d[i] = s[i] + s[i+1]
> with orc?

You can do that right now using something like:

  select0lw t1, s1
  select1lw t2, s1
  addw t1, t1, t2
  select0lw t3, d1
  select1lw t4, d1
  addw t3, t3, t1
  mergewl d1, t3, t4

It's a little clumsy, but any strided operation is clumsy with
vector operations.  (Also note that you can't currently read a
source twice, you have to copy it to a temp variable first, but
that is a bug.)

Concerning the orc Makefile target in you other email, I'm planning
to make orcc also generate independent C code, so if HAVE_ORC is not
defined in config.h (for example), the generated code won't need Orc
headers to compile, nor will you need orcc installed to generate
those files.  These are tradeoffs that aren't unique to Orc.



dave...


------------------------------------------------------------------------------
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[E. Westbrook-4]

 

On Sat, Jul 4, 2009 at 1:37 PM, David Schleef <[hidden email]> wrote:

On Sat, Jul 04, 2009 at 10:13:14AM +0200, Sebastian Dröge wrote:
> When do you plan to push this changes to the main GIT repository?

Probably won't be pushed any time soon.  I'm not planning to write
or maintain #ifdef HAVE_ORC's everywhere, so it's probably not
appropriate for master until Orc gets more user testing, cross-platform
testing, and perhaps a few more features.

There are several hurdles that need to be addressed:

 - Whether Orc will be a required dependency *for users*.  Orc
  will probably grow features soon that makes this irrelevant.

 - Whether Orc will be a required dependency *for developers*.

 - Whether to make the .orc source the canonical description of
  the functions implemented.  Pro: orcc automatically generates
  test code.  Cons: yet more crap for developers to learn, plus
  the generated C code is not easy to understand.

 - Orc is still developing rapidly enough that it will either
  need an ABI bump soon or start accumulating crufty API.

The summit would be a convenient time to discuss such things.  I
don't really need to be involved.  I'm committed to making Orc a
useful tool for GStreamer,

I'm tentatively planning an ABI bump once Orc handles roughly all
the liboil functions that Schroedinger and GStreamer use, which
should be some time in September.  Hopefully there will have been
enough user testing by then that it can be an ABI that is stable
for several years.

> And what will happen if orc is used on an architecture (mips, alpha, x86
> without MMX and stuff)? Will orc simply fail then or is there a slow
> fallback implementation?

It uses the C backup function that orcc generates.

> - The multichannel conversion routines need some kind of matrix
> operations. Is this what you mean with 2-D array mode?

Partly.

> Will it also be possible at some point to write things like
> for (i = 0; i < N; i+=2)
>   d[i] = s[i] + s[i+1]
> with orc?

You can do that right now using something like:

 select0lw t1, s1
 select1lw t2, s1
 addw t1, t1, t2
 select0lw t3, d1
 select1lw t4, d1
 addw t3, t3, t1
 mergewl d1, t3, t4

It's a little clumsy, but any strided operation is clumsy with
vector operations.  (Also note that you can't currently read a
source twice, you have to copy it to a temp variable first, but
that is a bug.)

Concerning the orc Makefile target in you other email, I'm planning
to make orcc also generate independent C code, so if HAVE_ORC is not
defined in config.h (for example), the generated code won't need Orc
headers to compile, nor will you need orcc installed to generate
those files.  These are tradeoffs that aren't unique to Orc.



dave...

------------------------------------------------------------------------------
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

------------------------------------------------------------------------------

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Sebastian Dröge-7]

Am Samstag, den 04.07.2009, 12:37 -0700 schrieb David Schleef:

> On Sat, Jul 04, 2009 at 10:13:14AM +0200, Sebastian Dröge wrote:
> > When do you plan to push this changes to the main GIT repository?
>
> Probably won't be pushed any time soon.  I'm not planning to write
> or maintain #ifdef HAVE_ORC's everywhere, so it's probably not
> appropriate for master until Orc gets more user testing, cross-platform
> testing, and perhaps a few more features.
>
> There are several hurdles that need to be addressed:
>
>  - Whether Orc will be a required dependency *for users*.  Orc
>    will probably grow features soon that makes this irrelevant.

If it's not a dependency for users the CPU feature detection code, etc
must be statically included and called for every single orc program. Not
sure if this is a good idea.

Also one library more or less doesn't make a large difference IMHO.

>  - Whether Orc will be a required dependency *for developers*.

Same as above, one library (+ headers & orcc) more or less doesn't make
much difference.

>  - Whether to make the .orc source the canonical description of
>    the functions implemented.  Pro: orcc automatically generates
>    test code.  Cons: yet more crap for developers to learn, plus
>    the generated C code is not easy to understand.

Also orcc could have a parameter that changes it to output assembly code
for one specific target instead of the JIT-like OrcProgram code. This
probably makes embedded system developers happy ;)

>  - Orc is still developing rapidly enough that it will either
>    need an ABI bump soon or start accumulating crufty API.

Yeah, we should IMHO make orc optional for now until it has matured a
bit.

> The summit would be a convenient time to discuss such things.  I
> don't really need to be involved.  I'm committed to making Orc a
> useful tool for GStreamer,
>
> I'm tentatively planning an ABI bump once Orc handles roughly all
> the liboil functions that Schroedinger and GStreamer use, which
> should be some time in September.  Hopefully there will have been
> enough user testing by then that it can be an ABI that is stable
> for several years.

I've also packaged orc a month ago for Debian/experimental so some more
users/tester will probably come from there too (once it's accepted from
the new packages queue).

IMHO another thing that orc has to support until we can drop liboil
everywhere is the CPU feature detection stuff from liboil to enable "3rd
party" assembly code at runtime, like in the goom plugin. Or we should
add some functions for this somewhere in gst core.

> > - The multichannel conversion routines need some kind of matrix
> > operations. Is this what you mean with 2-D array mode?
>
> Partly.

Great, matrix operations will be very useful for a lot of code I
guess :)

> Concerning the orc Makefile target in you other email, I'm planning
> to make orcc also generate independent C code, so if HAVE_ORC is not
> defined in config.h (for example), the generated code won't need Orc
> headers to compile, nor will you need orcc installed to generate
> those files.  These are tradeoffs that aren't unique to Orc.

As said above I think it's better to generate the C code at runtime (the
embedded systems developers argument, etc above) and another argument
would be that changes to orcc would automatically be applied to all orcc
generated code all over the world ;)

A hybrid solution would be to ship the orcc generated code in tarballs
and have the generation target as in my previous mail. This would make
compilation without orcc possible but when it's installed it can be used
to regenerate the C code (+ maybe a configure switch to force
regeneration).

------------------------------------------------------------------------------

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel