タグ

ブックマーク / qiita.com/methane (8)

  • mimalloc のメモリ管理 - Qiita

    Microsoft の mimalloc は面白い割り切り方で、小さいソースコードで高速なアロケータを実装しています。 確保するメモリブロックのサイズを、 Small (~8KiB), Large (~512KiB), Huge (512KiB~) の3つに分類し、 Small と Large は同じアルゴリズムで管理し、 Huge は OS 任せにして、 Small と Large は同じアルゴリズムをうまく利用しています。 基礎 OSはpage (x86では基本 4KiB) ごとにメモリをプロセスに割り当てています。 しかしアプリケーションではずっと小さいメモリブロックが必要になることが多くあります。また、必要になるたびに毎回OSからメモリを割り当ててもらうのはパフォーマンスも悪いです。 mimalloc やその他の malloc 実装 (以降 malloc と呼びます) は OS か

    mimalloc のメモリ管理 - Qiita

  • Rubyist が pyenv を使うときに知っておいてほしいこと - Qiita

    はじめに 機械学習ブームなどにより、 Python を触り始める Rubyist が増えてきたと思います。その際に問題になりやすいのが環境構築です。Rubyだと rbenv がデファクトスタンダードになっているのに、なぜか Python には pyenv に否定的な意見が多いんですよね。 私は pyenv を使っていますし、便利だと思っています。また、 Ruby は殆ど使わないのですが、RubyとPythonのツールスタックの違いについても調べました。 (参考: gem, bundler と pip, venv の比較) その視点から、 Rubyユーザーが自分でpyenvの使い方を自分で決める上で知っておいた方が良いだろうなと思う Ruby と Python の環境の違いをまとめてみます。 tl;dr 丁寧に解説しても、「Python使うにはこんな長い記事を読まないといけないの」とすぐに否

    Rubyist が pyenv を使うときに知っておいてほしいこと - Qiita

  • Go が他の多くの言語での非同期プログラミングよりも優れている理由 - Qiita

    はじめに 非同期プログラミングと呼んでいるのは、ノンブロッキングIOと select, poll, epoll, kqueue のようなIO多重化を利用したネットワークアプリケーションを書くことです。 node.js で websocket 使ったチャットを書くとかそういうのです。 「他の多くの言語」とは、 Python (asyncio), node.js, C# などを想定しています。 Erlang や GHC なんかは Go に近いかも知れません。 async / await がない言語では、「コールバック地獄」や「deferred地獄」のような問題もありますがこの記事では扱っていません。 async / await のメリットを解説した他の記事を参照してください。 あとこの記事は主にランタイムに関する部分を扱っているので、「それは言語じゃなくて処理系の問題だ！」等の頓珍漢な揚げ足取

    Go が他の多くの言語での非同期プログラミングよりも優れている理由 - Qiita

  • [翻訳] Why Go? - Qiita

    (この記事は Dave Cheney さんの Why Go? の翻訳です。) 数週間前、友人に「Goに注目に値するのはなんで？」と聞かれました。 彼は私がGoに情熱を注いでいることを知っていましたが、なぜ私が他の人もGoを気にするべきだと思っているのかを知りたいようでした。 この記事は、私がGoを重要なプログラミング言語だと考える、3つの大きな理由を紹介します。 メモリ安全 個人としては、私もあなたもC言語でメモリリークも危険なメモリの再利用もしないプログラムを書く事ができるでしょう。しかし、40年以上の経験から、集団としてのプログラマーはC言語で信頼できるプログラムを書けない事がはっきりしています。 コードの静的解析、 valgrind, tsan (訳注: たぶん ThreadSanitizer), -Werror といったツールは10年以上前から使えますが、それらのツールが広く認知さ

    [翻訳] Why Go? - Qiita

  • エラーを検査する - Qiita

    NOTE: この記事は Inspecting Errors を翻訳したものです。 原文に従い、 Creative Commons ライセンスで公開します。 error インターフェイス型の値を返す関数の一般的な契約は、呼び出し側はその error をチェックする前にそれ以外のいかなる戻り値も利用してはいけないというものです。 多くのケースにおいて、関数が返した error 値は呼び出し元にとって不透明であるべきです。 error が nil かどうかチェックすることで呼び出しが成功したかどうかを知ることができ、そしてそれ以上のことはしません。 少ないケースにおいて、主にネットワークなどプロセス外の世界とやりとりする場合に、呼び出し側がエラーの種別を調べて、操作をリトライするべきかどうかを決める必要があります。 パッケージ作者に対して、呼び出し側がエラーの型を判別して利用できるように返すエラ

    エラーを検査する - Qiita

  • Go の Prepared Statement は Connection を気にせず使える - Qiita

    コネクションプールと prepared statement database/sql は、トランザクションを除いて基本的にコネクションをユーザーに見せず、全ての操作をコネクションプール sql.DB を通して行う設計になっています。 コネクションプールと言えば、 prepared statement の実装が気になります。 prepared statement は基本的にコネクションに紐付いていて、 プレースホルダ付きのクエリを投げてコネクションローカルの「ハンドル」を貰う 「ハンドル」にパラメータを送ってクエリを実行する 「ハンドル」を閉じる（あるいはコネクション自体を閉じる） という流れになるので、コネクションプールと組み合わせて使う場合には、 毎回ハンドルを取得＆開放する (１クエリに３回通信が発生) ハンドルを開放しない (DBサーバー側のリソースを食いつぶす) コネクションごとに

    Go の Prepared Statement は Connection を気にせず使える - Qiita

  • Python 3.4 から標準ライブラリに入る Enum 型が今からでも便利 - Qiita

    今年3月にリリース予定の Python 3.4 から、 enum が追加されます。 (ドキュメント) Python 2.4 から使えるバックポートが開発されており、 pip install enum34 でインストールできます。 enum が欲しい理由 今までも例えばこんな方法で定数を定義していました。 しかし、この方法には以下のような問題点があります。 デバッグ時など、ただの整数値が表示され、意味が分かりにくい 値から名前を引く方法を自作しないといけない 列挙する方法も自作しないといけない アドホックに解決したり、ライブラリがあったりしたんですが、これくらい標準ライブラリに欲しいですよね。で、標準ライブラリに入ったんだから、使いましょう。 シンプルな使い方 namedtuple と同じく、最初に形名、次に名前の一覧のリスト、あるいは空白区切りの文字列を渡すと、勝手に1から順番に値が割り振

    Python 3.4 から標準ライブラリに入る Enum 型が今からでも便利 - Qiita

  • 最速最強Webサーバーアーキテクチャ - Qiita

    POST /post HTTP/1.1 Host: localhost Content-Type: application/x-www-form-urlencoded Content-Length: 7 foo=bar 1行目は request-line で、 method URI HTTP-version の形をしています。URIはホストを含めた絶対URIの場合と、ホストを含めない絶対パスの場合がありますが、絶対パスの方が一般的です。 2行目から空行までが request-header です。各行は field-name: field-value の形をしています。 field-name は大文字小文字を区別しません。 request-line から request-header とそれに続く空行まで、改行は CR LF になってます。Windowsでよく見る改行コードですね。 meth

    最速最強Webサーバーアーキテクチャ - Qiita
  • 1

お知らせ

もっと読む

公式Twitter

  • @HatenaBookmark

    リリース、障害情報などのサービスのお知らせ

  • @hatebu

    最新の人気エントリーの配信

はてなブックマーク

公式Twitter

はてなのサービス

  • App Storeからダウンロード
  • Google Playで手に入れよう
Copyright © 2005-2024 Hatena. All Rights Reserved.