On Thu, 2008-04-17 at 06:41 +0200, Jens M Andreasen wrote:
> On Wed, 2008-04-16 at 22:41 +0200, Mario Lang wrote:
> > You are not really following what I am trying to get across. Cross
> > compilation
> > isn't the issue. The issue is that something as generic as i386 (or i686
> > for
> > rpm b
On Wed, 2008-04-16 at 22:41 +0200, Mario Lang wrote:
> You are not really following what I am trying to get across. Cross
> compilation
> isn't the issue. The issue is that something as generic as i386 (or i686 for
> rpm based distros IIRC) actually targets a lot of different types of hardware.
Christian Schoenebeck <[EMAIL PROTECTED]> writes:
> Am Mittwoch, 16. April 2008 19:25:01 schrieben Sie:
>> The distributor in me cried out when I read over this. I know I am kind
>> if nitpicking here, but please consider how much nicer this would be if
>> the small benchmark was run at start up
Am Mittwoch, 16. April 2008 19:25:01 schrieben Sie:
> The distributor in me cried out when I read over this. I know I am kind
> if nitpicking here, but please consider how much nicer this would be if
> the small benchmark was run at start up time instead of compilation time.
> Its not much more wo
Christian Schoenebeck <[EMAIL PROTECTED]> writes:
[...]
> So I would say it's finally time to put hands on GCC's vector toys, wasting
> less time on hairy assembly tasks. I think for such simple algorithms like
> mixing it's completely sufficient to keep a pure C++ implementation and a GCC
> v
On Wed, 2008-04-16 at 18:36 +0200, Pau Arumí Albó wrote:
> Luthman va escriure:
>
> > This is a development tool, but I'm sending it to the LAU list as well
> > in case there are any not-yet-hackers who would like to start writing
> > effects or synths. It's easy, I promise. Here's the code you w
On Wed, 2008-04-16 at 17:37 +0200, Remon wrote:
> I only modified the example to use gettimeofday() instead of clock().
>
> Maybe a gcc developer can shed some light on this issue ?
>
Not a gcc developer, but 'man clock' says that clock is supposed to
measure the time used by the application t
On Wed, 2008-04-16 at 18:55 +0200, Lars Luthman wrote:
> You are right that is should be p(p_in)[i] instead of p(p_in).
...and *p(p_gain) instead of p(p_gain), obviously. Doh!
--ll
signature.asc
Description: This is a digitally signed message part
__
(answering to LAD only)
Luthman va escriure:
> This is a development tool, but I'm sending it to the LAU list as well
> in case there are any not-yet-hackers who would like to start writing
> effects or synths. It's easy, I promise. Here's the code you would need
> to write for a simple gain effe
This software package contains libraries and programs that should make
it easier to write LV2 plugins and GUIs.
Download it: http://ll-plugins.nongnu.org/hacking.html
Read documentation: http://ll-plugins.nongnu.org/dox/lv2-c++-tools/
Or read a nice tutorial: http://ll-plugins.nongnu.org/lv2pftci
...for those who do not follow the LV2 mailing list.
1. EVENTS
There is an extension for sending arbitrary events to and from plugin
ports here: http://lv2plug.in/ns/ext/event#EventPort
This extension specifies how to send MIDI events using those ports:
http://lv2plug.in/ns/ext/midi#MidiEvent
M
Hi,
And very interesting findings, thanks for looking into this!
Here are some more on my core2 pc.
flags: CFLAGS=-O3 -mmmx -msse -mfpmath=sse -ftree-vectorize
compiler: 4.1.3 or 4.2.1, didn't make a difference.
1.
#define FRAGMENTSIZE32
Benchmarking mixdown (WITH coeff):
Process time for
On Wed, Apr 16, 2008 at 04:46:10PM +0200, Jens M Andreasen wrote:
> Benchmarking mixdown (no coeff):
> pure C++: 100 ms
> ASM SSE : 140 ms
> GCC vector extensions : 120 ms
>
> Benchmarking mixdown (WITH coeff):
> pure C++: 120 ms
> ASM SSE
On Wed, 2008-04-16 at 14:01 +0200, Christian Schoenebeck wrote:
> Am Mittwoch, 16. April 2008 12:17:23 schrieb Jens M Andreasen:
> > Then you will probably like this run of ./mixdown:
> >
> > Benchmarking mixdown (WITH coeff):
> > pure C++: 150 ms <-- pretty good, eh? ;-)
> > ASM SS
Am Mittwoch, 16. April 2008 12:17:23 schrieb Jens M Andreasen:
> Then you will probably like this run of ./mixdown:
>
> Benchmarking mixdown (WITH coeff):
> pure C++: 150 ms <-- pretty good, eh? ;-)
> ASM SSE : 140 ms
> GCC vector extensions : 150 ms
>
> This is wi
On Wed, 2008-04-16 at 10:41 +0200, Christian Schoenebeck wrote:
> So in practice, if the results are very close together anyway, probably not
> even noticeable, I would definitely prefer to spend that time on other tasks
> and enjoy the fact that the implementation compiles with very good
> pe
Am Mittwoch, 16. April 2008 10:14:33 schrieb Jens M Andreasen:
> Yes, it bothers me if the compiler can beat "hand-optimized" ASM :-D
> It turns out that I get different results on consecutive runs of the
> same binary, look:
Well, those two mixing tasks are really simple examples and it's easi(er
Am Mittwoch, 16. April 2008 09:19:19 schrieb Christian Schoenebeck:
> But if you're totally sceptical, you could simply move out the mixing
> functions into an own C++ file, compile that object file with maximum
> optimization, and compile the actual benchmark application with just "-O1"
> or somet
On Wed, 2008-04-16 at 09:19 +0200, Christian Schoenebeck wrote:
> But if you're totally sceptical, ...
Yes, it bothers me if the compiler can beat "hand-optimized" ASM :-D
It turns out that I get different results on consecutive runs of the
same binary, look:
Benchmarking mixdown (WITH coeff):
p
Am Mittwoch, 16. April 2008 02:10:20 schrieb Jens M Andreasen:
> On Tue, 2008-04-15 at 19:45 +0200, Christian Schoenebeck wrote:
> > Yeah, I'm respawning this topic ...
>
> There is something funny with this benchmark. If we compare your
[snip]
> Benchmarking mixdown (WITH coeff):
> ASM SSE
20 matches
Mail list logo
