Havent been receiving any news lately, please help.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:linux-audio-dev-admin@;music.columbia.edu]On Behalf Of
[EMAIL PROTECTED]
Sent: Saturday, July 27, 2002 9:00 AM
To: [EMAIL PROTECTED]
Subject: linux-audio-dev digest, Vol 1 #127 - 2 msgs
Send linux-audio-dev mailing list submissions to
[EMAIL PROTECTED]
To subscribe or unsubscribe via the World Wide Web, visit
http://music.columbia.edu/mailman/listinfo/linux-audio-dev
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of linux-audio-dev digest..."
Today's Topics:
1. Re: runtime / compiletime processing proof of concept (Paul Winkler)
2. Re: runtime / compiletime processing proof of concept (Juan Linietsky)
--__--__--
Message: 1
Date: Fri, 26 Jul 2002 13:00:10 -0400
From: Paul Winkler <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: [linux-audio-dev] runtime / compiletime processing proof of
concept
Reply-To: [EMAIL PROTECTED]
On Fri, Jul 26, 2002 at 01:21:46PM +0200, Maarten de Boer wrote:
> Hello,
>
> Juan Linietsky (reduz on #lad) talked on #lad about an idea of
> Benno to have processing graphs generate source code, compile
> it on the fly, thus taking advantage of all compiled optimizations,
> as an alternative to runtime processing. Especially for sample
> based processing instead of block based processing this can be
> very useful and a lot faster.
John Lazarro tells me that sfront does something similar.
He says it's described here:
http://www.cs.berkeley.edu/~lazzaro/sa/pubs/pdf/wemp01.pdf
--PW
--__--__--
Message: 2
Date: Fri, 26 Jul 2002 14:38:40 -0300
From: Juan Linietsky <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: [linux-audio-dev] runtime / compiletime processing proof of
concept
Organization: Codenix
Reply-To: [EMAIL PROTECTED]
On Fri, 26 Jul 2002 13:56:55 +0200
Maarten de Boer <[EMAIL PROTECTED]> wrote:
>
> What i forgot to mention:
>
> The most interesting thing is that the code used for runtime, and
> the generated code used for on the fly compilation is actually the
> same! Which ensures that the result of runtime execution and
> compiling generated code -> execution is the same, and everything
> has to be written only once.
>
> maarten
>
Hi! Thanks for taking the time of writing a proof of concept program.
So far from what i've been reading it seems ok (didnt have much time
to check the entire code in detail) althought the real
advantage of compiling such graphs is when they are very large and
stack/buffer and indirection operations start to really slow it down.
Still, even whith this, i get (please tell me if these are correct):
realtime code: (./main)
real 0m1.005s
user 0m0.970s
sys 0m0.030s
runtime code: (./gen)
real 0m0.435s
user 0m0.370s
sys 0m0.060s
three seems to be quite a difference!
Juan Linietsky
--__--__--
_______________________________________________________
linux-audio-dev Mailing List Digest
http://music.columbia.edu/mailman/listinfo/linux-audio-dev
End of linux-audio-dev Digest
