Dense Linear Algebra,

I haven't use or heard those patterns.

I think the Dense Linear Algebra is easy to understand and the author try to make it easier to understand by using a lot of picture to illustrate.
For Graph Algorithm Pattern, I think I see enough definition in the paper that can help understanding the problem. Monte Carlo Pattern gives two examples which I found useful in understanding the pattern.

To me the computational pattern and the structual pattern are all aiming at efficiently solving certain problem. Structual patterns ease the design by building up relationships between entities in a simple way; Computational patterns find the best math model for the problem in the solution space. Hmmm, I will say the distinction is fuzzy.


Small problems that I have when reading through the patterns.

For Dense Linear Algebra, in performance analysis, isn't O(N^3) > O(N)? Why it seems like BLAS level 3 stand out?

Armstrong Thesis Ch 2.

I think the six descriptions are great guidelines of characterizing the software architecture.  If I try to describe a system, I might use the some of them, probably not all.  I don't see the necessity of the construction guidelines in majority of the system descriptions.



I don't have much experience in parallel programming, and I don't remember that I've ever worked with a system with inter-process communication solely via messages.  I'd like to hear some examples tonight.


I think the "fast-fail" idea is suitable with the requirement of the system, which has a lower tolerance of fault. I think in the Thesis, the author lists some properties that needs to be built in such as a failure status need to be recorded and the isolation of crashed processors.

I think it is a good decision to make for treating the messaging layer as unreliable in the telecom environment that is working.  The tradeoffs will be the additional confirmation in the system.

Event based implicit invocation & Map reduce

Event based implicit invocation

I think the difference between this event based pattern and observor pattern is the medium.  The similarity exists in that both of the patterns do some decoupling job to separate the publisher and subscriber to get better scalibility. And event based pattern uses medium as a hub to receive/dispatch the event whileas the observor is one to one.

Implicit invocation makes it ideal for broadcasting and requires less process for the medium.  I don't know about the security here to broadcasting. 

I think the "standard" messaging mechanism can only be achieved flexibly using a "middle man", since the one to one relationship is not good in adding new members.  An extra layer of abstraction is needed here.

I think that kind of structrue is widely used in distributed system.  The main error handling should reside in the "hub" so that error messages can be passed along or to be handled. But there should be some simpler error handlings in "node" too, in case the "hub" fails.


Map reduce

For some reason, when I saw this master-worker pattern, I immediately thought of the propagation of Storm, they share the same concepts of managers and workers. And because of this really efficient way of managing the robot machine, that spam spread very quickly around the world and I think parallel programming can be benefit from that too. 

Refactoring for Reentrancy

This is the third paper discussing about refactoring in paralellism.  This paper is dealing a more difficault problem, creating a program that can be run in parallel on multicores without additional control or separate VM for each program instance.  Like previous two papers, the refactoring of making program reentrant needs several steps that contains interactions with programmer.  Same as the tools that are described in previous two papers, the paper lists some statistics to show the efficiency and correctness of this tool.

The tool uses the concept of Lazy Initialization, but as mentioned in the paper that the initialization code the reentrant tool generates may alter program behavior, which will probably makes this tool unuable in complex code that will read mutable static field in other class. And that I think is pretty common in systems of a certain size.

Beautiful Architecture Ch 14.

I always find interesting topics in this book, and here comes what I am always waiting for: a chapter about a pure OO language, the Smalltalk! I found a lot of fun from Squeak in Smalltalk this Summer in another course taught by Professor Ralph Johnson. It's such a natual way in Smalltalk that objects interacting with each other through the messages. I think that gives this OO language a little bit favor of functional languages. The functions in Smalltalk are small yet powerful, the whole developing environment in Squeak is so convenient that I almost hate Visual Studio when I have to switch back to C# in my work.

One of the many interesting feature of Smalltalk is that it supporting "Duck typing", I recently found the support of this feature in C# too, the problem is C# is a strong typed language, and there is some debates in the internet about how to use the "Duck typing" in C#, or if it should be used.  Anyway, I appreciate the duck typing in Smalltalk that give me another option of polymorphism.

Since Smalltalk's open environment, it seems to me that Squeak is turning into a big lab, new concepts are implemented and tested there and later on adopted by other languages.  So even with so many cool concepts and architecture, it is not stable enough and not used much in industries.

I seem Smalltalk or Squeak as a system with beautiful architecture, I feel pitty that they are not known or used by many programmers. But I think that is one of the reason that they can always do something cool and never been done before.  I can't imagine any main stream architecture will have the opportunity of doing that.

Relooper

This paper describes another tool for semi-automizing the refactoring for parallelism.  This tool is dedicatedly used for transformation of data structure that can run loop operation on it such as array.  I think this paper is an enhancement of the previous paper. 

In this paper, the author is able to identify the biggest problem of dealing the safty of parallelism in an array, which is the "race" problem. And the statistic analysis shows that Relooper is an efficient tool for code refactoring to create safe parallel loop code.

Beautiful Architecture Ch 13.

This is one of the most interesting chapter in this book in my opinion. Although I found the comparison between the two does not always make sense.  I think both type of languages (OO or functional) exists for certain reason.  I only have experience with a couple of languages, (C++,C#, Java,Smalltalk)OO or functional(OCamel).  To me, OO languages are more modulized and easy to apply the "reuse" concepts. While functional languages are more flexible in structural, I like the convenience high-order function brings.  Especially powerful when you can use small functions and use the result of a function as the input of another.  You can get things done with shorter coding in functional languages than in OO.  This is not always, you can get fairly small functions by using Smalltalk too.  I don't have the same "easy to use" feeling in some OO environment such as C# though. But since functional language is more flexible, it takes more time for me to understand the function if it is embedded several layers of functions from my experience with OCamel.  Maybe it just takes time to get use to it, like it takes time for me to turn from structural languages such as PASCAL to OO language C++ at first.  I don't think it is fair to compare this two languages at certain level that they are just not comparable at all.  Because they are designed differently for different purpose. 

Refactoring Sequential Java Code for Concurrency via Concurrent Libraries

Refactoring process is tedious, and desparately need suppoorts from tools.  In this paper, a tool called Concurrencer is introduced to reduce the pain of this tedious, error prone process.  I believe they are on the right track of refactoring in parallel that semi-automatical convertion is less painful and much quicker solution for the transformation.  The paper lists three possible use of that tool: AtomicInteger, ConcurrentHashMap and ForkJoinTask, and gives detailed example of each use case.  I find it is easy to understand.

In the end of the paper, it lists some statistical result, trying to prove that Concurrencer is an efficient and useful tool for performing such convertion tasks.  I am curious if they can  extend that tool to support other more complicated parallel-programming structures.  I think integer increment, hash map operation and fork join are pretty simple, structual wise. Especially for fork join, majority of the divide and conquer functions are simple when using recurrence.  I think to make this tool more soundly applicable for industrial use, they need to have more complex structure transformation covered by this tool.

Java Fork/Join Framework

In this paper, the author trying to introduce the fork/join framework as a lighter parallel programming architecture comparing to threads so that ca be more protable for JVMs.  The framework is able to break runnables to a fairly small workload and pass that on to workers.  I think this framework is suitable for programs that are needed a lot of "simple" workers, rather than a more complicated counterpart.  I believe it shows a great performance advance for recurrsive type of work, not sure about more complex ones.