Wednesday, October 14, 2009

FreeMat 4.0 Release

We are pleased to announce the release of FreeMat 4.0 . This version brings major feature improvements and also changes to the internals of FreeMat. Here is a list of changes:

  • Improved Editor with integrated debugger
  • Improved Main Application UI with dockable workspace browser and command history:
  • Just In Time compiler (enabled by default)
  • Greatly improved compatibility with Matlab (over 366 compatibility tests pass)
  • Dynamic linking with BLAS (users can use custom optimized BLAS libraries)
  • Vectorized fprintf, sprintf, fscanf, sscanf functions
  • Added patch handle graphics object
  • Much faster figure drawing
  • Ability to handle huge arrays (more than 2GB) when compiled under 64 bit OS
  • Code profiler

Internal changes:

  • New array class implementation
  • Compatible type handling
  • JIT compiler. See an older post for details.
  • CMake build system

You can download the new 4.0 release as usual from our Sourceforge.net Download page.


Thursday, August 21, 2008

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.

Saturday, August 9, 2008

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.

Sunday, July 20, 2008

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.)

Monday, April 14, 2008

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?

Thursday, April 3, 2008

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.

Friday, February 29, 2008

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.