Lessons Learned part 1.

I thought I would share some lessons learned while coding freemat. The first lesson is due to Samit.

#include 

class A {
 int m_data;
public:
 A(int m) : m_data(m) {std::cout << "Construct A: " << m_data << "\n";}
 const int & value() const { return m_data;}
 const A doubled() const {return A(2*m_data);}
 ~A() {std::cout << "Destruct A: " << m_data << "\n";}
};

int main() {
 A x(5);
 const int &y(x.doubled().doubled().value());
 std::cout << "y = " << y << "\n";
 return 0;
}

The result:

$ ./temp
Construct A: 5
Construct A: 10
Construct A: 20
Destruct A: 20
Destruct A: 10
y = 20
Destruct A: 5

Note that the temporary object "A" is destructed _before_ the const
ref to it's internals is used. So...

int main() {
 A x(5);
 const A &t(x.doubled().doubled());
 const int &y(t.value());
 std::cout << "y = " << y << "\n";
 return 0;
}

yields:

$ g++ -o temp temp.cpp
$ ./temp
Construct A: 5
Construct A: 10
Construct A: 20
Destruct A: 10
y = 20
Destruct A: 20
Destruct A: 5

Yikes.

Progress update

Eugene's list:
(Done) 1. Finish "patch" command implementation.
(Done) 2. Implement "hist".
3. Try porting statistics and imaging toolbox from octave-forge (by request).
(Half-way done) 4. Re-enable OpenGL rendering. Add command to switch between Qt and OpenGL rendering. Debug an issue that was reported earlier - slowdown with OpenGL rendering.
5. Look at upgrading to LLVM 2.3 (or 2.4 if it is released by then.)

Samit is also making good progress on the new array class, and new type system implementation. He says that many of the unit test pass.

TODO:

I thought I should publish our current ToDo list:

Samit is finishing new array class migration. He says he should be done in a month or so.

Eugene's list:
1. Finish "patch" command implementation.
2. Implement "hist".
3. Try porting statistics and imaging toolbox from octave-forge (by request).
4. Re-enable OpenGL rendering. Add command to switch between Qt and OpenGL rendering. Debug an issue that was reported earlier - slowdown with OpenGL rendering.
5. Look at upgrading to LLVM 2.3 (or 2.4 if it is released by then.)

Rant

Sometimes, Matlab language drives me nuts. It appears that software engineers just went for the most illogical and incorrect design decisions. Here's an example:

int16(100000000) returns 32767 (So, in Matlab integers are not a group. Why not go for modular arithmetic?)

int16(1)+0.4 returns an answer of class int16 (So, Matlab demotes(!) types in arithmetic expressions.)

(int16(1)+0.4)+0.4 returns 1, but
int16(1)+(0.4+0.4) returns 2 (So, in Matlab addition is not associative!)


Why? Oh, Why?

What we are working on...

I thought I would post an update:

Samit is finishing up new array class. The new arrays will simplify writing matlab functions and improve performance.

I've been trying to fix a very annoying bug - zooming on a image has unpredictable results. In the process I'm cleaning up some handle graphics code. I think I'm going to cleanup more code in libgraphics.

Why JIT? How to JIT?

I started using Matlab circa version 4 and I still cringe every time I have to write a loop in Matlab. The main reason is that I got conditioned (like the generations of matlab users) that loops are really slow because they have to be interpreted. Matrix or index operations on the other hand turn into internal function calls and are fast. The old view - almost always using clever indexing one can avoid loops. However, this is 21st century and we have better ways...

The goal for using JIT (just-in-time compilation) is to speed up interpreted code by compiling it in run time. This is very tricky for dynamic languages such as Matlab (also Python, Perl, etc. ). The main reason is that the variable types are determined at runtime. For example:

for j=1:10
  if j > 5
      a = int8(j);
  else
      a = float(j);
  end
end

What's the type of a? Compiler has to know the variable size and type to emit correct code. One can imagine using an object to represent variables (the object would carry a type and pointer to memory where data is stored) and assignement operator which would assign both value and type. However, such implementation results in code that is not much faster than interpreted code.

However, code like the snippet above is rare. In most cases variables have well defined type at runtime. For such a code we can generate very fast machine code.

Here's the current approach that FreeMat takes is:

• Compile code that would most benefit from speedup (loops, functions)
• If code cannot be compiled fall back to using the interpreter (slow, but at least you always get an answer).
• Check for variable type changes between running JIT compiled code.
• JIT compiled code works on the same data structures as the interpreter.

Samit and I looked at three jit compilers: Java JIT, Mono JIT, and LLVM. Java JIT seemed better suited for Java language. Mono JIT isn't mature.

LLVM was our choice. It is not perfect - the library is really huge and quite hard to compile and use. However, you can generate and optimize code on the fly and get near optimal performance (the only thing you can't do with JIT code is interprocedural optimizations).

We plan to have functional JIT compiler in Freemat 4.

What's coming in version 4.

I just wanted to update on the current Freemat developments. We are planning some major changes for version 4:

• Just-In-Time compiler.
  
• Type system compatible with Matlab.
• New build system using cmake (native build using Visual Studio Express under Windows).
• Dynamic linking with BLAS libraries.

The development is happening in two branches FreeMat4 and array_rework. Check it out!

Freemat 3.6 on the horizon

Freemat team is working on the 3.6 release. This is planned as a bugfix release. Well, a few compatibility changes will thrown in too.

The release is planned for early March. Stay tuned....