From gmendola at mbigroup.it Mon Aug 4 08:00:42 2008 From: gmendola at mbigroup.it (Gaetano Mendola) Date: Mon, 04 Aug 2008 10:00:42 +0200 Subject: Fast convolution (slow!) Message-ID: <4896B72A.5090203@mbigroup.it> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I'm evaluating VSIPL++ for an application heavily based on convolutions. I tried the following code to estimate some execution time: int main(int argc, char **argv) { vsip::vsipl init(argc, argv); typedef vsip::complex T; const unsigned long long N = 10000; vsip::Vector inputs(N); vsip::Vector filters(N); vsip::Vector outputs(N); typedef vsip::Fft fwd_fft_type; typedef vsip::Fft inv_fft_type; fwd_fft_type fwd_fft(N, 1.0f); inv_fft_type inv_fft(N, 1.0f/N); fwd_fft(inputs, outputs); outputs *= filters; inv_fft(outputs); } and I obtained the following data: fwd_fft_type fwd_fft(N, 1.0f); -> 19.041 sec [19041 ms] inv_fft_type inv_fft(N, 1.0f/N); -> 19.009 sec [19009 ms] Convolution -> 000 ms now, I can accept a 40seconds as start up time for my final application but I have to raise that N to around 1E6 (one of the two vectors containse 1E6 samples, the second one contains 3k samples) so it seems not doable, am I doing something wrong? Atm I'm doing some tests on a Xeon processor in production should be CellBe. Regards Gaetano Mendola -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIlrcq7UpzwH2SGd4RArvJAKDmNIYTmOAcEL0DLhiaH+IV2xitzwCfUO31 mI9nc9MfjWVosqJJmqi06D0= =TdnR -----END PGP SIGNATURE----- From jules at codesourcery.com Tue Aug 5 19:44:25 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Tue, 05 Aug 2008 15:44:25 -0400 Subject: [vsipl++] Fast convolution (slow!) In-Reply-To: <4896B72A.5090203@mbigroup.it> References: <4896B72A.5090203@mbigroup.it> Message-ID: <4898AD99.90004@codesourcery.com> Gaetano Mendola wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi all, > I'm evaluating VSIPL++ for an application heavily based on convolutions. Gaetano, Thank you for evaluating VSIPL++! We'll try to answer your questions as best we can to make sure your evaluation is a success. VSIPL++ separates the creation of an FFT object (the 'fwd_fft_type fwd_fft') from the invocation (the 'fwd_fft(inputs, outputs') to allow potentially expensive setup computations to occur "outside" the computation inner loop. For example, a simple FFT backend might pre-compute twiddle factors, while a more elaborate backend might determine which FFT choices (radix, DIF vs DIT, etc) is best suited for the architecture. The intent is that setup computations will be amortized over a large number of FFT invocations. That is occurring here. The FFT backend use by VSIPL++ (persumably FFTW3) is spending considerable time planning the FFTs (20 sec per FFT) to give an efficient execution. If you really are performing the convolution only once (i.e. preventing the setup time from being amortized), you might consider setting the "number of times" template parameter to 1. This will tell the FFT BE to spend less effort planning. This will slow the FFT itself, but the overall time should be smaller. The default number of times is 0 corresponds to "infinite", which results in a large planning effort. typedef vsip::Fft fwd_fft_type; You might also consider using another FFT backend library besides FFTW3. IPP may spend less time planning, without sacrificing performance. However, IPP may have poorer performance on non-power-of-2 FFTs. Also, to be clear, what FFT library are you using? Is it the default provided by VSIPL++ (FFTW3), or another one? thanks, -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 From jules at codesourcery.com Wed Aug 6 13:20:52 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Wed, 06 Aug 2008 09:20:52 -0400 Subject: [patch] Document div, mul, and sub elementwise functions Message-ID: <4899A534.7030007@codesourcery.com> This patch documents the div,mul, and sub elementwise functions, along the same lines as the add function. It also removes the arguments from the man page title ('Add' instead of 'Add(A, B)') and adds a section on operator syntax (stating that 'add(A, B)' is equivalent to 'A + B'). I've put a generated manual here: ~jules/tmp/manual.pdf Ok to apply? -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: man.diff URL: From stefan at codesourcery.com Wed Aug 6 13:36:28 2008 From: stefan at codesourcery.com (Stefan Seefeld) Date: Wed, 06 Aug 2008 09:36:28 -0400 Subject: [vsipl++] [patch] Document div, mul, and sub elementwise functions In-Reply-To: <4899A534.7030007@codesourcery.com> References: <4899A534.7030007@codesourcery.com> Message-ID: <4899A8DC.1000306@codesourcery.com> Jules Bergmann wrote: > This patch documents the div,mul, and sub elementwise functions, along > the same lines as the add function. > > It also removes the arguments from the man page title ('Add' instead of > 'Add(A, B)') and adds a section on operator syntax (stating that 'add(A, > B)' is equivalent to 'A + B'). > > I've put a generated manual here: ~jules/tmp/manual.pdf > > Ok to apply? This looks good (literally so ! :-) ). I have a couple of (small) issues, though: > +
> + <literal>div</literal> What is the reason you use the 'literal' element in the above ? Is it to force a specific output style ? If you really want to mark this up specially, I'd suggest any of the more expressive markups, such as 'code'. (The same issue came up in a patch from Mike.) > + Elementwise Functions > > + > + > + I would suggest we put the namespace declaration (the 'xmlns:xi' attribute) into the root element of each xml file, so we don't need to repeat it each time we use xi:include. Finally, I noticed in your pdf manual the same thing Mike complained about in his output: the formatting of the function synopsis is wrong, as the function parameter types are declared outside the function prototype. As I mentioned in a reply to Mike, the fix for this is to customize the html and fo - generating stylesheets so ansi-style formatting is used, not k&r. (I can submit a fix for this in a separate patch, as it affects the csl-docbook module only.) Thanks, Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718 From gmendola at mbigroup.it Wed Aug 6 13:33:38 2008 From: gmendola at mbigroup.it (Gaetano Mendola) Date: Wed, 06 Aug 2008 15:33:38 +0200 Subject: [vsipl++] Fast convolution (slow!) In-Reply-To: <4898AD99.90004@codesourcery.com> References: <4896B72A.5090203@mbigroup.it> <4898AD99.90004@codesourcery.com> Message-ID: <4899A832.7040903@mbigroup.it> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jules Bergmann wrote: > Gaetano Mendola wrote: >> Hi all, >> I'm evaluating VSIPL++ for an application heavily based on convolutions. > > Gaetano, > > Thank you for evaluating VSIPL++! We'll try to answer your questions > as best we can to make sure your evaluation is a success. > > VSIPL++ separates the creation of an FFT object (the 'fwd_fft_type > fwd_fft') from the invocation (the 'fwd_fft(inputs, outputs') to allow > potentially expensive setup computations to occur "outside" the > computation inner loop. For example, a simple FFT backend might > pre-compute twiddle factors, while a more elaborate backend might > determine which FFT choices (radix, DIF vs DIT, etc) is best suited > for the architecture. The intent is that setup computations will be > amortized over a large number of FFT invocations. > > That is occurring here. The FFT backend use by VSIPL++ (persumably > FFTW3) is spending considerable time planning the FFTs (20 sec per > FFT) to give an efficient execution. > > If you really are performing the convolution only once > (i.e. preventing the setup time from being amortized), you might > consider setting the "number of times" template parameter to 1. This > will tell the FFT BE to spend less effort planning. This will slow > the FFT itself, but the overall time should be smaller. The default > number of times is 0 corresponds to "infinite", which results in a > large planning effort. > > typedef vsip::Fft vsip::by_reference, > 1 // Number of times > > fwd_fft_type; > > You might also consider using another FFT backend library besides > FFTW3. IPP may spend less time planning, without sacrificing > performance. However, IPP may have poorer performance on > non-power-of-2 FFTs. > > Also, to be clear, what FFT library are you using? Is it the default > provided by VSIPL++ (FFTW3), or another one? I do believe I'm using the FFTW3, I'm linking with: - -lfftw3 -lfftw3f -lfftw3l My application will do lot of convolution, so the best would be let the vsip::Fft::CTOR make a full plan, but this is not feasible with the large N I have to use. I have done some test with power of 2 and this is what I get: N: 2 -> 001 ms N: 4 -> 000 ms N: 8 -> 000 ms N: 16 -> 000 ms N: 32 -> 013 ms N: 64 -> 035 ms N: 128 -> 083 ms N: 256 -> 140 ms N: 512 -> 324 ms N: 1024 -> 678 ms N: 2048 -> 1.477 sec [1477 ms] N: 4096 -> 3.529 sec [3529 ms] N: 8192 -> 8.569 sec [8569 ms] N: 16384 -> 19.157 sec [19157 ms] N: 32768 -> 23.527 sec [23527 ms] N: 65536 -> 53.429 sec [53429 ms] N: 131072 -> 1:34.803 [94803 ms] N: 262144 -> 3:34.710 [214710 ms] N: 524288 -> 9:30.746 [570746 ms] N: 1048576 -> 25:24.579 [1524579 ms] N: 2097152 -> 56:42.435 [3402435 ms] N: 4194304 -> 2:10:8.423 [7808423 ms] In my application I have to perform convolution of a sequence with N points with a sequence of M points where N ~ 1E6 points, M ~ 1K points. Having a startup time of 1 hour for my application is too much, is there a way to serialize on disk an instance of "vsip::Fft"? Also take a look at the following two tests: Test1. typedef vsip::Fft fwd_fft_type; fwd_fft_type fwd_fft(1048576, 1.0); <== 25 minutes Test2. vsip::Vector inputs(1048576); typedef vsip::Fft fwd_fft_type; fwd_fft_type fwd_fft(1048576, 1.0); <== 10 ms (as expected) fwd_fft(inputs); <== 91 ms (I expected here around 25 mins) I think something wrong is going on. Regards Gaetano Mendola -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFImagy7UpzwH2SGd4RAiATAJ4qHhFC0A5Aw7IFpzJUwCvcJoP3igCguuCL y1Nj6TOitedpsXMG3eFsijY= =Vbwi -----END PGP SIGNATURE----- From jules at codesourcery.com Wed Aug 6 13:59:09 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Wed, 06 Aug 2008 09:59:09 -0400 Subject: [vsipl++] [patch] Document div, mul, and sub elementwise functions In-Reply-To: <4899A8DC.1000306@codesourcery.com> References: <4899A534.7030007@codesourcery.com> <4899A8DC.1000306@codesourcery.com> Message-ID: <4899AE2D.50804@codesourcery.com> > This looks good (literally so ! :-) ). I have a couple of (small) > issues, though: > >> +
>> + <literal>div</literal> > > What is the reason you use the 'literal' element in the above ? Is it to > force a specific output style ? If you really want to mark this up > specially, I'd suggest any of the more expressive markups, such as > 'code'. (The same issue came up in a patch from Mike.) I have it as literal partly because that is how add.xml did it (lame excuse :), and partly because it should be treated as a code fragment fontifically. I'll use instead. > > >> + Elementwise Functions >> > href="add.xml" /> >> + > href="div.xml" /> >> + > href="mul.xml" /> >> + > href="sub.xml" /> > > I would suggest we put the namespace declaration (the 'xmlns:xi' > attribute) into the root element of each xml file, so we don't need to > repeat it each time we use xi:include. Ok. Is there an example of doing that for us XML neophytes? > > Finally, I noticed in your pdf manual the same thing Mike complained > about in his output: the formatting of the function synopsis is wrong, > as the function parameter types are declared outside the function > prototype. As I mentioned in a reply to Mike, the fix for this is to > customize the html and fo - generating stylesheets so ansi-style > formatting is used, not k&r. > (I can submit a fix for this in a separate patch, as it affects the > csl-docbook module only.) I agree the output looks ugly. How long would a fix take? If it is a couple of hours, go for it. Otherwise, let's punt until another year, as Mark suggests. -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 From Mike at CodeSourcery.com Wed Aug 6 14:22:52 2008 From: Mike at CodeSourcery.com (Mike LeBlanc) Date: Wed, 6 Aug 2008 10:22:52 -0400 Subject: [vsipl++] [patch] Document div, mul, and sub elementwise functions In-Reply-To: <4899AE2D.50804@codesourcery.com> References: <4899A534.7030007@codesourcery.com> <4899A8DC.1000306@codesourcery.com> <4899AE2D.50804@codesourcery.com> Message-ID: <71DC25CE-D5CF-4940-9ED9-F323DFBFD5E1@CodeSourcery.com> On Aug 6, 2008, at 9:59 AM, Jules Bergmann wrote: > I agree the output looks ugly. How long would a fix take? If it is > a couple of hours, go for it. Otherwise, let's punt until another > year, as Mark suggests. I have the following changes and they seem to do what Stefan predicted. Will this do? mike at cugel:~/csl-docbook$ svn diff Index: xsl/fo/csl.xsl =================================================================== --- xsl/fo/csl.xsl (revision 216979) +++ xsl/fo/csl.xsl (working copy) @@ -342,5 +342,7 @@ /article nop +ansi + Index: xsl/html/csl.xsl =================================================================== --- xsl/html/csl.xsl (revision 216979) +++ xsl/html/csl.xsl (working copy) @@ -47,4 +47,6 @@ are displayed in their intrinsic size instead. --> 1 +ansi + From stefan at codesourcery.com Wed Aug 6 14:25:44 2008 From: stefan at codesourcery.com (Stefan Seefeld) Date: Wed, 06 Aug 2008 10:25:44 -0400 Subject: [vsipl++] [patch] Document div, mul, and sub elementwise functions In-Reply-To: <71DC25CE-D5CF-4940-9ED9-F323DFBFD5E1@CodeSourcery.com> References: <4899A534.7030007@codesourcery.com> <4899A8DC.1000306@codesourcery.com> <4899AE2D.50804@codesourcery.com> <71DC25CE-D5CF-4940-9ED9-F323DFBFD5E1@CodeSourcery.com> Message-ID: <4899B468.9050801@codesourcery.com> Mike LeBlanc wrote: > On Aug 6, 2008, at 9:59 AM, Jules Bergmann wrote: > >> I agree the output looks ugly. How long would a fix take? If it is a >> couple of hours, go for it. Otherwise, let's punt until another year, >> as Mark suggests. > > I have the following changes and they seem to do what Stefan predicted. > Will this do? Yes, that's precisely what I suggest. As far as I'm concerned, please check it in. (Mark, is anybody in the GNU Toolchain group using functionsynopsis ? Does this change affect you at all ?) Thanks, Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718 From stefan at codesourcery.com Wed Aug 6 14:26:43 2008 From: stefan at codesourcery.com (Stefan Seefeld) Date: Wed, 06 Aug 2008 10:26:43 -0400 Subject: [vsipl++] [patch] Document div, mul, and sub elementwise functions In-Reply-To: <4899AE2D.50804@codesourcery.com> References: <4899A534.7030007@codesourcery.com> <4899A8DC.1000306@codesourcery.com> <4899AE2D.50804@codesourcery.com> Message-ID: <4899B4A3.20109@codesourcery.com> Jules Bergmann wrote: >>> + Elementwise Functions >>> >> href="add.xml" /> >>> + >> href="div.xml" /> >>> + >> href="mul.xml" /> >>> + >> href="sub.xml" /> >> >> I would suggest we put the namespace declaration (the 'xmlns:xi' >> attribute) into the root element of each xml file, so we don't need to >> repeat it each time we use xi:include. > > Ok. Is there an example of doing that for us XML neophytes? tutorial/tutorial.xml does what I suggest. Thanks, Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718 From Mike at CodeSourcery.com Wed Aug 6 14:32:00 2008 From: Mike at CodeSourcery.com (Mike LeBlanc) Date: Wed, 6 Aug 2008 10:32:00 -0400 Subject: [vsipl++] [patch] Document div, mul, and sub elementwise functions In-Reply-To: <4899B468.9050801@codesourcery.com> References: <4899A534.7030007@codesourcery.com> <4899A8DC.1000306@codesourcery.com> <4899AE2D.50804@codesourcery.com> <71DC25CE-D5CF-4940-9ED9-F323DFBFD5E1@CodeSourcery.com> <4899B468.9050801@codesourcery.com> Message-ID: <0B038D4D-7053-4CBB-B5C5-3FE2D6791C61@CodeSourcery.com> On Aug 6, 2008, at 10:25 AM, Stefan Seefeld wrote: > Yes, that's precisely what I suggest. As far as I'm concerned, > please check it in. (Mark, is anybody in the GNU Toolchain group > using functionsynopsis ? Does this change affect you at all ?) Yesterday I stumbled on a similar tag , and related children, for OO languages. Is anyone using this already for C++? From mark at codesourcery.com Wed Aug 6 14:36:20 2008 From: mark at codesourcery.com (Mark Mitchell) Date: Wed, 06 Aug 2008 07:36:20 -0700 Subject: [vsipl++] [patch] Document div, mul, and sub elementwise functions In-Reply-To: <4899A8DC.1000306@codesourcery.com> References: <4899A534.7030007@codesourcery.com> <4899A8DC.1000306@codesourcery.com> Message-ID: <4899B6E4.7010408@codesourcery.com> Stefan Seefeld wrote: >> +
>> + <literal>div</literal> > > What is the reason you use the 'literal' element in the above ? Is it to > force a specific output style ? If you really want to mark this up > specially, I'd suggest any of the more expressive markups, such as > 'code'. (The same issue came up in a patch from Mike.) Or even .... -- Mark Mitchell CodeSourcery mark at codesourcery.com (650) 331-3385 x713 From mark at codesourcery.com Wed Aug 6 14:38:46 2008 From: mark at codesourcery.com (Mark Mitchell) Date: Wed, 06 Aug 2008 07:38:46 -0700 Subject: [vsipl++] [patch] Document div, mul, and sub elementwise functions In-Reply-To: <4899B468.9050801@codesourcery.com> References: <4899A534.7030007@codesourcery.com> <4899A8DC.1000306@codesourcery.com> <4899AE2D.50804@codesourcery.com> <71DC25CE-D5CF-4940-9ED9-F323DFBFD5E1@CodeSourcery.com> <4899B468.9050801@codesourcery.com> Message-ID: <4899B776.7060203@codesourcery.com> Stefan Seefeld wrote: > Yes, that's precisely what I suggest. As far as I'm concerned, please > check it in. (Mark, is anybody in the GNU Toolchain group using > functionsynopsis ? Does this change affect you at all ?) Not to the best of my knowledge, but Sandra is our documentation expert. I would suggest asking her to check. Or, check out the getting-started guide (the primary piece of DocBook on the toolchain side) and look there. (I forget the exact module name in subversion, but if you look for getting.*started I'm sure you'll find it.) Thanks, -- Mark Mitchell CodeSourcery mark at codesourcery.com (650) 331-3385 x713 From stefan at codesourcery.com Wed Aug 6 14:48:28 2008 From: stefan at codesourcery.com (Stefan Seefeld) Date: Wed, 06 Aug 2008 10:48:28 -0400 Subject: [vsipl++] [patch] Document div, mul, and sub elementwise functions In-Reply-To: <0B038D4D-7053-4CBB-B5C5-3FE2D6791C61@CodeSourcery.com> References: <4899A534.7030007@codesourcery.com> <4899A8DC.1000306@codesourcery.com> <4899AE2D.50804@codesourcery.com> <71DC25CE-D5CF-4940-9ED9-F323DFBFD5E1@CodeSourcery.com> <4899B468.9050801@codesourcery.com> <0B038D4D-7053-4CBB-B5C5-3FE2D6791C61@CodeSourcery.com> Message-ID: <4899B9BC.4000704@codesourcery.com> Mike LeBlanc wrote: > On Aug 6, 2008, at 10:25 AM, Stefan Seefeld wrote: > >> Yes, that's precisely what I suggest. As far as I'm concerned, please >> check it in. (Mark, is anybody in the GNU Toolchain group using >> functionsynopsis ? Does this change affect you at all ?) > > Yesterday I stumbled on a similar tag , and related > children, for OO languages. Is anyone using this already for C++? Yes. DocBook has some vocabulary bordering (or even overlapping with) a modeling language. Whether or not it is worth using this depends on our precise needs. As I find the existing elements rather limited, I have so far avoided using them. I tried to use the existing vocabulary in the Synopsis DocBook formatter, but ran into lots of problems. For now I abandoned the idea, and am now using the generic 'synopsis' element. (I have some plans to work on a DocBook 5 extension profile adding more modeling-related vocabulary, in particular to better support C++ templates, or even (eventually) concepts. Some related work has been done as part of the boost project.) FWIW, Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718 From Mike at CodeSourcery.com Wed Aug 6 15:13:10 2008 From: Mike at CodeSourcery.com (Mike LeBlanc) Date: Wed, 6 Aug 2008 11:13:10 -0400 Subject: [vsipl++] [patch] Document div, mul, and sub elementwise functions In-Reply-To: <4899B9BC.4000704@codesourcery.com> References: <4899A534.7030007@codesourcery.com> <4899A8DC.1000306@codesourcery.com> <4899AE2D.50804@codesourcery.com> <71DC25CE-D5CF-4940-9ED9-F323DFBFD5E1@CodeSourcery.com> <4899B468.9050801@codesourcery.com> <0B038D4D-7053-4CBB-B5C5-3FE2D6791C61@CodeSourcery.com> <4899B9BC.4000704@codesourcery.com> Message-ID: Please see ~mike/tmp/manual.pdf for changes to the window pages like Jules' for add etc., also with Stefan's ansi change and removing most uses of in favor of or , and instead of . From brooks at codesourcery.com Wed Aug 6 17:19:34 2008 From: brooks at codesourcery.com (Brooks Moses) Date: Wed, 06 Aug 2008 10:19:34 -0700 Subject: [vsipl++] [patch] Document div, mul, and sub elementwise functions In-Reply-To: <71DC25CE-D5CF-4940-9ED9-F323DFBFD5E1@CodeSourcery.com> References: <4899A534.7030007@codesourcery.com> <4899A8DC.1000306@codesourcery.com> <4899AE2D.50804@codesourcery.com> <71DC25CE-D5CF-4940-9ED9-F323DFBFD5E1@CodeSourcery.com> Message-ID: <4899DD26.5080306@codesourcery.com> Mike LeBlanc wrote, at 8/6/2008 7:22 AM: > On Aug 6, 2008, at 9:59 AM, Jules Bergmann wrote: >> I agree the output looks ugly. How long would a fix take? If it is >> a couple of hours, go for it. Otherwise, let's punt until another >> year, as Mark suggests. > > I have the following changes and they seem to do what Stefan > predicted. Will this do? This looks good functionally, and I've checked to confirm that "functionsynopsis" is not used in either the stable or trunk versions of the getting-started guide: > grep -R functionsynopsis getting-started-stable/ > grep -R functionsynopsis getting-started-trunk/ > It would be good to indent these lines a space to match the other elements, and add a comment along the lines of "Format function synopses in ANSI style, not K&R style" above them. With those changes, this is good to check in. - Brooks, occasional csl-docbook maintainer. :) > mike at cugel:~/csl-docbook$ svn diff > Index: xsl/fo/csl.xsl > =================================================================== > --- xsl/fo/csl.xsl (revision 216979) > +++ xsl/fo/csl.xsl (working copy) > @@ -342,5 +342,7 @@ > /article nop > > > +ansi > + > > > Index: xsl/html/csl.xsl > =================================================================== > --- xsl/html/csl.xsl (revision 216979) > +++ xsl/html/csl.xsl (working copy) > @@ -47,4 +47,6 @@ > are displayed in their intrinsic size instead. --> > 1 > > +ansi > + > > From jules at codesourcery.com Wed Aug 6 18:52:45 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Wed, 06 Aug 2008 14:52:45 -0400 Subject: [vsipl++] Fast convolution (slow!) In-Reply-To: <4899A832.7040903@mbigroup.it> References: <4896B72A.5090203@mbigroup.it> <4898AD99.90004@codesourcery.com> <4899A832.7040903@mbigroup.it> Message-ID: <4899F2FD.6020906@codesourcery.com> Gaetano, > In my application I have to perform convolution of a sequence with N > points with a sequence of M points where N ~ 1E6 points, M ~ 1K > points. Having a startup time of 1 hour for my application is too > much, is there a way to serialize on disk an instance of > "vsip::Fft vsip::by_reference>"? I agree, a startup time of 1 hour is excessive! It turns out VSIPL++ uses FFTW3's PATIENT planning mode when number of times == 0 (since '0' indicates the FFT object will be used an infinite number of times). As you're seeing, PATIENT can be very expensive. If you set number of times to 15, VSIPL++ will use FFTW3's MEASURE planning mode, which should be much faster than the PATIENT planning mode, while still delivering reasonable performance. For example, for a 1K and 1M FFTs (measuring MFLOP/s on a ~3.6 GHz Xeon): ESTIMATE MEASURE PATIENT (times == 1) (times == 15) (times == 0) 1K 4959 6355 7482 32K 3985 5370 6488 1M 687 1735 While FFTW3 allows plans to be pre-computed and stored to disk, there is no way to access the functionalty from VSIPL++ at present. > > Also take a look at the following two tests: > > Test1. > > typedef vsip::Fft fwd_fft_type; > fwd_fft_type fwd_fft(1048576, 1.0); <== 25 minutes > > > Test2. > > vsip::Vector inputs(1048576); > typedef vsip::Fft fwd_fft_type; > fwd_fft_type fwd_fft(1048576, 1.0); <== 10 ms (as expected) > fwd_fft(inputs); <== 91 ms (I expected here around 25 mins) > > I think something wrong is going on. No, that's reasonable. It is the power of heuristics doing well against a brute force search. PATIENT (number of times == 0) does a thorough search of the space of possible FFTs, while ESTIMATE (number of times == 1) uses simple heuristics. Presumably, if you measured the FFT time for Test1, it would be faster than 91 ms. If it wasn't, it would indicate that the ESTIMATE heuristics happened to pick the best case heuristically, leaving PATIENT with nothing better to find. -- Jules > > > Regards > Gaetano Mendola -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 From jules at codesourcery.com Thu Aug 7 12:38:36 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Thu, 07 Aug 2008 08:38:36 -0400 Subject: [vsipl++] Fast convolution (slow!) In-Reply-To: <4899F2FD.6020906@codesourcery.com> References: <4896B72A.5090203@mbigroup.it> <4898AD99.90004@codesourcery.com> <4899A832.7040903@mbigroup.it> <4899F2FD.6020906@codesourcery.com> Message-ID: <489AECCC.6060406@codesourcery.com> > For example, for a 1K and 1M FFTs (measuring MFLOP/s on a ~3.6 GHz > Xeon): > Updating this with the PATIENT 1M performance: ESTIMATE MEASURE PATIENT (times == 1) (times == 15) (times == 0) 1K 4959 6355 7482 32K 3985 5370 6488 1M 687 1735 3177 -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 From jules at codesourcery.com Tue Aug 19 13:38:20 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Tue, 19 Aug 2008 09:38:20 -0400 Subject: [patch] Fix llsqsol to detect qrd save type Message-ID: <48AACCCC.1090804@codesourcery.com> This patches llsqsol to determine whether to use qrd_saveq (full) or qrd_saveq1 (skinny), since not all BE's support both. Ok to apply? -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lsq.diff URL: From stefan at codesourcery.com Tue Aug 19 13:52:20 2008 From: stefan at codesourcery.com (Stefan Seefeld) Date: Tue, 19 Aug 2008 09:52:20 -0400 Subject: [vsipl++] [patch] Fix llsqsol to detect qrd save type In-Reply-To: <48AACCCC.1090804@codesourcery.com> References: <48AACCCC.1090804@codesourcery.com> Message-ID: <48AAD014.3050707@codesourcery.com> Jules Bergmann wrote: > This patches llsqsol to determine whether to use qrd_saveq (full) or > qrd_saveq1 (skinny), since not all BE's support both. > > Ok to apply? Yes, this looks good. Thanks, Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718 From jules at codesourcery.com Tue Aug 19 16:14:36 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Tue, 19 Aug 2008 12:14:36 -0400 Subject: [patch] Fix matlab io tests Message-ID: <48AAF16C.2050107@codesourcery.com> Adds missing library initialization to tests. Patch applied. -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: mlt.diff URL: From jules at codesourcery.com Tue Aug 19 21:25:10 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Tue, 19 Aug 2008 17:25:10 -0400 Subject: [patch] Adjust correlation test threshold on Cell Message-ID: <48AB3A36.1000404@codesourcery.com> Overlap-add/FFT based correlation is noisier on the Cell due to the round toward zero. Patch applied. -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: corr.diff URL: From jules at codesourcery.com Wed Aug 20 14:26:23 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Wed, 20 Aug 2008 10:26:23 -0400 Subject: [patch] unary elementwise functions Message-ID: <48AC298F.8030201@codesourcery.com> This patches the manual to cover some of the elementwise unary functions (sin, cos, log, exp, sq, mag, etc). See ~jules/tmp/manual.pdf Ok to apply? -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: doc.diff URL: From don at codesourcery.com Wed Aug 20 22:48:46 2008 From: don at codesourcery.com (Don McCoy) Date: Wed, 20 Aug 2008 16:48:46 -0600 Subject: [patch] SSAR support for Cell Message-ID: <48AC9F4E.107@codesourcery.com> This support is really applicable to any big-endian system such as Cell/B.E. or Power. No actual Cell-specific changes are needed other than the changes addressing file I/O issues. Note: Added new data set. The previously named 'set1' is now 'data3' and contains radar data generated with the SCALE factor set to 3 (as before). There is also a new set named 'data1', which sets SCALE to 1. Some other minor enhancements and fixes are included, as detailed in the Changelog. Regards, -- Don McCoy don (at) CodeSourcery (888) 776-0262 / (650) 331-3385, x712 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ssar_cell.changes URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ssar_cell.diff URL: From jules at codesourcery.com Thu Aug 21 12:36:47 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Thu, 21 Aug 2008 08:36:47 -0400 Subject: [patch] Add FFTMs xfails to fft_be Message-ID: <48AD615F.1090204@codesourcery.com> This adds Xfails for FFTMs, and uses them to make lack of cbe double precision fftm expected. Ok to apply? -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fbe.diff URL: From stefan at codesourcery.com Thu Aug 21 12:40:33 2008 From: stefan at codesourcery.com (Stefan Seefeld) Date: Thu, 21 Aug 2008 08:40:33 -0400 Subject: [vsipl++] [patch] Add FFTMs xfails to fft_be In-Reply-To: <48AD615F.1090204@codesourcery.com> References: <48AD615F.1090204@codesourcery.com> Message-ID: <48AD6241.3090805@codesourcery.com> Jules Bergmann wrote: > This adds Xfails for FFTMs, and uses them to make lack of cbe double > precision fftm expected. > > Ok to apply? This looks good. Thanks, Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718 From jules at codesourcery.com Thu Aug 21 19:52:18 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Thu, 21 Aug 2008 15:52:18 -0400 Subject: [patch] Fix ukernels for split complex Message-ID: <48ADC772.3070203@codesourcery.com> Several fixes for ukernels to work with split-complex. Patch applied. -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: uksplit.diff URL: From jules at codesourcery.com Thu Aug 21 21:05:08 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Thu, 21 Aug 2008 17:05:08 -0400 Subject: [patch] Always include csl-docbook/GNUmakefile.inc Message-ID: <48ADD884.2000701@codesourcery.com> The install-pdf rule uses the install_pdf_template defined in csl-docbook's GNUmakefile.inc, ergo the makefile needs to be included even when not in maintainer mode. Patch applied. -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cd.diff URL: From brooks at codesourcery.com Thu Aug 21 21:44:58 2008 From: brooks at codesourcery.com (Brooks Moses) Date: Thu, 21 Aug 2008 14:44:58 -0700 Subject: [vsipl++] [patch] Always include csl-docbook/GNUmakefile.inc In-Reply-To: <48ADD884.2000701@codesourcery.com> References: <48ADD884.2000701@codesourcery.com> Message-ID: <48ADE1DA.4090500@codesourcery.com> Jules Bergmann wrote, at 8/21/2008 2:05 PM: > The install-pdf rule uses the install_pdf_template defined in > csl-docbook's GNUmakefile.inc, ergo the makefile needs to be included > even when not in maintainer mode. > > Patch applied. FWIW, this will be a problem for our distribution of the source package if we decide not to ship csl_docbook with it at some point in the future, as it means that not having a csl_docbook tree will break the build. - Brooks From mark at codesourcery.com Fri Aug 22 00:39:28 2008 From: mark at codesourcery.com (Mark Mitchell) Date: Fri, 22 Aug 2008 01:39:28 +0100 Subject: [vsipl++] [patch] Always include csl-docbook/GNUmakefile.inc In-Reply-To: <48ADE1DA.4090500@codesourcery.com> References: <48ADD884.2000701@codesourcery.com> <48ADE1DA.4090500@codesourcery.com> Message-ID: <48AE0AC0.90102@codesourcery.com> Brooks Moses wrote: > Jules Bergmann wrote, at 8/21/2008 2:05 PM: >> The install-pdf rule uses the install_pdf_template defined in >> csl-docbook's GNUmakefile.inc, ergo the makefile needs to be included >> even when not in maintainer mode. >> >> Patch applied. > > FWIW, this will be a problem for our distribution of the source package > if we decide not to ship csl_docbook with it at some point in the > future, as it means that not having a csl_docbook tree will break the build. We don't want to ship csl_docbook. It's proprietary and it's not really useful to anyone. Our customers certainly don't want to rebuild our docs, and if they try they'll just get annoyed. I think that means we probably have to hack up the Makefiles to avoid relying on csl_docbook when in non-maintainer mode. We get to create an alternative install-pdf rule, I guess? -- Mark Mitchell CodeSourcery mark at codesourcery.com (650) 331-3385 x713 From brooks at codesourcery.com Fri Aug 22 00:44:15 2008 From: brooks at codesourcery.com (Brooks Moses) Date: Thu, 21 Aug 2008 17:44:15 -0700 Subject: [vsipl++] [patch] Always include csl-docbook/GNUmakefile.inc In-Reply-To: <48AE0AC0.90102@codesourcery.com> References: <48ADD884.2000701@codesourcery.com> <48ADE1DA.4090500@codesourcery.com> <48AE0AC0.90102@codesourcery.com> Message-ID: <48AE0BDF.4050202@codesourcery.com> Mark Mitchell wrote, at 8/21/2008 5:39 PM: > Brooks Moses wrote: >> Jules Bergmann wrote, at 8/21/2008 2:05 PM: >>> The install-pdf rule uses the install_pdf_template defined in >>> csl-docbook's GNUmakefile.inc, ergo the makefile needs to be included >>> even when not in maintainer mode. >>> >>> Patch applied. >> FWIW, this will be a problem for our distribution of the source package >> if we decide not to ship csl_docbook with it at some point in the >> future, as it means that not having a csl_docbook tree will break the build. > > We don't want to ship csl_docbook. It's proprietary and it's not really > useful to anyone. Our customers certainly don't want to rebuild our > docs, and if they try they'll just get annoyed. > > I think that means we probably have to hack up the Makefiles to avoid > relying on csl_docbook when in non-maintainer mode. We get to create an > alternative install-pdf rule, I guess? Actually, I suppose we could just copy csl_docbook/GNUmakefile.inc into the final source directory, rather than copying the whole csl_docbook tree there. That's probably the simplest solution for the moment, and I could work on creating an alternate rule once we have everything else working. - Brooks From mark at codesourcery.com Fri Aug 22 00:46:38 2008 From: mark at codesourcery.com (Mark Mitchell) Date: Fri, 22 Aug 2008 01:46:38 +0100 Subject: [vsipl++] [patch] Always include csl-docbook/GNUmakefile.inc In-Reply-To: <48AE0BDF.4050202@codesourcery.com> References: <48ADD884.2000701@codesourcery.com> <48ADE1DA.4090500@codesourcery.com> <48AE0AC0.90102@codesourcery.com> <48AE0BDF.4050202@codesourcery.com> Message-ID: <48AE0C6E.9030500@codesourcery.com> Brooks Moses wrote: > Actually, I suppose we could just copy csl_docbook/GNUmakefile.inc into > the final source directory, rather than copying the whole csl_docbook > tree there. If that works, I certainly have no objection. -- Mark Mitchell CodeSourcery mark at codesourcery.com (650) 331-3385 x713 From brooks at codesourcery.com Fri Aug 22 00:53:50 2008 From: brooks at codesourcery.com (Brooks Moses) Date: Thu, 21 Aug 2008 17:53:50 -0700 Subject: [vsipl++] [patch] Always include csl-docbook/GNUmakefile.inc In-Reply-To: <48AE0C6E.9030500@codesourcery.com> References: <48ADD884.2000701@codesourcery.com> <48ADE1DA.4090500@codesourcery.com> <48AE0AC0.90102@codesourcery.com> <48AE0BDF.4050202@codesourcery.com> <48AE0C6E.9030500@codesourcery.com> Message-ID: <48AE0E1E.9090807@codesourcery.com> Mark Mitchell wrote, at 8/21/2008 5:46 PM: > Brooks Moses wrote: >> Actually, I suppose we could just copy csl_docbook/GNUmakefile.inc into >> the final source directory, rather than copying the whole csl_docbook >> tree there. > > If that works, I certainly have no objection. I just tested; it seems to work fine. - Brooks, already finding gnu-* making his life easier. :) From don at codesourcery.com Fri Aug 22 07:06:50 2008 From: don at codesourcery.com (Don McCoy) Date: Fri, 22 Aug 2008 01:06:50 -0600 Subject: [patch] SSAR operation counts Message-ID: <48AE658A.7040604@codesourcery.com> This patch allows the SSAR application have accurate op counts when using datasets with a scale factor other than 3. Regards, -- Don McCoy don (at) CodeSourcery (888) 776-0262 / (650) 331-3385, x712 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ssar_ops.changes URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ssar_ops.diff URL: From jules at codesourcery.com Fri Aug 22 12:50:21 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Fri, 22 Aug 2008 08:50:21 -0400 Subject: [vsipl++] [patch] SSAR support for Cell In-Reply-To: <48AC9F4E.107@codesourcery.com> References: <48AC9F4E.107@codesourcery.com> Message-ID: <48AEB60D.2000702@codesourcery.com> Don McCoy wrote: > This support is really applicable to any big-endian system such as > Cell/B.E. or Power. No actual Cell-specific changes are needed other > than the changes addressing file I/O issues. > > Note: Added new data set. The previously named 'set1' is now 'data3' > and contains radar data generated with the SCALE factor set to 3 (as > before). There is also a new set named 'data1', which sets SCALE to 1. > > Some other minor enhancements and fixes are included, as detailed in the > Changelog. Don, this looks good, please check it in. -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 From jules at codesourcery.com Fri Aug 22 12:56:57 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Fri, 22 Aug 2008 08:56:57 -0400 Subject: [patch] Config fix for builtin FFT Message-ID: <48AEB799.7010401@codesourcery.com> The builtin FFTW was advertising support for all FFT types (fftw_has_{type}), even when types were disabled. Patch applied. -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fft-cfg.diff URL: From jules at codesourcery.com Fri Aug 22 15:09:42 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Fri, 22 Aug 2008 11:09:42 -0400 Subject: [patch] Vmmul bug fix Message-ID: <48AED6B6.3050409@codesourcery.com> Vmmul was promoting vector/matrix value types before re-dispatching. This confused the IPP (and potentially generic SIMD) evaluators. I found this trying to build the C-VSIP bindings, and extended the vmmul.cpp to provide coverage. Patch applied. -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: vmmul.diff URL: From jules at codesourcery.com Tue Aug 26 02:21:41 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Mon, 25 Aug 2008 22:21:41 -0400 Subject: [patch] alf_fft_split_c Message-ID: <48B368B5.9070204@codesourcery.com> Missing file that should have been committed long ago! Patch applied. -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: as.diff URL: From jules at codesourcery.com Tue Aug 26 03:12:45 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Mon, 25 Aug 2008 23:12:45 -0400 Subject: [patch] autodetect CML libdir Message-ID: <48B374AD.3080408@codesourcery.com> This detects if the libcml.a is in $cml_prefix/lib or $cml_prefix/lib64. I'm manually packaging up an eval CML with the following layout: cml/include headers (shared) cml/lib libraries (32-bit) cml/lib64 libraries (64-bit) this patch lets VSIPL++ take a single cml prefix and find the right library. Ok to apply? -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cfg.diff URL: From stefan at codesourcery.com Tue Aug 26 03:31:41 2008 From: stefan at codesourcery.com (Stefan Seefeld) Date: Mon, 25 Aug 2008 23:31:41 -0400 Subject: [vsipl++] [patch] autodetect CML libdir In-Reply-To: <48B374AD.3080408@codesourcery.com> References: <48B374AD.3080408@codesourcery.com> Message-ID: <48B3791D.50601@codesourcery.com> Jules Bergmann wrote: > This detects if the libcml.a is in $cml_prefix/lib or $cml_prefix/lib64. > > I'm manually packaging up an eval CML with the following layout: > > cml/include headers (shared) > cml/lib libraries (32-bit) > cml/lib64 libraries (64-bit) I take it 'cml' here stands for the installation prefix, e.g. '/usr'. Correct ? > this patch lets VSIPL++ take a single cml prefix and find the right > library. > > Ok to apply? The patch looks good. One little nitpick: > + for trylibdir in $libdirs; do > + AC_MSG_CHECKING([for CML libdir: $with_cml_prefix/$trylibdir]) > + > + CPPFLAGS="$orig_CPPFLAGS -I$with_cml_prefix/include" > + LDFLAGS="$orig_LDFLAGS -L$with_cml_prefix/$trylibdir" > + CPP_SPU_FLAGS="$orig_CPP_SPU_FLAGS -I$with_cml_prefix/include" > + LD_SPU_FLAGS="$orig_LD_SPU_FLAGS -L$with_cml_prefix/$trylibdir" AFAICT, the trylibdir loop only affects LDFLAGS and LD_SPU_FLAGS, so you may keep the definition of CPPFLAGS and CPP_SPU_FLAGS as they were. > + # ALF_LIBRARY_PATH (ALF 3.0) only supports a single path. > + # Create link to CML kernels from VSIPL++ directory. > + # This allows in-tree development. It will not be copied > + # on installation. > + mkdir -p lib > + ln -sf $with_cml_prefix/$cml_libdir_found/cml_kernels.so lib Let's not forget to remove that, eventually, since: 1) $with_cml_prefix may be empty (for example if CML can be found in a default location) and 2) ALF 3.1 will no longer need that. Eventually we'll also have to come back to the point of whether and how to define ALF_LIBRARY_PATH. My personal preference would be to allow SV++ and CML to accumulate search paths and then set them via alf_init(). However, if I remember correctly, ALF_LIBRARY_PATH would, if set, simply override that, instead of complement it. Thus users are required to carry the full set of search paths around. Oh well... Thanks, Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718 From jules at codesourcery.com Tue Aug 26 11:22:54 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Tue, 26 Aug 2008 07:22:54 -0400 Subject: [vsipl++] [patch] autodetect CML libdir In-Reply-To: <48B3791D.50601@codesourcery.com> References: <48B374AD.3080408@codesourcery.com> <48B3791D.50601@codesourcery.com> Message-ID: <48B3E78E.7010103@codesourcery.com> > I take it 'cml' here stands for the installation prefix, e.g. '/usr'. > Correct ? Yes. > AFAICT, the trylibdir loop only affects LDFLAGS and LD_SPU_FLAGS, so you > may keep the definition of CPPFLAGS and CPP_SPU_FLAGS as they were. OK. > Let's not forget to remove that, eventually, since: > > 1) $with_cml_prefix may be empty (for example if CML can be found in a > default location) and This particular code only gets called when the user passes --with-cml-prefix=foo > 2) ALF 3.1 will no longer need that. But yes, that won't be necessary with 3.1. -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 From jules at codesourcery.com Tue Aug 26 12:38:47 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Tue, 26 Aug 2008 08:38:47 -0400 Subject: [patch] Split large tests Message-ID: <48B3F957.9040605@codesourcery.com> Patch applied -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: split-tests.diff URL: From jules at codesourcery.com Tue Aug 26 12:47:35 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Tue, 26 Aug 2008 08:47:35 -0400 Subject: [patch] Fix 64-bit problem in ukernel Message-ID: <48B3FB67.1090302@codesourcery.com> Patch applied. -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: uk64.diff URL: From jules at codesourcery.com Tue Aug 26 12:48:54 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Tue, 26 Aug 2008 08:48:54 -0400 Subject: [patch] update README.cbe and add example configury Message-ID: <48B3FBB6.1030108@codesourcery.com> Patch applied. -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: cbe-cfg.diff URL: From stefan at codesourcery.com Tue Aug 26 13:18:28 2008 From: stefan at codesourcery.com (Stefan Seefeld) Date: Tue, 26 Aug 2008 09:18:28 -0400 Subject: [vsipl++] [patch] Split large tests In-Reply-To: <48B3F957.9040605@codesourcery.com> References: <48B3F957.9040605@codesourcery.com> Message-ID: <48B402A4.1030300@codesourcery.com> Jules Bergmann wrote: > Patch applied As a minor (esthetic) point: I'd suggest to make use of directories, e.g. tests/coverage/binary_mul.cpp etc. QMTest will just DoTheRightThing, and you are even able to get the same granularity as before by running 'qmtest coverage', as directories map to sub-testsuites, so this will expand automatically. Regards, Stefan -- Stefan Seefeld CodeSourcery stefan at codesourcery.com (650) 331-3385 x718 From jules at codesourcery.com Tue Aug 26 20:56:58 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Tue, 26 Aug 2008 16:56:58 -0400 Subject: [patch] Benchmarks with profiling enabled Message-ID: <48B46E1A.5030004@codesourcery.com> This adds a new rule to create benchmarks with profiling enabled. Then the --vsipl++-profile-foo command line options can be used to enable profiling. Ok to apply? -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: bmmf.diff URL: From jules at codesourcery.com Wed Aug 27 07:08:22 2008 From: jules at codesourcery.com (Jules Bergmann) Date: Wed, 27 Aug 2008 03:08:22 -0400 Subject: [patch] Fix DTL size bug in fastconv Message-ID: <48B4FD66.6040304@codesourcery.com> Calls to Task_manager::reserve have a bad habit of passing "true" for the argument indicating the number of DTL entries to allocate. Fastconv needed 6, but was only allocating 1. This fixed the fastconv.cpp failure. Patch applied. -- Jules -- Jules Bergmann CodeSourcery jules at codesourcery.com (650) 331-3385 x705 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fix.diff URL: From don at codesourcery.com Fri Aug 29 16:31:16 2008 From: don at codesourcery.com (Don McCoy) Date: Fri, 29 Aug 2008 10:31:16 -0600 Subject: [patch] Multiply-add user-defined kernel Message-ID: <48B82454.7010309@codesourcery.com> This kernel extends the user-defined kernel framework to allow functions having three inputs and one output. Multiply-add is used as a test case for this. At this time, only scalar floats and complex-interleaved floats are supported. A few other minor corrections are included with this patch. Ok to commit? -- Don McCoy don (at) CodeSourcery (888) 776-0262 / (650) 331-3385, x712 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: uk_madd.changes URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: uk_madd.diff URL: