This past weekend our team met once again to discuss our project. This team we were assigned to find a bug, describe it, and find in the code where it is. Then we had to describe a test plan on how to fix it. I found a bug to deal with and even developed my own hotfix for it. I submitted it to our team’s wiki. The report is replicated below: Continue reading
For any reader’s who are a member of the ACM or IEEE you might be familiar with the magazine, Computer. This segment is a critical look at an article from March 2010 called “Parallelism via Multithreaded and Multicore CPUs”. I will offer my own personal analysis along with general information about what was contained within the article.
The general summary of the article is that it is a “comparison between multicore and multithreaded CPUs currently on the market”. The attributes the article focuses on are “design decisions, performance, power efficiency, and software concerns in relation to application and workload characteristics”. This area is really intriguing to me personally, because it is an area I have always wanted more clarification on. What are the yields of a multicore and multithreaded processors and how important are they, especially when it comes to choosing the right cpu for a new computer.
The article starts off with design decisions. It describes how multithreaded cores have multiple hardware threads to make switching between threads easier and more efficient. The most common approach to switch between threads is known as simultaneous multithreading aka hyperthreading. This threading technique utilizes precoded instructions from only a subset of the threads on the chip. Interestingly the article also mentions that no commercial CPUs issue more than two threads per core per cycle. This information tells me that the way CPUs are threaded is a negligible difference when deciding which CPU is better. The article further explains that the limits on threading are due to scalability. By having more than two threads you have surpassed a “saturation point”. This point hampers your ability to get any more use out of executing more than two threads. However there is a way to work around this dilemma: multiple cores, which is great news. These facts indicate that threading is standard but how many cores you have does make a big difference in capability.
Another consideration is the cache. There are currently three types of caches: shared, private, and dynamic. The latter being very rare. Because of this reason the article compares the major types of private and shared. Shared implies that the cache is shared between the cores, while private implies it belongs to one core alone and cannot be used by other cores. For multicore programs it is better to have shared cache if the software threads need to share data. This method also prevents the need to copy data and if more efficient because it avoids the need to access other caches indirectly between cores. The draw back though is that shared cache is more unpredictable. The software is less isolated and therefore can end up using much more cache than is necessary. Also it makes it difficult to gauge the program’s service to each thread which leads to instability. The private is therefor more predictable and controls performance. These findings depict some of the tricky decisions in CPU choice. It becomes a much more advanced situation of deciding which kind of trade off you want to make based on the software you use. To me I would prefer the private because stability is many times better than speed when it comes to managing memory.
So when it comes to multicore processors, this article suggests that there is no clear cut choice. It all depends on your software’s specific needs and design. Certain hardware is always have certain software designs in mind and CPUs are no exception. Just like life, there is never one true right answer.
These are my personal reflections about the article The Cathedral and the Bazaar,written by Eric Raymond.
The premise of the article is that software development has two categories: a cathedral style and a bazaar style. According to Eric each choice has their own purposes and uses that make each unique and effective in their own way. However a majority of the article involves an anecdote about him initially discovering what is known as the bazaar style. This anecdote involves his development of the open source software fetch mail. Within the anecdote are pieces of programming wisdom provided by Eric to be used by any programmers reading the article.
As for my personal view, I found the premise to be interesting. I think the theme of the paper is accurate and Eric takes a fair shake on it. He mentions that most of the time the core of a program is cathedral style, while the innovation and tools added onto the program are done bazaar style. This blend of the styles is what makes the most sense to me. You want to have skilled programmers who understand the main concept to develop a strong foundation. Then the community can help build the rest.
I also found the anecdote quite entertaining and a good example of how bazaar style can be effective. I agree with a majority of his claims such as releasing early and treating the user as a co-developer. These kinds of concepts were newer to the field back in 1996 but have flourished today, and for good reason. As Eric points out, the most famous example of the bazaar technique was Linus’ work with the linux system. This system was only the beginning. Today programs such as filezilla and firefox are quite competitive in the market and show that bazaar techniques can lead to a more stable and better built programs.
There is one area where I have to disagree with Eric though. I think he does not address issues appropriately. He writes a great article about how awesome this style is and how great the bazaar is but does not anticipate audience response. Now he may not be going for a purely argumentative paper or persuasive paper, but at the least I would hope he would counter people who say the bazaar style is a poor way of doing things. Like most open source writers he does not appropriately address the issue of payment. The thing about a bazaar is that the people in a bazaar are making money, they do not come there out of the kindness of their heart and do everything for free. This is where is analogy seems to be off the mark.
However, I am not suggesting this is a mortal flaw with the argument for open source. Just as he says near the middle of the article. By making the program open source he had thousands of users looking at bugs and suggesting ways to fix them. I just feel like his analogy incorrectly depicts the relationship between core developers (cathedral builders) and the community (bazaar). A more appropriate way to describe this relationship is a house being built by an architect in a community. Then the community volunteers to help their neighbor make some great improvements to the house, motivated by either their like of the neighbor or just wanting to try out their skills on improving the house.
Either way, this article was entertaining, funny, and convincing. Definitely worth the read.