The “Many Core” Problem

We, as developers, have a problem.  CPUs will continue to have more cores, and each core is not going to be any faster.  The only way to write faster applications is to write multithreaded code, which has two challenges:

  • Multithreaded code is complex to write and think about.
  • Multithreaded code is difficult to test.

From what I’ve seen, people are pursuing 4 approaches. 

Better Languages

If languages are the whole answer, the language has to make it impossible to write multithreaded bugs, otherwise you only address the first problem (the complexity).

Erlang is one such language that removes whole class of multithreaded bugs. Erlang’s approach is to isolate the threads, and give them a way to pass messages to each other.  However programming in Erlang is awkward and arguably it makes the code more complex.

Other languages, like Clojure and F#, take a different approach and make it easier to write and deal with multithreaded issues, however they don’t prevent you from writing multithreaded bugs.  These languages do not address the whole problem as you still need a way to test the code.

Better Libraries

Microsoft has a library for .Net called Parallel Task Library to make it easier to write multithreaded code.  Need to operate on each element in an array?  Use the Parallel.For() method.  This library makes it easier to think and write multithreaded code, but it doesn’t make it any easier to test.

Static Code Analyzer

Java has a static code analyzer that is able to find multithreading bugs called FindBugs.  It looks at your code and reports any code that will cause multithreaded bugs.  This would address the second issue, because it, in theory, reports all threading bugs.  It doesn’t however address the first issue, making the code easier to write.

Testing with Deterministic Threads

Microsoft is going in a different direction.  They are working on something called CHESS that makes your unit tests find multithreaded bugs.  It does this by taking over the scheduler and sysmatically repeating each test, weaving the threads differently each time to exercise every possible way the scheduler could run the code.  However it requires us to to write a set of tests that finds *all* the threading bugs.  Since it is common to write unit tests with less than 100% coverage, a code coverage tool should be used to write more tests.


The good news is that there appears to be a variety of approaches to the problem and the whole answer will likely involve a combination of language or library enhancements and analyser or testing enhancements that are already in the works.

About Clay Lenhart

I am a DBA/Technical Architect for Latitude Group and love technology.
This entry was posted in Architecture, Languages and tagged , , . Bookmark the permalink.

19 Responses to The “Many Core” Problem

  1. henk says:

    I agree there’s a problem with the complexity of threading, but it already helps *a lot* if the communication pattern between your objects is well defined instead of chaotic.

    And guess, we should already be adhering to the well defined communication pattern for regular sequential (OO) programming 😉

    Next to that, in some cases building multi-threaded software is easier. Firing off some piece of code in a kind of job and then forgetting about it, may be far simpler than executing it inline of your regular sequential code and trying to interweave some other tasks while processing this piece of code.

  2. Andras says:

    Erlang got one thing right – the concurrency mechanism (I’ve written a post on this earlier: It *IS* a pitty that they chose to make it a functional language (it’s *incorrect* to claim that functional languages enable parallelism – why would they still need process constructs like in Erlang and Haskell?!) – same (otherwise powerful and beautifully simple) principles would have worked with traditional languages.
    Cheers, Andras

  3. Clay Lenhart says:

    > Erlang got one thing right – the concurrency mechanism

    You may be interested to know that .Net copied Erlang style concurrency and put it in a library for any .Net language call MPI.Net:

  4. Ulf Wiger says:

    That Erlang is supposed to be awkward is repeated in many blogs, as if it were an indisputable fact. Yet the University of Kiel uses Erlang to teach programming to high-school girls, and their final task after a week is programming a distributed chat server. There may, or may not, be an awkward transition depending on what you’re used to, but there’s plenty of evidence that Erlang itself can give good productiviy, compact code, and excellent life-cycle economy.

    A very recent study compared implementations of IMAP:

    Its conclusion is no surprise to those familiar with Erlang. On several occasions, Erlang teams participating in standardization work have ended up being identified as the de-facto reference implementation, since they are able to implement working feature-complete code much faster than the others.

    There are other languages that have outstanding qualities, but if you’re going to call Erlang awkward and complex, you should be fairly specific about what you’re comparing it to – it may carry some weight if coming from a seasoned Haskell programmer, but even then it will depend on the problem domain.

  5. Kamil Szot says:

    Most of apps today are multiuser and/or built of multiple software components.
    You can just run different users, or diffrent software components on different cores and you get the boost but almost never have to bother yourself with multithreading. The only case that remains a problem is when some component of your system responds to slow, then you have try to replace it with some equivalent that uses algorithm that can be distributed. This single tiny bit of system can be written as well in erlang regardles of it’s obscurity. There is a chance that you won’t even have to write it by yourself because some erlang hackers wrote it already because they needed it before you and published it as open source.

  6. Ulf Ochsenfahrt says:

    In which category does software transactional memory fall?

  7. Clay Lenhart says:

    > That Erlang is supposed to be awkward is repeated in many blogs, as if it were an indisputable fact.

    I’ve got to admit, you make a fair point here. For what it is worth, my merger explanation is:
    a) Erlang hasn’t taken off yet, so people must have some issue with it.
    b) “Standard” languages can do most anything concurrency-wise, which means that a restrictive model, like actors/message passing, must be more awkward.

    Pretty weak.

    Keep in mind that the point I’m trying to make is we’ll get through this crisis. Heck, Erlang may very well be the answer.

  8. Clay Lenhart says:

    > In which category does software transactional memory fall?

    This is a oversight — thanks for reminding me.

    For .Net people, you may be interested in the Transaction Memory blog

  9. ラグジュアリーなブランドコピー商品が発売こちらは有名かつラグジュアリーなシャネル、ルイヴィトンやエルメスなどのブランドコピー商品をご紹介いたします。新作は大量入荷して、情報満載です。書類もいっぱいあるし、今は色々な割引活動を開催中ですし、超低価格で、品質最高な逸品を購入できます。

  10. ヴィトンのダミエ財布N62668コピー商品です。イタリアのリゾート地リビエラの海と砂をイメージして作られたダミエアズールシリーズ。中でも男女問わず絶大な支持を集めているのがこの「ジッピーウォレット」。機能的なラウンドファスナー開閉式、多種多様な用途に対応した内部様式、シンプルで無駄のないデザイン等、いい所を挙げたらキリがない程のマストアイテム。普段使いには勿論、海外旅行時も考慮された仕様になっているので、インターナショナル派の貴方も大満足間違いなしです。弊社のサイトでは、シリーズごとに品番などをご覧にくださいで、ご自身にマッチしたルイヴィトンスーパーコピー商品を探しにご活用ください。

  11. ∮∮∮∮∮ ☆☆☆☆☆ 最大卸売り皮革市場 ☆☆☆☆☆ ∮∮∮∮∮ここには正真正銘感動される品質のスーパーコピーブランド 激安代引き好評信用販売店です!当社は長年の豊富な経験と実績を持ち、完壁な品質を維持する為に、一流の素材を選択し、精巧な作り方でまるで本物のようなな製品を造ります。商品の数量は多い、品質はよい、品質も大自信です。ブランドコピーバッグ,財布, ベルト,靴、腕時計などの逸品を想像しきれない優待価格で提供しております.ご来店を期待しています。

  12. 腕時計スーパーコピーN品専売店!スーパーコピー時計の激安老舗.!アフターサービスも自ら製造したスーパーコピー時計なので、技術力でお客様に安心のサポー トをご提供させて頂きます。スーパーコピー,スーパーコピー時計,パネライスーパーコピー,ウブロスーパーコピー,IWCスーパーコピー,スーパーコピー時計N品,腕時計スーパーコピー,時計スーパーコピー,腕時計コピー,コピー時計スーパーコピー時計,流行の2016新作腕時計スーパーコピー通販_「10 %OFFセール開催中!」。スーパーコピー時計直営店.会員登録頂くだけで2000ポイント 取得できます! 2015クリスマス10%OFF】:ロレックス、ウブロ 、パネライスーパーコピー時計等多種ブランド時計コピー。2015人気TOPスーパー コピー時計専門店。

  13. ∮∮∮∮∮ ☆☆☆☆☆ 最大卸売り皮革市場 ☆☆☆☆☆ ∮∮∮∮∮ここには正真正銘感動される品質のスーパーコピーブランド 激安代引き好評信用販売店です!当社は長年の豊富な経験と実績を持ち、完壁な品質を維持する為に、一流の素材を選択し、精巧な作り方でまるで本物のようなな製品を造ります。商品の数量は多い、品質はよい、品質も大自信です。ブランドコピーバッグ,財布, ベルト,靴、腕時計などの逸品を想像しきれない優待価格で提供しております.ご来店を期待しています。

  14. プロジェクトZ8腕時計配備双タイムゾーン自動的に機械ムーブメント。同ムーブメントはブランドの経典を受けて専門家の認可。あなたどこでも、同時に2つのタイムゾーンの時間を。ロレックス時計コピープロジェクトZ8腕時計の様々な機能分担明確:1時位置のえこひいき時/分によると、3時位置の日/夜によると、ブーメラン(shuriken)――プロジェクトZシリーズのシンボル的な模様――は演じて動力貯蔵指示とカレンダー表示の役。文字盤中央の第二のタイムゾーンのレトログラード表示盤は、特別に配備が見もの指針:そのデザインは精巧で、採用陽極メッキアルミ素材、立体造形体現弧と完璧な工芸の設計。

  15. Millenary3問表は今年発売した別のブランドの旗艦表。見渡すオーデマピゲ(Audemars Piguet)タブ史、ブランドずっと3問機能を求める声なんだか、指示時間、特にない電燈の年代、容易な闇の中で「読解」の時間。凝縮タブ工芸、最先端技術と革新素材、これはMillenary3問表の創製理念。Millenary3問腕時計搭載AP 2910自動的にムーブメント配備風変わりな規制の仕組み。それはツイン糸遊構造代わりに伝統の単糸遊、に逆が180度の角。このような首尾連携の双糸遊構造が多い優位を除いて、解決することができる「宝飢え」糸遊多い「末端曲線」問題に加え、発条不均衡時、借りて自動補償バランスを取り戻す。また、それを借りる必要はない復雑な陀はずみ車装置、すぐ解決腕時計が垂直位置精度低下の問題。ウブロ 時計 コピーべてのこれらの特色を確保するための設計摆轮糸遊精微調節を1時間21 600回の週波数精巧なスイング。

  16. さらに、20 mmのひもが私の例についての湾曲した開口部を通して自然な合うものではありません。だから私の設計目標は、従来から搭載ストラップを保持するが冗長性と独特のルックスをそれに加えました。その結果、多くの紙と革のプロトタイピングに使用する連続ループを確保し、従来のストラップを介して一対のいわゆる「ズールー族の「鋼のループ。 ウブロ 時計 コピー 結果として視覚的密度のストラップ」がたくさんありますが、実際のシステムと腕時計にマウントを製造する技術的に簡単である。概念的に、デザインへの挑戦が、実装するのが簡単である。極端な冗長性と連続的な二次のループで、名前を「インフィニティ・ストラップ」を作りました(私に)。

  17. 私と言って好易通CEOのヴィンセントそれは何の頭蓋骨、彼らに贅沢な腕時計がこんなに人気がある。 ドクロのテーマの陀はずみ車がますます人気のブランドのリチャードMilleとウブロ(など)。 ダウンレディースコピー 今、好易通はすでに入って頭蓋骨ゲームを見るもので、1時(点)の追加の技術の深さのテーマは通常の病的状態の。第一歩は作成の頭骨輪郭、使用好易通の専用液時間表示「毛細管」システム。完全に円形で、液体管の頭蓋骨の上の文字盤は、あなたが読んだ時の主要な方式。好易通によって、薄いガラス管の微妙な曲げは特殊な工学の挑戦。

  18. ひっくるめてCHANEL製のバッグと言ってもデザインも色も多種多様です。シャネルスーパ-コピー話題の商品はもちろんのこと、日本では売られていない物、入手困難な限定モデルなども外国の通販でチェックしてみましょう。人気のバッグを通販で安価で購入する秘策を知りたいですか?それは何かと申しますと……、型の等しいバッグをインターネットで調べるだけなんです。単純なことですが、実は意外とほとんどの人が気付いてないんですよね。テレビで放映されている通販番組内でも、有名ブランド品はかなりの確率で売られています。これらの通販番組を利用して著名ブランドの商品を注文したよという方も割と多いと思います。

  19. 今年は実力で優勝したチームはたくさん本を含め、アイルランド隊。ヨーロッパツアー第2位の罗里・マイクロイ(Rory McIlroy)が今年は格莱姆・麦克道尔(Graeme McDowell)コンビ代表アイルランド出陣。20歳の罗里・マイクロイは現在、世界ランキング10位。

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>