クックパッドの海外向けのAndroidアプリを開発している @rejasupotaro です。海外チームでは英語圏だけでなく、スペイン語圏やアラビア語圏や、その他いろいろな地域・ユーザーの環境に合わせてサービスをローカライズしながら展開しています。 東南アジアや南米では日本に比べるとネットワークは不安定で遅く、現地に行って自分たちのサービスを使うと読み込みの遅さに愕然とすることがあります。レシピサービスにとって画像の読み込みの速度は重要なので、これまでもレイテンシ、フォーマット、圧縮率、キャッシュ、画像サイズ、リクエストの優先度、プリロードなどさまざまな最適化を試みてきました。今回はスレッドプールのサイズについて考察しました。 非同期処理とスレッドプール Androidには、UIを操作することができる唯一のメインスレッドと、APIや画像のリクエスト、DBの読み書きなどの時間のかかる処理でメ
今の状況を書いておくと、 https://github.com/tanakamura/waifu2x-converter-cpp/blob/gpu/src/modelHandler_OpenCL.cl いちおう動いている、が、FMA版よりまだ遅い。i7 4700MQ vs GTX 765M でFLOPS値 200 : 80 ぐらい 765M は 1300GFLOPS なので効率6%ぐらい。 FMA 版と同じように、outputplane を最内ループにすると、係数全部ローカルメモリに乗せないといけないのだが、16KBでは全然入らない。(最大576KBになる) 案としては、 occupancy に頼らない。参考:http://www.cs.berkeley.edu/~volkov/volkov10-GTC.pdf SMあたり65536,32768 レジスタあることを考えると、128x9 は余
C++11の標準ライブラリ<thread>を使った並列化 大量のデータを分割し、複数のスレッドに分担させて処理時間を稼ぐことを考えます。スレッドに関わるAPIは、WindowsならCreateThreadやWaitForNltipleObjectなど、Linuxならpthread_xxxxと、OSによって異なるのですが、C++11では標準ライブラリ<thread>がOSごとの差異を吸収してくれているのが嬉しいところ。大量のデータを詰め込んだvectorを2つのスレッドでソートしてみます。 #include <iostream> // cout, endl #include <thread> // thread #include <algorithm> // inplace_merge, etc. #include <chrono> // clock, time_point, duratio
この記事はC++ Advent Calendar 2013の15日目にエントリしています。 内容はC++標準ライブラリとスレッドセーフに関する解説になります。 flickr / rennasverden もくじ What's スレッドセーフ？ スレッドセーフという幻想 基本型とデータ競合 C++標準ライブラリとデータ競合 C++標準ライブラリ：シーケンスコンテナ編 C++標準ライブラリ：連想コンテナ編 スレッドセーフ RELOADED 基本的なスレッドセーフ保証 std::shared_ptr<T> std::rand() std::cout （本文のみ約9000字） はじめに マルチスレッド対応の点では他言語に遅れを取っていたプログラミング言語C++ですが、C++11ではようやく標準ライブラリにスレッドサポートが追加されました。C++11スレッドサポートではスレッドクラスstd::thr
条件変数(condition variable)同期プリミティブにまつわる "spurious wakeup" についてメモ。 安定した対訳語が存在しないようなので、本記事ではそのまま英語表記とする*1。spurious は “偽の; 疑似; 似非” といった意味の単語であり*2、wakeup は “条件変数で待機していたスレッドがブロック解除されて実行再開する”（＝寝ていたスレッドが起きる）ことを意味する。 まとめ： spurious wakeup は、「条件変数での待機(wait)処理において、何もしていないのにブロック解除される現象」を指す。ライブラリ内部実装やハードウェア／OSの都合といった、同期プリミティブの利用者から関与できない原因によって生じる。その発生頻度は特に言及されないが、一般的には低確率でしか生じないはず。 spurious wakeup に対応するため、条件変数での
C++11標準ライブラリの条件変数std::condition_variableおよびstd::condition_variable_anyは仕様上 spurious wakeup を許容する（→id:yohhoy:20120326）。このため条件変数のタイムアウト付き待機関数wait_until, wait_forの動作において、「通知を受けていないしタイムアウトもしていないがスレッドのブロックが解除される」という、プログラマの望まない（しかし規格に準拠した）状況が発生しうる。 #include <mutex> #include <condition_variable> int user_cond = 0; std::mutex mtx; // 変数user_condの保護 std::condition_variable cv; // 待機条件の達成(user_cond!=0)を通知 /
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
C++11 には、複数の Lockable なオブジェクトをロックしてくれる std::lock 関数があります。 template<class L1, class L2, class... L3> void lock(L1& m1, L2& m2, L3&... m3); この関数の最大の特徴は、決してデッドロックしないことです。 そして、このデッドロックしないという要件を満たすために使われるアルゴリズムが、try-and-back-off アルゴリズムと呼ばれるものです。 今回はこの try-and-back-off アルゴリズムについて説明します。 （この記事には独自解釈が含まれているので、間違ってる部分とかあれば指摘して頂けると嬉しいです） デッドロックの条件 デッドロックは、正確ではないですが、大まかに言って以下の条件を満たすと発生します。 ロックを取得するために待機を行なう あ
Lock-free programming is a challenge, not just because of the complexity of the task itself, but because of how difficult it can be to penetrate the subject in the first place. I was fortunate in that my first introduction to lock-free (also known as lockless) programming was Bruce Dawson’s excellent and comprehensive white paper, Lockless Programming Considerations. And like many, I’ve had the oc
元記事：Benign Data Races Considered Harmful | Corensic, Bartosz Milewski氏, 2011/6/7 自分自身の理解のために日本語訳を行ったC++11でのデータ競合に関する記事。（タイトルはいわゆる"〜 Considered Harmful"ネタ） 良性データ競合は有害である 最近、本ブログで大いに論争を巻き起こした良性データ競合（訳注：同記事の拙訳）に関する一連の投稿があり、また多数のディスカッションが行われました。2つの陣営が形成され、一方はデータ競合は良性たりえないと主張し、他方はデータ競合はパフォーマンスを得るために必要だと主張しています。そしてデータ競合の定義すらも合意できていないと分かりました。特に、C++11での定義は従来の概念からは逸しているようです。 データ競合っていったい何？ まず初めに、議論の対象を明確にしま
このブラウザーはサポートされなくなりました。 Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。 .NET アプリケーションの並列処理についての過去、現在、未来 Stephen Toub 過去の並列処理 スレッドの直接操作は、応答性の高いクライアント アプリケーション、並列アルゴリズム、およびスケーラブルなサーバーを実現するために、以前から開発者が採用している方法です。しかし、この手法は、デッドロック、ライブロック、ロック コンボイ、2 ステップ ダンス、競合、オーバーサブスクリプションといったアプリケーションを望ましくない状態に陥らせる温床でもありました。Microsoft .NET Framework は、その誕生以来、専用の名前空間 (System.Threading) など、同時実行アプリケーショ
目次 ホーム 連絡をする RSS Login Blog 利用状況 投稿数 - 1078 記事 - 2 コメント - 33227 トラックバック - 363 ニュース 著作とお薦めの品々は 著作とお薦めの品々は 東方熱帯林へ。 わんくま 東京勉強会#2 C++/CLI カクテル・レシピ 東京勉強会#3 template vs. generics 大阪勉強会#6 C++むかしばなし 東京勉強会#7 C++むかしばなし 東京勉強会#8 STL/CLRによるGeneric Programming TechEd 2007 @YOKOHAMA C++・C++/CLI・C# 適材適所 東京勉強会#14 Making of BOF 東京勉強会#15 状態遷移 名古屋勉強会#2 WinUnit - お気楽お手軽UnitTest CodeZine Cで実現する「ぷちオブジェクト指向」 CUnitによるテスト駆
http://cpplover.blogspot.com/2011/07/mutex.html C++ のソースコード中に「途中のreturnや例外に気をつけること」などといったコメントはあってはならないため，補足． // 排他的にアクセスするリソース class exclusive_resource { public : std::vector<int> v ; private : std::mutex m ; public : void lock() { m.lock() ; } void try_lock() { m.try_lock() ; } void unlock() { m.unlock() ; } } ; exclusive_resource res1, res2 ; void thread1() {// res1のみを操作 std::lock_guard< exclusi
Java SE 7徹底理解の2回目である今月は、並行処理のフレームワークについて紹介していきます。 Javaは1.0がリリースされた当初から、スレッドを使用することができました。筆者もJava 1.0で簡単にスレッドが使えることに感動したことを覚えています。 しかし、スレッドを安易に使ってしまうと、デッドロックやデータの破壊を引き起こしかねません。スレッドクラスは簡単に使えるものの、使いこなすには並列/並行処理についての適切な知識を必要としたのです。 そこで、より簡単に並列/並行処理を使うためのフレームワークであるConcurrency UtilitiesがJ2SE 5.0で導入されました。 Concurrency Utilitiesは非同期処理APIや、スレッドセーフで高性能な並行コレクション、ラッチやセマフォなどのロック機構、アトミック処理など並列/並行処理のためのさまざまな機能が含ま
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
