Beginner's problem with MEX -files
in [Matlab]
|
From: Rune Allnor on 5 Jul 2010 08:29 On 5 Jul, 13:42, "Aristeidis " <aris...(a)hotmail.com> wrote: > > Wait with the thanks till you have tested the idea. > > > > > Don't be surprised if this cuts run-time with less than 50% > > of what you do now. Constructing the input cell array X will > > take at least as long (probably several times as long) as > > the time James' code saves. > > > Do away with the cell array X in the first place. Once you find > > out how to do *that*, you can hope to see some *real* speeds > > improvements. > > > Rune > > Rune, I ve taken your comments on board. I ll have to research on that a little bit. Cell arrays are possibly not ideal as you say, but on the other hand having tried structures I wouldn't say these are ideal either. To my knowledge there isn't anything else in Matlab that can hold multiple matrices of values in such a structured way. I could be wrong? You told me earlier that you know C and / or C++. I've taken your word for it, but you might want to reconsider if you will want to stand by that claim. The point is that the structures / cell arrays might not be needed at all. A proficient C(++) programmer would look for an on-line solution: Instead of spending huge resources (both time and memory) on storing large amounts of intermediate results, he would do the computations inside the loop and store only the end result Y. So the natural thing to do in C(++) is to take one or two steps back from the problem you have asked about, and instead try and avoid to produce the cell array X at all, by computing the desired results Y (and possibly any further refinements) directly from the raw data that go into X. Again, you haven't said anything about the actual task at hand here, so I might be wrong with the details. But the overall approach of cutting straight through to the end result is the desired C(++) strategy for obtaining speed. Rune
From: Aristeidis on 5 Jul 2010 09:17 Rune Allnor <allnor(a)tele.ntnu.no> wrote in message <9efd9955-2212-4b05-a2ff-924e8645232a(a)r27g2000yqb.googlegroups.com>... > On 5 Jul, 13:42, "Aristeidis " <aris...(a)hotmail.com> wrote: > > > Wait with the thanks till you have tested the idea. > > > > > > > > > Don't be surprised if this cuts run-time with less than 50% > > > of what you do now. Constructing the input cell array X will > > > take at least as long (probably several times as long) as > > > the time James' code saves. > > > > > Do away with the cell array X in the first place. Once you find > > > out how to do *that*, you can hope to see some *real* speeds > > > improvements. > > > > > Rune > > > > Rune, I ve taken your comments on board. I ll have to research on that a little bit. Cell arrays are possibly not ideal as you say, but on the other hand having tried structures I wouldn't say these are ideal either. To my knowledge there isn't anything else in Matlab that can hold multiple matrices of values in such a structured way. I could be wrong? > > You told me earlier that you know C and / or C++. I've taken > your word for it, but you might want to reconsider if you > will want to stand by that claim. > > The point is that the structures / cell arrays might not be > needed at all. A proficient C(++) programmer would look for > an on-line solution: Instead of spending huge resources (both > time and memory) on storing large amounts of intermediate > results, he would do the computations inside the loop and > store only the end result Y. > > So the natural thing to do in C(++) is to take one or two > steps back from the problem you have asked about, and instead > try and avoid to produce the cell array X at all, by computing > the desired results Y (and possibly any further refinements) > directly from the raw data that go into X. > > Again, you haven't said anything about the actual task at > hand here, so I might be wrong with the details. But the > overall approach of cutting straight through to the end result > is the desired C(++) strategy for obtaining speed. > > Rune Rune, I said (please scroll up and read) I have basic knowledge in C++. I never said or claimed to be proficient in C++. I asked you a couple of times if there is another way in MATLAB (Matlab not C++) to hold pixel values of an area and calculate a simple max value over this area of an image (apart from cells and structures) and you bring C++ up. But that is why I asked the original question here anyway! Given that you can do all sorts of other nice things in C++ would it perhaps be better to look at mex files and/or what are the best strategies/tutorials out there to build a mex file? Also, I presented the actual for loop as requested and then James responded with some strategies and that is what I wanted, some things to think and experiment on... Finally, don't forget that I obviously need to keep the pixel values themselves as well for my application, isn't that brighter than the sun? I ve mentioned several times, store/hold pixel values and calculate max.
From: Rune Allnor on 5 Jul 2010 09:50 On 5 Jul, 15:17, "Aristeidis " <aris...(a)hotmail.com> wrote: > Rune Allnor <all...(a)tele.ntnu.no> wrote in message <9efd9955-2212-4b05-a2ff-924e86452...(a)r27g2000yqb.googlegroups.com>... > > On 5 Jul, 13:42, "Aristeidis " <aris...(a)hotmail.com> wrote: > > > > Wait with the thanks till you have tested the idea. > > > > > Don't be surprised if this cuts run-time with less than 50% > > > > of what you do now. Constructing the input cell array X will > > > > take at least as long (probably several times as long) as > > > > the time James' code saves. > > > > > Do away with the cell array X in the first place. Once you find > > > > out how to do *that*, you can hope to see some *real* speeds > > > > improvements. > > > > > Rune > > > > Rune, I ve taken your comments on board. I ll have to research on that a little bit. Cell arrays are possibly not ideal as you say, but on the other hand having tried structures I wouldn't say these are ideal either. To my knowledge there isn't anything else in Matlab that can hold multiple matrices of values in such a structured way. I could be wrong? > > > You told me earlier that you know C and / or C++. I've taken > > your word for it, but you might want to reconsider if you > > will want to stand by that claim. > > > The point is that the structures / cell arrays might not be > > needed at all. A proficient C(++) programmer would look for > > an on-line solution: Instead of spending huge resources (both > > time and memory) on storing large amounts of intermediate > > results, he would do the computations inside the loop and > > store only the end result Y. > > > So the natural thing to do in C(++) is to take one or two > > steps back from the problem you have asked about, and instead > > try and avoid to produce the cell array X at all, by computing > > the desired results Y (and possibly any further refinements) > > directly from the raw data that go into X. > > > Again, you haven't said anything about the actual task at > > hand here, so I might be wrong with the details. But the > > overall approach of cutting straight through to the end result > > is the desired C(++) strategy for obtaining speed. > > > Rune > > Rune, I said (please scroll up and read) I have basic knowledge in C++. I never said or claimed to be proficient in C++. Then go back to my first response, where I told you to learn C(++). If you want to go MEX, then you need to learn the language you want to use. > I asked you a couple of times if there is another way in MATLAB (Matlab not C++) to hold pixel values of an area and calculate a simple max value over this area of an image (apart from cells and structures) and you bring C++ up. No, you didn't. You asked about increasing speed by using MEX. I told you to make a choise, based on your proficiency with the languages: Either stick with matlab and pay the run-time price, or learn how to do things in the language you want to use for MEX. > But that is why I asked the original question here anyway! Given that you can do all sorts of other nice things in C++ would it perhaps be better to look at mex files and/or what are the best strategies/tutorials out there to build a mex file? Which is the wrong question to ask. What you want to do, is to ask two questions: 1) What is the preferred way to do what one wants in the MEX language of choise? 2) How can one integrate the best practice C(++) approach into matlab? > Also, I presented the actual for loop as requested and then James responded with some strategies and that is what I wanted, some things to think and experiment on... Again, which was the wrong answer. I am sure you are aware of the old adage "one can give a hungry man a fish, and he will not starve for the rest of the day. Or one can teach him how to fish, and he will never again starve." > Finally, don't forget that I obviously need to keep the pixel values themselves as well for my application, isn't that brighter than the sun? I ve mentioned several times, store/hold pixel values and calculate max. You have said that you *do* store the pixels. You haven't said anything about *why* you need the cell array X. There might be some computations needed and some intermediate results required, but as I said yesterday, one can not possibly do these things less efficiently than what you presently do. Some numbers were emntioned where run times were decreased from 6s to 0.1s or so. If you are only searching for maxima in images, this kind of thing should be possible to do in time scales on the order of 0.001s, with image sizes on the order of 1000x1000 pixels. Rune
From: Steve Amphlett on 5 Jul 2010 11:51 Rune Allnor <allnor(a)tele.ntnu.no> wrote in message <75812221-0090-44e4-a33a-46fab1d8a82a(a)k39g2000yqb.googlegroups.com>... > > Again, which was the wrong answer. I am sure you are aware of > the old adage "one can give a hungry man a fish, and he will > not starve for the rest of the day. Or one can teach him how > to fish, and he will never again starve." Teach a man to fish and he'll come back for a refresher course every time he's actually hungry. He'll also blame you for anything that goes wrong with his fishing equipment and expect you to sort it out for him.
From: Rune Allnor on 5 Jul 2010 12:15
On 5 Jul, 17:51, "Steve Amphlett" <Firstname.Lastn...(a)Where-I- Work.com> wrote: > Rune Allnor <all...(a)tele.ntnu.no> wrote in message <75812221-0090-44e4-a33a-46fab1d8a...(a)k39g2000yqb.googlegroups.com>... > > > Again, which was the wrong answer. I am sure you are aware of > > the old adage "one can give a hungry man a fish, and he will > > not starve for the rest of the day. Or one can teach him how > > to fish, and he will never again starve." > > Teach a man to fish and he'll come back for a refresher course every time he's actually hungry. That's what consultancy is all about... > He'll also blame you for anything that goes wrong with his fishing equipment and expect you to sort it out for him. I never said anything about giving him tools; only about teaching how to use whatever tools he might happen to come across. ;) Rune |