Prev: Calling .NET from MATLAB
Next: Image Averaging
From: Rune Allnor on 14 Sep 2006 14:40

Scott Seidman skrev:
> "Rune Allnor" <allnor(a)tele.ntnu.no> wrote in news:1158155787.108329.267460
> @p79g2000cwp.googlegroups.com:
>
> > 8. How can i vectorize my code to make matlab run faster?
> >
>
> Back in the day before JIT optimization, vectorization made a HUGE
> difference, and these threads were very interesting as they often involved
> issues of best coding practice specific to Matlab. Today, it's not so
> important, but vectorization can also make code much more readable-- of
> course, it could also make code much more cryptic.

Well, this is one of many "pet peevees"(?). My first professional
degree (BSc) was as a computer engineer. The first three semesters
were spent learning the 8086 virtually on the shift regisetr level.
The next two were spent learning the 286. Then the 386 was
released and I decided that I had better ways of spending my
time that learning a new microprocessor every six months.

The idea behind this detailed training was to squeeze perfomance
out of the available HW. We learned a couple of principles
at the time, which TMW apparently seem to deliberately break.
Variable passing by reference in function calls, and total control
of data types were two of the main themes in the entry level
classes I took.

I was very disappointed when I discovered an article in the
proceedings from some conference I attended some 10 years
ago, where somebody basically presented "vectorization"
as a significant breakthrough when coding some algorithm.

If one does not know basic programming beforehand,
adapting to the idiosyncratics of matlab conditions the
user to never be able to program a computer. "Vectorization"
is one issue, the "never use for loops or while tests"
is another.

> I don't disagree with Matlab intended to be a fast prototyping tool, but I
> don't agree that this was necessarily it's major design issue,

It was. The "fast prototyping tool" was a major PR issue
at least up to matlab 5. In the most recent versions that
factor has been de-emphasised.

> and matlab
> certainly satisfies the needs of many that go far beyond this use.

Maybe. Matlab does not compete very well with respect to
fast program execution.

Rune

From: Scott Seidman on 14 Sep 2006 14:57
"Rune Allnor" <allnor(a)tele.ntnu.no> wrote in
news:1158259215.915274.233250(a)m73g2000cwd.googlegroups.com:

>
> Scott Seidman skrev:
>> "Rune Allnor" <allnor(a)tele.ntnu.no> wrote in
>> news:1158155787.108329.267460 @p79g2000cwp.googlegroups.com:
>>
>> > 8. How can i vectorize my code to make matlab run faster?
>> >
>>
>> Back in the day before JIT optimization, vectorization made a HUGE
>> difference, and these threads were very interesting as they often
>> involved issues of best coding practice specific to Matlab. Today,
>> it's not so important, but vectorization can also make code much more
>> readable-- of course, it could also make code much more cryptic.
>
> Well, this is one of many "pet peevees"(?). My first professional
> degree (BSc) was as a computer engineer. The first three semesters
> were spent learning the 8086 virtually on the shift regisetr level.
> The next two were spent learning the 286. Then the 386 was
> released and I decided that I had better ways of spending my
> time that learning a new microprocessor every six months.
>
> The idea behind this detailed training was to squeeze perfomance
> out of the available HW. We learned a couple of principles
> at the time, which TMW apparently seem to deliberately break.
> Variable passing by reference in function calls, and total control
> of data types were two of the main themes in the entry level
> classes I took.
>
> I was very disappointed when I discovered an article in the
> proceedings from some conference I attended some 10 years
> ago, where somebody basically presented "vectorization"
> as a significant breakthrough when coding some algorithm.
>
> If one does not know basic programming beforehand,
> adapting to the idiosyncratics of matlab conditions the
> user to never be able to program a computer. "Vectorization"
> is one issue, the "never use for loops or while tests"
> is another.
>

There's my pet peeve-- Matlab is a tool that doesn't force us to know
basic programming beforehand-- so we get a ton of "Why doesn't my
floating point equality test work", and many things like this.

But vectorization is an interesting issue. An environment created
specifically for the purpose of manipulating matrices shouldn't require
you to write a nested loop or do a function call to do matrix
multiplication. So, every matrix multiply you do is "vectorization"--
even to just multiply a vector by a constant. It makes the code much
more readable, easier to get right sooner, and easier to debug when you
don't get it right.

Over the years, of course, the "never use for loops or while tests" issue
has almost gone away, with better optimization. This doesn't mean that
I'll reintroduce the nested loop to do matrix multiplies.

In the meantime, "fast" is sort of relative. For all the things I tend
to do, Matlab is "fast enough". Then again, fifteen years ago, I would
run an Fortran-coded optimization on a 386, and come back in the morning
to see if it crapped out overnight. Today, the same optimization runs in
minutes, not seconds.

In the years of gigahertz processors and disks that are hundreds of
gigabytes big (and they need to be-- my last Acrobat install was over
600Mbytes!), there's less and less call for optimization, and more and
more of a call for reduced development time.

--
Scott
Reverse name to reply
From: Richard Brown on 14 Sep 2006 15:17

Duane Hanselman wrote:

> Here's a list of most annoying cssm posts. (Started in a different
> thread.) Please add yours as well as suggested replies. I'd like to
> keep this around so annoying posts can get quick "cut and paste"
> answers.
>
> 3. I'm new at MATLAB and I'm doing a project on "some topic name".
> Please send me anything you have.
> (Or) I'm doing graduate research on "some topic name". Please send me
> the code (so I can my degree).

Maybe we should post a dummy "Matlab codes for speech recognition" on
the FEX to point people to ...

From: PB on 14 Sep 2006 15:37
On 2006-09-14 16:10 Steve Amphlett said the following:
> Duane Hanselman wrote:
>>
>> In reality, what I'd like to see is a header above the list of
>> postings on the Mathworks interface to cssm (right up there with
>> the
>> "Most Active" and "Threads Needing Replies"). This header would be
>> "What NOT to post" and would contain this list or a link to it and
>> simple replies to those things. To be most effective, the list
>> should
>> be right there without making anyone click a link to get to it.
>> That
>> way it stares folks in the face. The replies could appear as links.
>> As it stands now, I don't find much use in the "Most Active" and
>> "Threads Needing Replies" headers. They could be removed in favor
>> of
>> this suggestion?
>
> There could be two links:
>
> FAQs (Frequently asked questions)
> DAQs (Don't ask questions)

Clever! But how are we handling the ones using real newsreaders? (Maybe
they post "real" questions?:-))

/PB

--
"Never attribute to malice that which can be adequately explained by
stupidity."
From: Rune Allnor on 14 Sep 2006 16:17

Scott Seidman skrev:
> "Rune Allnor" <allnor(a)tele.ntnu.no> wrote in
> news:1158259215.915274.233250(a)m73g2000cwd.googlegroups.com:
>
> >
> > Scott Seidman skrev:
> >> "Rune Allnor" <allnor(a)tele.ntnu.no> wrote in
> >> news:1158155787.108329.267460 @p79g2000cwp.googlegroups.com:
> >>
> >> > 8. How can i vectorize my code to make matlab run faster?
> >> >
> >>
> >> Back in the day before JIT optimization, vectorization made a HUGE
> >> difference, and these threads were very interesting as they often
> >> involved issues of best coding practice specific to Matlab. Today,
> >> it's not so important, but vectorization can also make code much more
> >> readable-- of course, it could also make code much more cryptic.
> >
> > Well, this is one of many "pet peevees"(?). My first professional
> > degree (BSc) was as a computer engineer. The first three semesters
> > were spent learning the 8086 virtually on the shift regisetr level.
> > The next two were spent learning the 286. Then the 386 was
> > released and I decided that I had better ways of spending my
> > time that learning a new microprocessor every six months.
> >
> > The idea behind this detailed training was to squeeze perfomance
> > out of the available HW. We learned a couple of principles
> > at the time, which TMW apparently seem to deliberately break.
> > Variable passing by reference in function calls, and total control
> > of data types were two of the main themes in the entry level
> > classes I took.
> >
> > I was very disappointed when I discovered an article in the
> > proceedings from some conference I attended some 10 years
> > ago, where somebody basically presented "vectorization"
> > as a significant breakthrough when coding some algorithm.
> >
> > If one does not know basic programming beforehand,
> > adapting to the idiosyncratics of matlab conditions the
> > user to never be able to program a computer. "Vectorization"
> > is one issue, the "never use for loops or while tests"
> > is another.
> >
>
> There's my pet peeve-- Matlab is a tool that doesn't force us to know
> basic programming beforehand-- so we get a ton of "Why doesn't my
> floating point equality test work", and many things like this.
>
> But vectorization is an interesting issue. An environment created
> specifically for the purpose of manipulating matrices shouldn't require
> you to write a nested loop or do a function call to do matrix
> multiplication. So, every matrix multiply you do is "vectorization"--
> even to just multiply a vector by a constant. It makes the code much
> more readable, easier to get right sooner, and easier to debug when you
> don't get it right.

Sure. It's brilliant for matrices. The problems occur for more general
programming problems.

> Over the years, of course, the "never use for loops or while tests" issue
> has almost gone away, with better optimization.

I don't like this issue because it conditions novice programmers to
not use algorithmic structures that are basic to any sort of
programming.

> This doesn't mean that
> I'll reintroduce the nested loop to do matrix multiplies.

Well, I made a C++ overload operator to multiply matrices
in one of my first programming projects. It did make the code
a lot easier to read. And I learned the significance of the C/C++
"inline" compiler directive along the way.

But there is a difference between making the code more compact,
and not thinking in terms of these programming primitives.

> In the meantime, "fast" is sort of relative. For all the things I tend
> to do, Matlab is "fast enough". Then again, fifteen years ago, I would
> run an Fortran-coded optimization on a 386, and come back in the morning
> to see if it crapped out overnight. Today, the same optimization runs in
> minutes, not seconds.

Been there, done that.

My point is merely that people like you and I, who have done these
sorts of things in a variety of ways, have made informed choises
about what to use. When we use matlab, we know what we get
and what we give up.

Recently, lots of posts give the impression that people don't
have that knowledge these days.

> In the years of gigahertz processors and disks that are hundreds of
> gigabytes big (and they need to be-- my last Acrobat install was over
> 600Mbytes!), there's less and less call for optimization, and more and
> more of a call for reduced development time.

Maybe I'm working with the wrong problems. Lots of data processing,
very little time to do the job. I know it is realistic to speed the job
up
a factor 10 - 50 by using C++ instead of matlab. Lots of details in the
processing history is a lot easier to keep track of when using one,
integrated processing system.

Nah, matlab is a very good testbed for algorithms (as well as an
"OS-in-a-can" when you don't have anything else), but it has its
limits.

Rune

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6
Prev: Calling .NET from MATLAB
Next: Image Averaging