Path: news.mathworks.com!newsfeed-00.mathworks.com!nlpi057.nbdc.sbc.com!prodigy.net!news.glorb.com!news2.glorb.com!postnews.google.com!h31g2000yqd.googlegroups.com!not-for-mail
From: Rune Allnor <allnor@tele.ntnu.no>
Newsgroups: comp.soft-sys.matlab
Subject: Re: Segmentation violation due to MEX code
Date: Mon, 6 Jul 2009 21:18:23 -0700 (PDT)
Organization: http://groups.google.com
Lines: 68
Message-ID: <b71bb73a-66fd-424e-8b5b-8d82aa1cd293@h31g2000yqd.googlegroups.com>
References: <h2tkfd$l84$1@fred.mathworks.com> <5b6d0b68-60e9-41be-a22f-ea755e2db20d@r33g2000yqn.googlegroups.com> 
	<h2tmbf$t3o$1@fred.mathworks.com> <h2tn3p$kpc$1@fred.mathworks.com> 
	<h2tnu1$dng$1@fred.mathworks.com> <h2togo$mdd$1@fred.mathworks.com> 
	<h2tos2$fdt$1@fred.mathworks.com>
NNTP-Posting-Host: 77.17.26.240
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Trace: posting.google.com 1246940303 16524 127.0.0.1 (7 Jul 2009 04:18:23 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Tue, 7 Jul 2009 04:18:23 +0000 (UTC)
Complaints-To: groups-abuse@google.com
Injection-Info: h31g2000yqd.googlegroups.com; posting-host=77.17.26.240; 
	posting-account=VAp5gAkAAAAmkCze5hvZtMeedpZWNthI
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; 
	Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 
	3.5.21022),gzip(gfe),gzip(gfe)
Xref: news.mathworks.com comp.soft-sys.matlab:553281


On 6 Jul, 23:04, "Jose Antonio " <jurig...@gmail.com> wrote:
> Jaja, sorry I misunderstood
>
> The difference is not great though, but the solution you advised with accumarray takes around 1s in the best case (only that part of the code), while the MEX always takes 0.6s
>
> I mean best for accumarray because it looks like it speeds up, as if Matlab had to warm up or something. The first time I call the routine it takes like 3s, and then fixes to around 1s. But the MEX code is always twice as fast.

It can get even faster. From your first post:

        for (i = 0; i < yRows; i++)
            for (j = 0; j < yCols; j++)
            {
                index = i * yCols + j;
                if (index >= ySize)
                    printf("Wrong\n");
                else if (m == y[index])
                {
======>>>>>>        num += e[j] * x[i];
                    den++;
                 }
            }
        if (den == 0) I[m] = num;
        else I[m] = num / den;

The line I have marked out shows a computation
bewteev e[j] and x[i]. The loop ove j is inside
the loop over i, meaning that you multiply with
the same number x[i] j times.

Instead, move that computation out of the loop
over j, and multiply num by x[i] at the end,
before you use it.

Depending on what compiler you use, this may or
may not have an impact on run-time. A state-of-
the-art compiler might detect this and automatically
move x[i] outside the loop over j. With a simpler
compiler (LCC, which comes with matlab, is not
expected to be very advanced) you might have to
reorganize the code yourself.

Second, change the order of the if-else tests
in the last two lines above. If the code above
is correct, there are not very many cases where
den == 0, so the likelihood that the test actually
matches is very small.

However, since the test for den==0 has to be done
every time, and the alternative case is an else
statement, you loose some time here.

Instead, write

        if (den != 0) I[m] = num / den;
        else I[m] = num;

This way you skip the evaluaition of the else
statement most of the time.

And yes: Loose the PRINTF statements! You don't
need them, and they gobble ridiculous amounts
of time.

Don't be surprised if, after these modifications,
your routine run in less than 5% of the ACCUMARRAY
variant.

Rune