タグ

最適化とプログラミングに関するmohnoのブックマーク (5)

  • 高速なC#を書くために知っておくべきもの

    2025/07/29 dnSpy追加 Xでフォークの存在を教えてもらいました。 2025/07/28 RoslynPad追加 2025/07/27 リンクを基そのまま貼るように変更 C# docsを.NET documentationに変更 Advanced .NET programming documentationnについて追加 Compiler Explorerについて追加 perf-bookについて追加(その他記事) はじめに C#を最適化するために知っておくべき情報源、ツール、コミュニティをまとめました。 具体的な最適化テクニックよりも、個人の経験をもとにどこで学び、どう検証するかに焦点を当てて紹介していきいます。 とにかく知ってもらうこと重視なので、解説は最低限。 ドキュメントを読んで。 筆者について この記事の執筆時(2025年7月現在)、筆者はプログラミングとC#を学び始

    高速なC#を書くために知っておくべきもの
    mohno
    mohno 2025/07/28
    リンク集か。あんまり追いかけてないというか、追いかけなくても十分便利というか(←オイ)
  • [速習] 配列から欠けている数字を見つける「XORトリック」の深い理論と実践 - Qiita

    皆さんは『配列から欠けている数字を見つけろ』と言われたら、どう答えますか? 多くの方は「HashSetで解けばいい」と考えるでしょう。しかし、1000万個の要素で実測したところ、Pythonのsetは945MBもの追加メモリを消費し、処理に2.3秒かかりました。一方、XORを使った解法は追加メモリゼロ、C言語なら1ミリ秒で完了します。 なぜこれほどの差が生まれるのか? XORには単なるトリック以上の深い理論があり、配列の欠損値検出だけでなく、RAID 5のデータ復元やネットワークのエラー検出など、実務で幅広く応用されているのです。 追記: ネットワーク転送時のパケットロスやノイズによるデータ欠損、さらには宇宙線がメモリに衝突してビットが反転する「ソフトエラー」により、配列から要素が失われることがあります。 記事では、Florian Hartmannの「That XOR Trick」1を基

    [速習] 配列から欠けている数字を見つける「XORトリック」の深い理論と実践 - Qiita
    mohno
    mohno 2025/07/07
    『配列から欠けている数字を見つけろ』←どんな状況?というか、“チェックサム”なんてのがあったわけで、加算じゃダメなの?あれ、遅いの?ってオーバーフローを考慮してlong?同じビット数でやれよ。なんかなあ。
  • 今日からできる!簡単 .NET 高速化 Tips -2024 edition-

    C# / .NET における、パフォーマンス改善の Tips をお届けします。 これを見れば、効率良く 80 点を取ることができるようになるはずです!

    今日からできる!簡単 .NET 高速化 Tips -2024 edition-
    mohno
    mohno 2024/04/28
    .NET(旧.NET Core)のときに .NET Framework より格段に高速化されたと聞いて、そんな余地があったのか、とは思ったな。/後半、知らない話が。でもハードル上がっちゃう気も。/もう、あまり考えたくない(←オイ)
  • strlen() の深淵 - Qiita

    あらまし strlen() という関数がある。御存知の通り、文字列の長さを算出する標準 C ライブラリの関数だ。 やってることは単純で、例えば以下のように実装できる。 size_t strlen_simple(const char* str) { const char* p = str; while (*p) ++p; return size_t(p - str); } '\0' が見つかるまでポインタを進め、初期位置との差分を返すだけだ。これで機能的には std::strlen() と同等である。 では、速度的にはどうだろう?適当にベンチマークを書いて MSVC 2022 でコンパイル&実行するとこうなった。

    strlen() の深淵 - Qiita
    mohno
    mohno 2023/08/07
    今どきのコンパイラは大変だなあ。/インライン展開は速いままだとコード量が増えるんだろうな。
  • それ、非再帰で書けます - Qiita

    まだ再帰関数書いてるの? 再帰関数はプログラミング言語の有用な機能で、深さ優先探索をベースとする様々なアルゴリズムの実装として有用です。 その一方で、関数呼び出しはオーバーヘッドが大きく、定数倍が弱くなります。また、JavaPythonなどのスタック領域の制限が厳し目の言語では深すぎる再帰のせいでRuntime Errorが発生する場合があります。 C++などのコンパイル言語ではインライン展開によって関数呼び出しのオーバーヘッド解消されることもありますが、再帰関数は中でもインライン展開の難易度が高く、深い再帰ではそのまま実行せざるを得ない状況になります。 ところが、再帰関数は生のスタックを自分で用意するなどして非再帰に書き直すことができます。(「停止する再帰的処理は常に同じ時間・空間計算量の非再帰処理に書き換えられる」、真っぽいのですが厳密な証明が見つけられなかったのでもしかしたら反例が

    それ、非再帰で書けます - Qiita
    mohno
    mohno 2022/12/20
    再帰は知識として知るべきだし、分かりやすくなる場合はあるけど、業務では影響が明確でない限り使わないなあ。「富豪プログラミング」的には気にすべきじゃないかもしれないが。「再帰ではセグフォってしまいます」
  • 1