October 2007 - Posts
I have just posted the 3rd and final part of this miniseries about MSIL on Channel8, links below.
If I were to trust the view stats on C8 then this series has been the most popular stuff that has ever gone up on there, surprisingly more popular than videos with the likes of Brian Beckman! Crazy!
I hope at least a handful of people have enjoyed this little series on MSIL :-)
View it - MSIL - the language of the CLR (Part 3).
I really like what the C++ team have done here, they've essentially created a subset of the stuff found in the C++ STL but included error checking and stuff like that - of course this all requires .NET 3.5.
It seems that the STL/CLR stuff has been a victim of the more cooler features in the app languages C# and VB.NET like LINQ, and err... LINQ.
Check it out here - http://msdn2.microsoft.com/en-us/library/bb385954(VS.90).aspx.
I believe that all the containers act like their C++ STL counterparts from an interaction perspective, with a few under the hood error checking things thrown in to make them "safer". I mean where would you be without the trusty vector container?! :-)
Herb Sutter, one of my favorite C++ people has been posting some excellent stuff on C++ lately none more so than a video on machine architecture.
He has also been talking about concurrency a lot recently as well.
Enjoy.
I just pushed the publish button on part 2 of this mini series I'm doing on Channel8.
Go check it out!
Part 3 is already done - I'll hit the publish on that next Saturday.
Enjoy.
Finally.
I hope that MS embrace the communities of other popular functional languages like Haskell to great a truly amazing functional language, not that F# isn't already.
The more time I spend with F# the more I start to lose my interest in Haskell and that language is just great!
I must say this is music to my ears when the VP of dev div (Soma) announces it.
A commenter posted the following on Soma's blog:
This looks like Microsoft's solution to Python.
I wonder how many times we will be seeing this now that F# just got a little more mainstream? :-) This actually seems to be a pretty common assertion from people looking at the actual syntax of F# for the first time, reality is that F# is a static language.
Let the good times roll!
I came across a great resource on F# a few weeks back - it's a technical journal and is released on a monthly basis (although sometimes there are more than one per month).
Some of the stuff that Jon Harrop writes about (author of F# Journal) is really interesting. Most of what I have read to date I have never seen elsewhere - but the beauty of the F# Journal is that it clearly explains constructs within the F# language using really great examples.
To date some of my most favorite issues of the F# Journal include how to exploit tail recursion (great read!), pattern matching, and recently an issue on the Fourier transform.
If you are into F#, or looking at getting into F# then I highly recommend subscribing to the F# Journal!
...also I'm keeping an eye out for Jon's F# for Visualization book - this should be really good!
I don't know why but I randomly decided to see how well my SinglyLinkedListCollection<T> fared against the LinkedList<T> collection in System.Collections.Generic.
First off, my implementation supports pretty much everything that the MS LinkedList<T> does, that includes full LINQ support and so on.
Anyway, I added 5000 items to each to see what that would do - I actually expected the BCL data structure to be superior to mine. I had done no real magic in my implementation, I had simply coded the thing after working out the various algorithms on paper.
Memory allocation: both data structures are allocated 48 bytes total per instance, however I can only assume that the node used internally by the BCL collection has maybe another pointer i.e. it has a next and prev pointer, giving the ability to use it as a DoublyLinkedList? (I've not looked at it yet). This is where my implementation kind of wins, although I'm pretty sure at this moment that the BCL node supports doubly linked list style structures - in any case as my node is smaller than that of the BCL one my implementation after 5000 instances are created totals 160,000 bytes, the BCL one on the other hand stands at 240,000 bytes so quite a reduction there.
FYI: my node size is 32 bytes, the BCL one is 48 bytes.
Out of curiosity I also benchmarked my DoublyLinkedListCollection<T> against the LinkedList<T> of the BCL and my node size is still smaller, this time only by 8 bytes per instance but it still add's up. Same scenario, 5000 items added my implementation has been allocated 200,000 bytes where as the BCL one has been allocated 240,000 bytes - still a considerable saving, all be it slightly less.
Again, the actual data structures were allocated 48 bytes.
If you want to rip my implementations to bits then you can go ahead and download it from here: DSA 0.2.2 (you shouldn't notice any difference between these implementations and the BCL ones - both in terms of API and design time debugging experiences).
Over the last 4 or so months I have drifted away from technologies and focused heavily on compiler theory and design as well as data structures and algorithms.
You may of noticed that F# has become a fairly recurrent theme on this blog - that's because functional languages have a great deal to offer, especially in terms of lexical analysis and working with abstract syntax tree's, there is no better language paradigm to use when working with recursively defined data structures like trees.
Anyway, the focus of this blog will probably become 100% focused on the aforementioned subjects...this should be really interesting for the reader, not many people get excited by compiler theory and implementation...whether that is a good thing or bad thing I'm not sure! :-)
This means that code on this blog will probably be in one of the following languages:
Why? The first and last are obvious choices, two popular imperative languages with the latter exposing a little more control over the OS's resources. F# I've explained already it's uses in such an area.
On this blog I will try my best to explain things as best I can without throwing a load of formal methods at you, although avoiding it is impossible in such an area. Sorry if you have no knowledge of formal methods, but I happen to really like it.
Hopefully future blog posts will not only educate, but also invoke ideas on your part about how we can help languages evolve to encompass issues like parallelism, and so on. On the latter should the onus be on the developer? or should it be on the compiler writer? I'm not going to answer this now, but imperative languages are going to be immensely hard for the compiler writers to natively support mappings to code that is deemed safe for parallel execution - unfortunately for the majority of developers around the world these languages (C, C++, C#, Java and so on) are the most widely used commercially. To their credit Microsoft are working on introducing functional constructs into the likes of C# and VB.NET to address this, LINQ was the first major step - looking further ahead PLINQ will enable the developer to further abstract away from imperatives to support easier multi core/CPU friendly code to improve performance by many factors.
I kind of went on a tangent on the end there, sorry. I hope you will find what I have to say informative and at the same time exciting.
Granville.
About a month ago I posted about the importance of enforcing standard guidelines in your code, the simplest way of which is to use either the Code Analysis tool, or the standalone FxCop tool.
The FxCop tool is still a separate entity, and today I read that the latest version FxCop 1.36 Beta 2 is out - primarily this addresses bugs in the last release.
Please download this and improve your code today...seriously static code analysis will do you nothing but favors (well most of the time ;-)).
For some reason I wanted to look at the samples again as it's been a long time since I took a peak at them - not quite sure what examples exist now...anyway they didn't seem to exist on my machine in the samples folder. Turns out that the compiler I have installed 1.9.2.7 the samples were dropped according to Don but were reinstated in 1.9.2.9.
Case closed.
More Posts
Next page »