Reading all the angry posts about OpenGL 3.0 like the slashdot discussion or this post by Irrlicht3D developer Nikolaus Gebhardt it looks like that...

Seriously, why is anybody using Microsoft Outlook and Exchange? Outlook is really bad compared to other email programs (no other program was complaining when the inbox had more than 1000 mails...), and it's not even working properly:

Some days ago my Outlook just stopped to receive emails from the Exchange server. Webmail works fine, and Outlook says it is connected to the server. I tried to change the server settings to the initial settings, and guess what: You can not change the URL of an Exchange server in Outlook!

I think I'll just use webmail (Outlook Web Access) again, at least it works. Sometimes.

Somehow I am not so confident that openmoko will ever deliver an open, working mobile phone platform when I read blog postings like this and this. The project is running for almost two years now, and now they start developing the framework? Even if they are able to sell a working smartphone this year (which I still doubt), they are pretty late. What a pity, I thought this was a pretty cool project.

Oops, I almost missed it. Today is CSS Naked Day.

As you can see, davidtanzer.net doesn't look too good without CSS, so I'll have to correct my theme for next year... If I don't forget ;)

I have now decided to write my own unit testing framework because I did not find a suitable one. I want to add special assert functions for testing vectors, matrices, maybe acceleration structures, and so on. A simple unit test suite looks like this:

#include <unittest/unittest.h>
#include <unittest/assert.h>
#include <core/gre_math.h>
#include <core/geometry.h>

void gre_mathtest_setup() {
	
}

void gre_mathtest_teardown() {
	
}

void gre_mathtest_vector_dot_vector() {
	gre_vector4d v1 __attribute__((aligned(16)));
	gre_vector4d v2 __attribute__((aligned(16)));
	v1.x=2; v1.y=3; v1.z=4; v1.w=5;
	
	v2.x=1; v2.y=0; v2.z=0; v2.w=0;
	gre_assert_float_equals(gre_math_vector_dot_vector(&v1, &v2),
			2, 0.00001, "Vector product [2,3,4,5]*[1,0,0,0]");
	v2.y=1;
	gre_assert_float_equals(gre_math_vector_dot_vector(&v1, &v2),
			5, 0.00001, "Vector product [2,3,4,5]*[1,1,0,0]");
	v2.z=1;
	gre_assert_float_equals(gre_math_vector_dot_vector(&v1, &v2),
			9, 0.00001, "Vector product [2,3,4,5]*[1,1,1,0]");
	v2.w=1;
	gre_assert_float_equals(gre_math_vector_dot_vector(&v1, &v2),
			14, 0.00001, "Vector product [2,3,4,5]*[1,1,1,1]");
}

int main(int argc, char **argv) {
	int num_test_functions=1;
	test_function mathtest_functions[] = {
			{ "vector_dot_vector", gre_mathtest_vector_dot_vector }
	};
	
	gre_unittest_register_test_case("mathtest", gre_mathtest_setup, 
			num_test_functions, mathtest_functions, gre_mathtest_teardown);
	
	gre_unittest_run_testsuite();
}

Does anybody know a good Unit Testing Framework? I have had a look at CUnit which seems nice, but the license is LGPL and I would prefer a AL2 or compatible license. I also have checked out CuTest (ZLib license, but it looks a little bit strange) and RCUnit (GPL, so not an option).

All three frameworks are really simple, so it should only be a matter of a few days to write my own, and I am seriously considering doing that.

Yesterday I had a long discussion on ICQ with Andreas Krennmair who questioned the results of my previous C / C++ Benchmark. We found out that the mistake I made was to leave both functions empty, so the C compiler completely removed the function while the C++ compiler did not. AK has added return rand()%2 to both functions and re-did the tests. You can find the corrected results in his blog entry Performance of C vs. C++. So, thanks Andreas for pointing it out and correcting my benchmark results.

Update: C++ is not 7 times faster, only a little bit, here is the follow up article.

I recently did some benchmarking for my diploma thesis which will be about photo realistic rendering. The question now was wether to implement it in C or in C++. Although I already did some C vs. C++ benchmarks they were not specific enough for me to help me with that decision. I decided to implement 2 small example programs which test how fast the method calls for ray/triangle intersections would be.

The C version ran in 5.028sec and the C++ version took 35.89sec, so the C version was more than 7 times faster. I know this is not entirely fair because in my example programs the C compiler can inline the function call while the C++ compiler can not. Anyway, I think I'll stick with C and implement the version where inlining is possible.

Here's the code:

#ifndef __BENCHMARK_C_H_
#define __BENCHMARK_C_H_

#include 
#include 

typedef struct Vertex3D {
	float x;
	float y;
	float z;
} Vertex3D;

typedef struct GeometryObjectInfo {
	
} GeometryObjectInfo;

typedef struct GeometryObject {
	GeometryObjectInfo *info;
	int type;
} GeometryObject;

typedef struct Triangle {
	GeometryObjectInfo *info;
	int type;
	Vertex3D point1;
	Vertex3D point2;
	Vertex3D point3;
} Triangle;

inline int intersectTriangle(Triangle *triangle, 
		Vertex3D *start, Vertex3D *direction) {
	return 0;
}

#endif /* __BENCHMARK_C_H_ */

#ifndef __BENCHMARK_CPP_H_
#define __BENCHMARK_CPP_H_

class Vertex3D {
private:
	float x;
	float y;
	float z;
	
public:
	Vertex3D(float x, float y, float z) {
		this->x=x;
		this->y=y;
		this->z=z;
	}
	
	Vertex3D() {
		
	}
};

class Ray {
	
};

class GeometryObjectInfo {
	
};

class GeometryObject {
private:
	GeometryObjectInfo *info;
public:
	virtual bool intersect(Ray *ray)=0;
	virtual ~GeometryObject() {
		
	}
};

class Triangle : public GeometryObject {
private:
	Vertex3D point1;
	Vertex3D point2;
	Vertex3D point3;
public:
	virtual inline bool intersect(Ray *ray) {
		return false;
	}
};

#endif /* __BENCHMARK_CPP_H_ */

#include <stdio.h>
#include <sys/types.h>
#include <sys/timeb.h>
#include "benchmark.h"

int main(int argc, char **argv) {
	struct timeb start;
	struct timeb end;
	Triangle triangle;
	triangle.type=0;
	Vertex3D vertex;
	Vertex3D *startV=&vertex;
	Vertex3D *direction=&vertex;
	GeometryObject *object = (GeometryObject *)&triangle;
	int i,j;
	
	fprintf(stdout, "Size of triangle: %d\n", sizeof(Triangle));
	ftime(&start);
	for(j=0; j<10000; j++) {
		for(i=0; i<1000000; i++) {
			switch(object->type) {
			case 0:
				intersectTriangle((Triangle *)object, 
					startV, direction);
				break;
			default:
				//Error...
				break;
			}
		}
	}
	ftime(&end);
	double time = end.time-start.time;
	time *= 1000;
	time += end.millitm-start.millitm;
	time /= 1000;
	fprintf(stdout, "Intersect Method Calls: %lf\n", time);
}

#include <stdio.h>
#include <sys/types.h>
#include <sys/timeb.h>
#include "benchmark.h"

int main(int argc, char **argv) {
	struct timeb start;
	struct timeb end;
	
	fprintf(stdout, "Size of triangle: %d\n", 
		sizeof(Triangle));
	Triangle *triangle = new Triangle();
	GeometryObject *object = triangle;
	Ray *ray = new Ray();
	ftime(&start);
	for(int j=0; j<10000; j++) {
		for(long i=0; i<1000000; i++) {
			object->intersect(ray);
		}
	}
	ftime(&end);
	double time = end.time-start.time;
	time *= 1000;
	time += end.millitm-start.millitm;
	time /= 1000;
	fprintf(stdout, "Virtual Method Calls: %lf\n", time);
}

Austrian polititians are planning to allow remote searches of computers without the knowledge of the owners. We think that this is unethical and against other austrian laws. At http://onlinedurchsuchung.at we want to inform about this law (German language only) and start a petition against it.

I know the banners and buttons still look a little bit ugly, but this will probably change soon. We already have some information online and have started to collect links to news articles and other information about remote searches. For people who want to participate (for example sending us interesting links or discussing with us or doing some work) we have created two mailing lists.

We are currently looking for people who want to help, so if you are interested just subscribe to the mailing lists!

Just about once a year I meet sombody who says that one can optimize certain things (like for-loops or equals-methods) in Java using Exceptions instead of the normal control structures. I always try to tell them that they are wrong, using arguments like "Exception handling is painfully slow" or "you just have prevented the JIT to perform an important optimization", but most of the times I fail to convince them. By the way, I still think the most important argument against such "optimizations" is Use Exceptions only when an error has occured.

I have written some small benchmarks which demonstrate some interesting points. All timing measurements were done using YourKit Java Profiler 6.0.16, the program was running in Java 1.5.0_07 on a MacBook Pro (OS X 10.4.10). If you find any mistakes I made please email me (mail-at-davidtanzer-dot-net) - unfortunately I had to disable anonymous comments because of comment spam.

I did all the for loop tests with ARRAY_LENGTH=10 000 000 (JIT) and ARRAY_LENGTH=1 000 000 (JIT and Interpreter Only: -Xint), the Exception benchmarks were only done with the "Small" array length.

The argument for the optimization I want to debunk here goes like this:

For loops which iterate over an array waste lots of time

...because the array length is checke twice - int the for - condition and during each array element access. We could simply eliminate the check in the loop condition and wait for the ArrayIndexOutOfBoundsException which must be faster for large arrays:

	private int f(int i) {
		return i;
	}

	private void testForLoop() {
		int[] array = new int[ARRAY_LENGTH];
		
		for(int i=0; i<array.length; i++) {
			array[i] = f(i);
		}
	}

	private void testForLoopException() {
		int[] array = new int[ARRAY_LENGTH];
		
		try {
			for(int i=0;; i++) {
				array[i] = f(i);
			}
		} catch(ArrayIndexOutOfBoundsException e) {
			//Obviously the loop is finished. Or a real error has occured, we can't know that.
		}
	}

I have made a second benchmark which invokes the 2 methods 100 times to see if the JIT optimizes the loops better when they become a hot spot:

We see here that the Exception version is always slower.

...but exception handling is fast, creating the Exceptions is slow

...so if we could speed up Exception creation we could really optimize things this time. Well, this is also not true. While exception handling in Java causes no runtime overhead as long as everything works, It takes quite some time to find and invoke the exception handler:

	private void createAndThrowExceptions() {
		for(int i=0; i<ARRAY_LENGTH; i++) {
			try {
				throwException();
			} catch(ArrayIndexOutOfBoundsException e) {
				//Empty
			}
		}
	}

	private void throwException() {
		throw new ArrayIndexOutOfBoundsException(Integer.toString(0));
	}

	private void createExceptions() {
		for(int i=0; i<ARRAY_LENGTH; i++) {
			//The message of an AIOOBE is the index which was out of bounds
			Exception e = new ArrayIndexOutOfBoundsException(Integer.toString(0));
		}
	}

So again, throwing and catching takes up most of the time.

...but still we waste time during creation

...because the slowest thing when creating exceptions is filling in the stack trace.

	private class MyException extends Exception {
		private static final long serialVersionUID = 1L;
		@Override
		public synchronized Throwable fillInStackTrace() {
			return this;
		}
		public MyException() {
			super();
		}
		public MyException(String arg0, Throwable arg1) {
			super(arg0, arg1);
		}
		public MyException(String arg0) {
			super(arg0);
		}
		public MyException(Throwable arg0) {
			super(arg0);
		}
	}

	private void createExceptionsWithoutStacktrace() {
		for(int i=0; i<ARRAY_LENGTH; i++) {
			//The message of an AIOOBE is the index which was out of bounds
			Exception e = new MyException(Integer.toString(0));
		}
	}

So here we have not saved much time and have completely lost the stack trace. Not a good thing, IMHO.

Conclustion

Don't use exceptions for optimization. Don't try to be smarter than the JIT.

ExceptionLargeSet
ExceptionSmallSet
ExceptionLargeSet - Interpreter Only