Category: .net

Categories
.net c# nemo Programming

Improving latency while keeping your sanity

We had this problem in Nemo 0.2.0 that it would use quite a lot of cpu while it was indexing. I kind of knew this could happen but hoped that a transaction optimization to the database could improve the performance enough to make this problem irrelevant. Sadly it did not. The indexing code works by running an event loop in a single thread and then having two queues, one for tasks that needs to be completed fast and one for background tasks. Each of the queues are basically just a list of function pointers that is popped when a new task need to run.

The nice property of the indexing code is that it would put each task into simple function that one could read from start to end. The same property that is usually associated with programming using threads compared to programming using events where the code has to be broken into several parts. I feared that I had to go the event way and break the indexing up into smaller functions and do a lot of tedious book keeping to make sure the code could be resumed.

After thinking about the problem for a little while it dawned on me that this is the a perfect case for yielding. Yielding allows you to suspend the execution of a function and return immediately which is perfect for this problem since the runtime will automatically do all the book keeping for you. Another really nice thing is that it turns out that converting the code was extremely simple.

Instead of storing simple function pointer in the queue, we just store an object of type IEnumerable<bool> which will wrap the function and make sure we can call it multiple times. When the Enumerable is called it will keep returning true as long as there’s still work to do in the function wrapped. So the function could just return false and it would work the exact same way as it did before. So one can think of the IEnumerable as a sort of higher order function.

So we just need to wrap the normal functions with the following code:

private IEnumerator TurnEnumerableIntoEnumerator(IEnumerable enumerable)
{
	IEnumerator < bool > t = enumerable.GetEnumerator();

	while (t.MoveNext()) {
		yield return t.Current;
	}

	// make compiler happy
	yield break;
}

And make the function wrapped return IEnumerable instead of void. Then the function can at any point in the function do a simple yield return true; to signal that the function can be resumed to complete its task. So this way it is also very dynamic since a function can return if it has done X amount of work, or if X amount of time has passed or if it is signalled by some other code that a low latency task has been added to the queue. It really adds a lot of flexibility while still keeping the nice structure of a simple function. The complete code is in nemo 0.2.1 under metadata/MetadataStore.cs.

Categories
.net c# iola Programming

Iimplement brain damage

Had this annoying bug today where something that seemed perfectly resonable just didn’t work. After much investigation it appears that once again brain damage from Java has managed to over into C#. The problem is illustrated with the following code (You can ignore the Tuple for now):

public struct Tuple < TFirst,TSecond >
{
    public TFirst first;
    public TSecond second;

    public Tuple(TFirst first, TSecond second)
   {
	this.first = first;
	this.second = second;
   }
}

[...]

Tuple < int,string > t = new Tuple < int,string >(1, "1");
Tuple < int,string > t2 = new Tuple < int,string >(2, "2");

List < tuple < int,string > > lt = new List < tuple < int,string > >();
lt.Add(t);
lt.Add(t2);

List < tuple < int,string > > lt2 = new List < tuple < int,string > >();
lt2.Add(t);
lt2.Add(t2);

System.Console.WriteLine("eq {0}, == {1}", lt.Equals(lt2), lt == lt2);

Which gives the following result:

eq False, == False

Ok that was strange, in Python and C++ one doesn’t have to use Equal or anything similar and furthermore == gives the correct result since it compares elements memberwise instead of just checking the reference. I recalled that in Java one has to use Equal on strings, since == just compares references. So I googled around and found an explaination in point in the following link at 6.7. Note all the special cases. The best part is the following paragraph: “The implementation of Equals() in System.Object (the one you’ll inherit by default if you write a class) compares identity, i.e. it’s the same as operator==”. Apparently List doesn’t to that, despite their efforts to help, great… So we’ll have to do that ourselves:

public static IEnumerable < tuple < T1,T2 > > zip < T1,T2 >
(IEnumerable < T1 > l1, IEnumerable < T2 > l2)
{
   IEnumerator < T1 > i1 = l1.GetEnumerator();
   IEnumerator < T2 > i2 = l2.GetEnumerator();

   while (i1.MoveNext() && i2.MoveNext())
       yield return new Tuple < T1,T2 > (i1.Current, i2.Current);
}

public static bool sorted_lists_equal < T > (List < T > l1, List < T > l2)
where T:IEquatable < T >
{
   if (l1.Count != l2.Count)
       return false;
   foreach (Tuple < T, T > t in zip < T,T >(l1, l2)) {
        if (!t.first.Equals(t.second))
              return false;
         }
   return true;
}

IEquatable is an interface what basically says that it will compare by value. But even though our Tuple implementation is a struct and thus is a ValueType it doesn’t implement this interface (the Equals method). It instead automatically defines the == operator to work as one expects since it’s a ValueType. So we have to change Tuple:

public struct Tuple < TFirst,TSecond >
: IEquatable < Tuple < TFirst,TSecond > >
{
   public TFirst first;
   public TSecond second;

   public Tuple(TFirst first, TSecond second)
   {
	this.first = first;
	this.second = second;
   }

   public bool Equals(Tuple < TFirst,TSecond > other)
   {
      return first.Equals(other.first) && second.Equals(other.second);
   }

    public static bool operator==(Tuple < TFirst,TSecond > lhs,
    Tuple < TFirst,TSecond > rhs)
    {
	return lhs.Equals(rhs);
    }

    public static bool operator!=(Tuple < TFirst,TSecond > lhs,
    Tuple < TFirst,TSecond > rhs)
    {
	return !(lhs == rhs);
    }
}

The last two functions was added because now that we’re implementing the IEquatable interface the compiler doesn’t seem to want to implement == and !=.

So instead of the following Python code:

a = [(1,"1"), (2,"2")]
b = [(1,"1"), (2,"2")]
a == b

We have to do the big mess above :-/

Categories
.net boo Books c# lisp Programming

Finished reading Practical Common Lisp

Finally got through the mighty Practical Common Lisp tome. The style of the book is written in a nice mix of theory and practice (with relevant and good examples). My friend Lau asked me why on earth I would want to read a book on Lisp? A fair question since Lisp is really old, actually measured in computer time it might even be called ancient. But I had two main motivations for reading the book, to become a better programmer and secondly to better understand new language features introduced in languages like Boo and C#. Just look at the new LINQ features in C# 3.0 and specifically this video.

I wholeheartedly recommend this book to anyone interesting in a good programming book.

Categories
.net c# cpp iola Programming

C# from a C++ developer perspective

Been wanting to get this out of my system for a while and since I can’t sleep I might as well do something productive.

During my time in iola I’ve begun writing code in C#. I’ve written quite a lot of C++ in the past and still does, so it was quite interesting for me to see what the next iteration of C would be like when I started out with this. This next section is written in a very practical sense, since at the end of the day, that is really what matters.

The nice stuff:

  • Fast compiler. I really think this is big. The slow compile time in C++ is contributed by several things, templates are really big here. And since they need to live in header files changing them can easily trigger a cascade effect of recompilation that is extremely detrimental to the whole coding experience. There are hacks around this but they are not really optimal solutions. When I did almost all my coding in C++ I didn’t think of this as a big problem, but once you’ve been seduced by the dark side (Take that Siebel ;-)) you really start to notice it a lot. And the fast compile time of C# makes it much more bare able to write in a statically typed language again.
  • Portable library with a lot of useful stuff like threading, network communication, File System abstraction, serialization etc.
  • No more dreaded header files. While this may seems strange at first (since header files are a nice way of describing the interface of the classes with comments that don’t get lost in the smoke of implementations), it’s actually really nice not having the headache of keeping
    the header files in sync with the implementation, making it much easier to move code around. Another big thing here is the whole template thing.
  • Delegates (or function pointers if you will) are extremely powerful and having them built into the language makes them very easy to use.
  • Support for yield.
  • Being able to use the power of .net (Newer in a million years thought utter such words) to mix and match languages. It’s actually quite trivial to write a piece of your program in Boo and have it work with the rest of the code. This is in particularly useful for writing unit tests.
  • Perhaps the biggest improvement, although this varies greatly from ones perspective, is that the whole language raises the bar. In the sense that a lot of the BAD programming practice that has been associated with C++, mostly caused by people simply using the language in the wrong way (char pointers, not taking care of memory management, generally pointers comes to mind here) has been stripped away from the language. A really good example of this is to compare the abomination that is pre .net C++ windows code and .net C# code.
  • C# is constantly improving and is doing so quite rapidly. Compared to the extremely slow pace of C++ (still hoping for a new standard in this decade!) it’s really refreshing to see a lot of good new ideas being pushed out to people.

The bad stuff:

  • Two thumbs up to the designer of C# for stepping up and actually implementing generics in C#. That being said, they are just a shadow of templates in C++ and the whole I-Implement-an-Interface crap is just plain dumb. Templates in C++ compared to generics in C# feels much more like macros in lisp, which if one thinks about it is quite the irony.
  • C# is clearly very proud of their garbage collection and thus sees no problem in demanding that everything must be created using the dreaded new syntax. While writing something like: List<string> l = new List<string>(); is not that big of a problem in something like monodevelop or visual studio. But it’s a big pain in the ass if you’re using the one and true editor. Another thing related to the GC is that needed to invent new syntax (using) to support the good programming practice of RAII instead of just doing it by creating objects on the stack and letting them fall out of scope and thus become deconstructed automatically.
  • C# falls into the trap of thinking that everything must be an object and that object orientation is the true path to righteousness. Namespaces was invented for a reason you know?
  • The built in libraries and especially the documentation is sometimes really really bad. Like methods returning results in different threads than the caller and not writing anything in the documentation about this.

Overall the experience so far has been quite positive and as far as I can see it will only continue to improve. That being said, there are still use cases where C++ is much more optimal and combined with a lot of legacy code C++ will continue to be used for a foreseeable future.

Categories
.net On the web Programming

Interesting video on the future of programming

I found this interesting video today. It’s basicly just Anders Hejlsberg, Herb Sutter, Erik Meijer and Brian Beckman sitting around a table discussing future and current trends of programming languages. It touches a lot of exciting subject such as concurrency and the .Net’s ability to mix several programming languages.

It was very relieving that a lot of what was taught in courses at the university where I studied is now reaching mainstream languages 🙂