C++ヘッダだけでDeep Learning、tiny-dnnの紹介 - Qiita
DeepLearning Advent Calendar,6日目の記事です。 Deep Learningフレームワークも世の中に随分と充実してきた昨今、いかがお過ごしでしょうか。今日はC++プログラマが簡単に導入できるDeep Learningフレームワーク、tiny-dnnを紹介します。 まとめ C++でDeep Learningやるなら、tiny-dnnが便利 Header-only＆外部依存なしで簡単導入 Caffeからのインポートやシリアライズなどの各種機能にも対応 いろんなデバイス上で動かしたい人、既成のModel＋αを素早くアプリケーション化したい人、C++でDeep Learningを理解したい人に最適 背景 Deep Learningフレームワークといえば、 Chainer TensorFlow Caffe あたりが有名ですね。他にも老舗のTheanoにTorch、Tens
128bit除算も定数除算最適化したい - よーる
一般に整数除算（ここでは剰余演算も含むこととします）を行う命令は遅いです。 そのため、除算はなるべく回避したいものです。 除数がコンパイル時定数の場合、コンパイラの最適化により、除算が取り除かれることがあります。 これを定数除算最適化と呼びます。 定数除算最適化では、除算はいくつかの軽量な命令に分解されます。 二のべき乗で割る場合、単にシフト命令が使われます。 それ以外の数で割る場合、乗算とシフト命令が使われます。 符号付きの除算の場合、零への丸めの部分の取り扱いが面倒ですが、追加のシフト命令と加算命令だけで（分岐命令を使わずに）なんとかできるようです。 さて、この定数除算最適化は、128bit整数の除算の場合は常には行われないようです。 これを何とかしてみたいと思います。 もちろん、手で最適化されたコードを書けばできますが、コンパイル時計算により除数が決まる場合などに対応するのは困難とい
ESP32のC/C++の関数をアセンブリ言語化し手作業で最適化してみる
はじめに 前回の記事ではESP32を対象に、アセンブリ言語の読み方を説明しました。今回はもう少し具体的な例を挙げて説明をしていきます。 前提条件 XtensaコアのESP32シリーズ (ESP32/ESP32-S2/ESP32-S3) を使用していること。 ArduinoIDEまたはVSCode+PlatformIOでESP32用のプログラムを実行できること。 前回までの記事の内容までを把握していること。 ※ ESP32-C3などはXtensaコアではないため、本記事の対象から外れます。 今回取り扱うサンプルコード 今回はC/C++で作成した関数をアセンブリ言語化し手作業で最適化する手法を説明します。 比較的手軽にアセンブリ言語化の恩恵が得やすい 『配列に対して何らかの演算を行い、結果を配列に格納する』 という処理例を用意します。 今回取り扱う例は以下のようにしました。 void test
C++でONNXRuntimeをビルドして推論するまで - Qiita
はじめに C++でDNNの推論を行う時のライブラリとして、Pythonで学習を行った時のフレームワーク(PyTorchやTensorFlow)のC++APIをそのまま使う手もありますが、それ以外にONNXRuntimeが有力な候補として上げられます。 筆者の所感ですが、PyTorchやTensorFlowのC++APIと比べると バイナリサイズが小さい 静的ライブラリのビルド、リンクが比較的簡単 実行速度が同等かそれ以上 といったメリットがあります。 しかし、ビルドから実際に使用するところまでの情報が散逸しており、実際に動かしてみるまで苦労したので、この記事で一通りの流れをまとめます。 この記事でやること ONNXRuntimeをソースからビルド ONNXRuntimeのC++ライブラリをソースからビルドし、推論アプリケーションで使うために必要なライブラリ群を列挙します。 ONNXRunt
Unityの推論エンジン『Barracuda』を試してみたのでそのメモ - e.blog
概要 以下の記事を参考に、最近リリースされたUnity製推論エンジンを試してみたのでそのメモです。 qiita.com note.com Barracudaとは？ Barracudaとは、ドキュメントにはこう記載されています。 Barracuda is lightweight and cross-platform Neural Net inference library. Barracuda supports inference both on GPU and CPU. 軽量でクロスプラットフォームなニューラルネットワークの推論ライブラリということですね。 そしてこちらのブログによるとUnity製のオリジナルだそうです。 セットアップ BarracudaはPackage Managerから簡単にインストールできます。 インストールするにはWindow > Package Managerから
【DirectX12】Mesh Shaderを使用した次世代頂点パイプラインの検証 - Qiita
自作フレームワークにMesh Shaderを組み込み、従来の頂点シェーダーと比較してどのくらいパフォーマンスが変化するか検証しました。 CADデータをポリゴン化したモデル、3DスキャンやZBrushでスカルプトしたような超ハイポリゴンモデルの場合 Mesh Shaderが圧倒的優位である。 しかし低ポリゴン数のモデルが配置されたシーンではVertex Shaderの方が優位になる。 低ポリゴン数のモデルをAmplification Shaderと併用して描画するとMesh Shaderのみの場合と比べて速度が低下する。 超ハイポリゴンモデルの場合、Amplification Shaderを併用するとより高速になる。 自作フレームワーク せっかくなので今回検証に使用した自作フレームワークをちょっとだけ紹介させてください。 API 開発環境 CPU RAM GPU
C#の深層学習ライブラリ「KelpNet」 - じんべえざめのノート
KelpNetは、春条さんによって開発されたC#の深層学習ライブラリです。今回の記事では、このKelpNetとインストール方法を説明します。 C#だけで実装された深層学習ライブラリ『KelpNet』を公開しています ・『Keras』や『Chainer』のように関数を書き連ねる記述スタイルを採用 ・数学が苦手な人でも深層学習の仕組みを理解できる様に行列演算は未使用https://t.co/5NhfIIIHEG— 春条 (@harujoh) 2016年12月10日 この記事は、初めて深層学習のライブラリを使用する方・今まで他のライブラリを使ってきたけどKelpNetも気になる方などを対象としています。この記事を読み終える頃には、「KelpNetとはどのような深層学習ライブラリなのか」「KelpNetの使い方」「KelpNetの導入方法」が分かるようになっており、説明もその順番で行われています。
プログラムで大切なことは読むべきコードを少なくすること。ただそれだけだ。 - お前の血は何色だ!! 4
オブジェクト思考とか手続き型とか、関数型とかの議論はまったく無価値だ。 こういう議論をしているお前らは、どうやら、プログラムで大切なことを理解していないのだろう。 const性も、オブジェクトも、ライブラリや部品の再利用、グローバル変数の禁止も、継承を避けることも、巨大な関数を避けることも、それはたった一つのことをやるためにあるといってもいい。 それは、読むべきコードを少なくすることだ。 コードを読むのはとにかく疲れる。 だから読むべきコードを少なくしないといけない。 コードがたくさんあると、どこにバグがあるのか、探すのが大変だ。 新しい機能を実装するべき場所を探すのが大変だし、 何を変更したときに他を間違えて、他を壊さないかのチェックも大変だ。 お前らは、printfを知っていますか？ 画面に文字を表示する関数だ。 では、この関数がどのように実装されているか知っていますか？ まあ知らない
⚰️C++的ゾンビのお名前🧟 - Qiita
“こんなゾンビだらけの言語に居られるか！俺は他の言語に出て行くぜ！” -- 行方知れずのプログラマー 🧟Zombie Names📛 C++17標準ライブラリ仕様から「Zombie names」というセクションが追加され、過去バージョンで利用していた識別子（クラス名や関数名など）が予約済みとして列挙されるようになりました。1 ...嘘じゃないよ：https://eel.is/c++draft/zombie.names C互換ライブラリ［C++11で非推奨, C++14で削除］ gets バッファオーバーラン脆弱性につながるため、今すぐ利用停止してください。バッファサイズを明示指定するfgets関数で代替可能です。 スマートポインタauto_ptr<T>［C++11で非推奨, C++17で削除］ auto_ptr auto_ptr_ref C++11以降はunique_ptrクラスで代替可
ゲーム開発とSTL - とあるぼっちの生存報告
コンシューマ向けゲーム開発に携わって結構な年数が経過しました。 これまでは恵まれていたのか、STLを使える環境にいた*1ので特に気にしていなかったのですが、どうやら場所によってはSTLはゲーム開発向きではないらしく使用を禁止される事もあるようです。 おかしいですね。私、STL使ってコンシューマ向けのゲーム作ってきましたけど。 確かにSTLはその特性と使用方法を知らないと痛い目にあいます。特にコンシューマ機のメインメモリ容量はPCに比べて圧倒的に少ないです。その少ないメインメモリ上に実行バイナリやヒープ領域などを展開しなければなりません。メモリ管理に対してシビアになるのは当然で、templateは使用方法によってはバイナリサイズが増大するので使用をある程度制限する事は仕方ありません。 また、std::listや、std::map等は使えば使う程内部でメモリを平然と分断してくれるので、ヒープ領
Cのプロダクトを作るためにやったこと - Tomohisa Oda
今年に入って Octopassというプロダクトを公開しました。それは、Linuxのユーザや権限をGithubのTeamと連携して運用を楽にするというツールでした。色んな方々のご協力により、多くのRetweetやはてぶいただいたことで、ある程度、Octopass を必要としそうな人の目に触れたのではないかと思っています。（Githubのスター数が少ないのは今後の課題）その中で「すごく便利」「ぜひ導入したい」というフィードバックは、継続して機能追加していくというモチベーションにつながっていて、非常にありがたいです。 さて、この Octopass は、Linuxユーザ名前解決をするためにの glibc の libnssモジュールをCで実装しています。cgoやその他の言語でShared Objectを吐き出しても良かったのですが、それだと技術的挑戦が足りないとして、触れてこなかったCに挑戦しました
Yield の意味 - かたちづくり
C# で yield return に出会ったとき、まず最初に理解の妨げとなったのは yield という単語の意味だった。 当時の僕にとって、yield といえばそれは「降伏する」という意味だった。その理由は僕が工学部機械科出身で材料力学を習ってきたことと関係がある。材料力学には「降伏応力」という概念があって、これは英語で yield stress というのである。 そんなわけで、yield return を知ったときは大いに戸惑った。降伏する、ではサッパリ意味が通じないではないか。当然、辞書を引くことになる。 〔農産物や鉱物が〕産出する 〔努力や投資によって〕収益が出る、利益が挙がる 〔戦いなどで相手に〕降伏する、屈服する http://eow.alc.co.jp/yield/UTF-8/?ref=sa 辞書を引いても、ストンと腑に落ちる訳は見つからない。強いて言えば「産出する」だろうか
今流行りの投機実行脆弱性の影響を一切受けないDOOM実装が公開される
https://github.com/xoreaxeaxeax/movfuscator/tree/master/validation/doom このDOOMは条件分岐を一切使用していない。したがって今流行りの投機実行の脆弱性であるMeltdownやSpectreによる脆弱性は存在しない。 ちなみに、現代の性能のコンピューターで、1フレームの描画に7時間ほどかかるので、このDOOMで遊ぶには若干の忍耐力を要求される。しかし、脆弱性の完全な排除のためには若干のパフォーマンスの低下はやむを得ないところだろう。 このDOOM実装はオリジナルのDOOMのCコードに若干の変更を施して、M/o/Vfuscatorでコンパイルしたものだ。 https://github.com/xoreaxeaxeax/movfuscator M/o/Vfuscatorとは、IntelのMMUがチューリング完全であることを
C/C++に組み込める軽量JavaScriptエンジン “QuickJS” を試す - Qiita
はじめに QuickJS は C/C++ に組み込める軽量な JavaScript エンジンである。ライセンスは MIT license。JavaScript を組み込みたいけれど V8 はオーバースペックすぎる、という時に有用と思われる。 デザインがシンプルすぎてかえって信頼感のある公式ページはこちら。 QuickJS Javascript Engine QuickJS is a small and embeddable Javascript engine. It supports the ES2020 specification including modules, asynchronous generators, proxies and BigInt. （訳：QuickJS は小さい・組み込み可能な JavaScript エンジンである。モジュール・非同期ジェネレータ・プロキシ・Bi
何がOS実装の理解を難しくしているのか(GNU assemblyのポイント)
OS内部どうなってんのか知っといた方がいいんだろうなぁ、と思っている人向けになんか書きたいなぁ、と思って書きました。 OSを理解しようとすると、初回は挫折感をあじわって退場するのですが、原因いろいろあると思います。 C言語、アセンブリ(gnu assembly)、ELF, linker scriptの知識 boot処理時(の登場人物)で混乱する マルチタスク処理(switching, interrupt)がわからん OS自作しようぜ、みたいなはじめから強い本が多い まぁ、最後のは冗談として(自分は凡人なので..)、 https://github.com/mit-pdos/xv6-public (Unix V6のx86(32bit) implementation。以下xv6と呼びます) と https://pdos.csail.mit.edu/6.828/2018/xv6.html がとても
車輪の再実装 - Cube Lilac
「俺のソースだから」というプログラマは死んだらいいのに - 神様なんて信じない僕らのために に関連して，Twitter で「車輪の再発明」の意義について少しやり取りをしていました． プログラマが避けて通れない道の一つに「車輪の再発明」があります．私自身が公開している CLX C++ Libraries を見ても「それ Boost で(ry」の嵐で，あの時は勢いで公開してしまった．正直，後悔している．できればなかった事にしてリストから消してしまいたいと言うものもたくさんあります． このように数多くのプログラマが「車輪の再発明」の罠に悩まされているのですが，車輪の再発明（より正確に言うと，車輪の再実装）にはそれなりに意義もあります．そこで，リンク元の記事の意図とはずれそうですが，今回は車輪の再実装の意義について． 再実装は背景を理解する作業 車輪の再実装の利点の一つとして，既存の実装（のインタ
C++のiostreamの<<を導入したのはストラウストラップ - Arantium Maestum
最近@karino2さんのポッドキャスト「プログラム雑談」のバックナンバーをいろいろ聴いている： anchor.fm 二週間ほど前に書いた聴いてるポッドキャストの記事ではまだ「気になっている」という分類だったのだけど、聴き始めたらいい感じにゆるいのと技術的な内容が面白いのと（そして本人の技術や生活に関する哲学が見えるのも）で、続けて聴いている。 2020年あたりの「ストラウストラップ本のエピソード」で： anchor.fm 「iostreamの<<構文を導入した人は何十年かに渡って『やっちまった』と思っているはず」という話があった。 ここら辺の： www.cplusplus.com のoperator<<メソッドをオーバーロードしてIO出力に使う構文の話だ。確かにあの構文はC++の見た目のユニークさの最たるもので、それはつまり後続言語にまったく模倣されなかったということだ。自作言語勢でも「
printf()を書くかわりに.gdbinitを書く - iakioの日記
わたしがprintf()デバッグをしない理由 2009-03-22 - 未来のいつか/hyoshiokの日記 というエントリを読んだ。 僕もわりと安易にprintf()してしまうのだけれど、以前は結構頑張ってgdbを使っていたのでちょっとそのころを思い出して書く。 printf()が便利なのは、それがコードとして残ることだ。IDEのデバッガだと同じ操作を何度もするのが面倒だったりするわけだけど。 でもgdbだと.gdbinitというファイルにgdbの操作を書いておくことができる。 例えばこんなしょーもないコードがあったとする(sum.c)。 int main() { int i, j; for (i = 1, j = 0; i <= 10; i++) { j += i; } return 0; } で、ここでjとiの内容を表示したいとする。printf()を入れたい気持を抑えてこんな.gd
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
大昔のgccのプリプロセッサに関する、極めてどうでもよい話 - のらりくらり
間違ったコードは間違って見えるようにする - The Joel on Software Translation Project