並び順

ブックマーク数

期間指定

  • から
  • まで

121 - 135 件 / 135件

新着順 人気順

Memoryの検索結果121 - 135 件 / 135件

  • モバイルアプリ上の WebAssembly 製ライブゲームで発生した例外を捕捉して計測する - Mirrativ Tech Blog

    こんにちは、エンジニアのちぎら(@_naru_jpn)です。ミラティブでは、配信中のゲームに視聴者が介入できるゲームとライブ配信が融合した次世代のゲーム体験を提供しており、この体験を ライブゲーミング と呼んでいます。 ライブゲーミングは、Unity から WebGL 向けにビルドされた WebAssembly 製のゲームを、アプリに配置したウェブブラウザ上で動作させることによって実現しています。*1 今回は UnityでモバイルWebGLゲーム開発を頑張る話 の「メモリリークによって発生するクラッシュ」にも書かれているような、捕捉は難しいがユーザー影響があるような例外の発生を捕捉して、計測をするための仕組み作りについて解説をします。 ライブゲームが動作する仕組み 例外を捕捉することを考える前に、ライブゲームがどのように動作しているのかを知る必要があります。 Unity の WebGL 向

      モバイルアプリ上の WebAssembly 製ライブゲームで発生した例外を捕捉して計測する - Mirrativ Tech Blog
    • memcached proxyで使うハッシュアルゴリズムを比較した話 - Mirrativ Tech Blog

      memcached proxyのハッシュアルゴリズム比較 はじめまして!hibikiです(@add_bakkers) 現在大学3年生で、最近はネットワークに興味があり勉強中です。2023年8月からインフラチームにインターンとして参加しました。 本記事ではmemcached proxyのハッシュアルゴリズム比較の結果を紹介します。 memcached proxyのハッシュアルゴリズム比較 1. 背景と目的 ミラティブでのmemcachedの利用 課題: クライアントサイドでサーバ決定をしている memcached proxyの検討 2. memcached proxyに求められるアルゴリズム キーの分散 移動率の抑制 パフォーマンス ハッシュアルゴリズムの比較 3. 今回行うベンチマークの概要 計測対象とシナリオ 分散と移動率のベンチ 処理性能のベンチ 4. ベンチマークの結果と比較 移動率

        memcached proxyで使うハッシュアルゴリズムを比較した話 - Mirrativ Tech Blog
      • Ruby 3.3’s YJIT Runs Shopify’s Production Code 15% Faster

        Ruby 3.2 YJIT is Battle-Tested Shopify deploys YJIT on business-critical services in production, such as Storefront Renderer, the software that powers all online storefronts on Shopify’s platform, and Shopify’s Monolith. As of the Ruby 3.2 release, YJIT sped up our Storefront Renderer by 10% on average. Storefront Renderer is a complex application. Your more reasonable-sized app might get better/w

          Ruby 3.3’s YJIT Runs Shopify’s Production Code 15% Faster
        • Apple Silicon (M1/M2)MacでのVagrant+VirtualBoxの代替手段 - GMOインターネットグループ グループ研究開発本部

          みなさんこんにちは、グループ研究開発本部 AI研究開発室のK.Fです。 これまで、Intel MacでVirtualBox + Vagrantを利用してCentOS 7の仮想(VM)環境を利用していたのですが、Apple Silicon MacにPCを乗り換えたので、代替方法がないか調査してみました。 結論 Ubuntu 22.04/aarch64 on multipass -> CentOS 7/x86_64 on vagrant + libvirt が最もよい 動作は少し遅いと感じることがあるが、x86_64をエミュレートしているので本番との環境差分が少なくなってうれしい 1. はじめに 筆者の環境 MacBook Pro 14 inch, M2 Pro, 32GB RAM MacOS Ventura 13.4.1 なるべくこれまで使ってきたVagrantfileを変更したくないので、

            Apple Silicon (M1/M2)MacでのVagrant+VirtualBoxの代替手段 - GMOインターネットグループ グループ研究開発本部
          • Vim で SQL を素で編集してるの?

            タイトルは釣りです。 この記事は Vim Advent Calendar 2023 16 日目の記事です。 はじめに みなさんは SQL はどんな環境で編集しているでしょうか? Visual Studio Code?それとも Vim?まさか Vim/Neovim の素の状態で編集していたりしませんよね? 僕はしていました。 sqls (SQL Language Server) 以前、lighttiger2505 さんが開発した sqls に少しコントリビュートしていた頃がありました。 既に public archive になってしまっていますが、機能として実用的なままです。コントリビュートしていた頃は、あくまで OSS としての興味の方が大きく、如何に機能的にしていくかだけ着目していたため、常用はしていませんでした。 あらためて常用してみる sqls の導入 Vim から sqls を使う

              Vim で SQL を素で編集してるの?
            • 【LLMの研究者向け】400本を超えるLLMに関する論文のリストを公開・更新しています - Qiita

              自身の研究のためにLLMに関する論文を表形式でまとめています。 このレポジトリでは特にさまざまな分野の論文を表にする(Comprehensive)ことを目的としています。具体的には以下のキーワードに注目しています。 CoT / VLM / Quantization / Grounding / Text2IMG&VID / Prompt / Reasoning / Robot / Agent / Planning / RL / Feedback / InContextLearning / InstructionTuning / PEFT / RLHF / RAG / Embodied / VQA / Hallucination / Diffusion / Scaling / ContextWindow / WorldModel / Memory / ZeroShot / RoPE / Spe

                【LLMの研究者向け】400本を超えるLLMに関する論文のリストを公開・更新しています - Qiita
              • Elasticsearchのパフォーマンス問題をプロファイラを使って解決する | メルカリエンジニアリング

                search infra teamのmrkm4ntrです。我々のチームではElasticsearchをKubernetes上で多数運用しています。歴史的経緯によりElasticsearchのクラスタは全てElasticsearchクラスタ専用のnode pool上で動作していました。ElasticsearchのPodは使用するリソースが大きいため、このnode poolのbin packingが難しくコストを最適化できないという問題がありました。そこで全てのElasticsearchクラスタを専用のnode poolから他のワークロードと共存可能なnode poolへ移行しました。ほとんどのクラスタが問題なく移行できたのですが、唯一移行後にlatencyのスパイクが多発してしまうものがありました。 この記事では、その原因を調査する方法と発見した解消方法について説明します。 発生した現象 共

                  Elasticsearchのパフォーマンス問題をプロファイラを使って解決する | メルカリエンジニアリング
                • 2024年の今、いかにしてVS2005を捨ててVS2015にする戦いは終わったか、そしてなぜCOMとの苦しい戦いが繰り広げられたか ~再入の悪魔~ - OPTiM TECH BLOG

                  概要 Optimal BizのWindows AgentはながらくVisual Studio 2005とVisual Studio 2015を併用してビルドする必要がありました。Visual Studio 2015化対応は2012年のVisual Studio 2012化対応からスタートしていましたが、対応範囲の大きさからモジュールごとにVisual Studio 2015化対応を行ってきました。そして2024年リリースのBiz 9.19.0にてVisual Studio 2015化対応は完了を迎えました。 しかし、埋め込まれたバグの修正にはCOMの理解が不可欠であったため、2020年代に突入した今になって私達はこれまで正面戦争を避けてきたCOMを0から学び直す必要がありました。そしてATLの不思議な挙動やSTAにおける再入との戦いを乗り越え、無事にリリースされました。 はじめに Opti

                    2024年の今、いかにしてVS2005を捨ててVS2015にする戦いは終わったか、そしてなぜCOMとの苦しい戦いが繰り広げられたか ~再入の悪魔~ - OPTiM TECH BLOG
                  • 多数のWindowsでブルースクリーンを発生させてしまったCrowdStrikeのコードは何が悪かったのか

                    世界中のWindows搭載PCにおいてブルースクリーンオブデスを発生させてしまったCrowdStrikeの問題について、エンジニアのパトリック・ワードル氏が原因を分析してXに投稿しました。 I don't do Windows but here are some (initial) details about why the CrowdStrike's CSAgent.sys crashed Faulting inst: mov r9d, [r8] R8: unmapped address ...taken from an array of pointers (held in RAX), index RDX (0x14 * 0x8) holds the invalid memory address@_JohnHammond pic.twitter.com/oqlAVwSlJj— Patri

                      多数のWindowsでブルースクリーンを発生させてしまったCrowdStrikeのコードは何が悪かったのか
                    • bpftraceによるGoアプリケーションのトレース|hayajo

                      はじめにシステムの状態を的確に捉え、運用に必要なインサイトを継続的に得るための特性は「オブザーバビリティ」と呼ばれます。オブザーバビリティを実現することで、パフォーマンスのモニタリングやトラブルシューティングを効果的に行い、システムの信頼性を高めることができます。 この重要な特性を実現する上で、eBPFやbpftraceは強力なツールとなります。 本記事では、Goアプリケーションにおけるオブザーバビリティを実現するための一つの方法として、bpftraceを用いたトレースの手法を紹介します。 内容が多いため、目次を活用して段階的に読み進めることをお勧めします。 eBPFとbpftraceはじめに、eBPFとbpftraceについて簡単に説明します。 eBPFとはeBPF(Extended Berkeley Packet Filter)はLinuxカーネル内で動作する柔軟なプログラミングフレー

                        bpftraceによるGoアプリケーションのトレース|hayajo
                      • CrowdStrike社のセキュリティソフトに起因するWindowsのシステム障害(BSOD)について - セキュリティ事業 - マクニカ

                        CrowdStrike社のセキュリティソフトに起因するWindowsのシステム障害(BSOD)について 7月19日に発生しましたWindowsを搭載したパソコンでの全世界的なシステム障害につきまして、CrowdStrike社(以下CS社)のセキュリティソフトFalcon Sensorのアップデートに起因する障害であると、同社から連絡を受けております。マクニカでは、CS社の国内販売代理店として、本障害に関する情報を入手し次第、弊社ホームページ上にてご報告してまいります。 すでに、CS社からは、問題の原因は突き止め、復旧とお客様へのサポートに全力を尽くしていると報告を受けています。弊社でも、現在、ご契約のお客様の業務が復旧するよう全力でサポートに当たっております。お客様、販売パートナー様におかれましては、下記を参考の上、ご不明な点等ございましたら、弊社問い合わせ先までご連絡いただけますよう、ご

                          CrowdStrike社のセキュリティソフトに起因するWindowsのシステム障害(BSOD)について - セキュリティ事業 - マクニカ
                        • postgres.new: In-browser Postgres with an AI interface

                          Introducing postgres.new, the in-browser Postgres sandbox with AI assistance. With postgres.new, you can instantly spin up an unlimited number of Postgres databases that run directly in your browser (and soon, deploy them to S3). Each database is paired with a large language model (LLM) which opens the door to some interesting use cases: Drag-and-drop CSV import (generate table on the fly) Generat

                            postgres.new: In-browser Postgres with an AI interface
                          • 最新の Google Gemma モデルを MLX を使ってローカルでファインチューニング|alexweberk

                            今回は、最新の Google Gemma モデルを Apple Silicon に最適化されたライブラリ MLX を使ってローカルで実行したり、ファインチューニングしてみましたのでその手順を紹介します。 MLX 関連の情報はドキュメンテーションが分かりづらいものも多かったので色々試した経緯も共有しながら少しでも何かの参考になれば幸いです。 実際に使った Jupyter Notebook を Gist にアップロードしていますので、そちらも参考にしてください。 →Google Gemma モデルを MLX を使ってローカルでファインチューニング 事前準備必要なライブラリをインストールします。 また Apple Silicon 搭載の Mac が必要です。今回は M3 Max 128GB 搭載の MacBook Pro で実行しました。 !pip install -U mlx mlx_lm t

                              最新の Google Gemma モデルを MLX を使ってローカルでファインチューニング|alexweberk
                            • ちょっとJavaのsynchronizedをGoに移植しようとしたはずが、なぜか1万文字の作文ができた - エムスリーテックブログ

                              AI・機械学習チームのブログリレーも9日目になりました。同チームの横本@yokomotodです。 本日はJavaとGoを題材に並行プログラミングまわりの自由研究をしたお話をしてみたいと思います。 3部構成で、パート1では発端となった「排他制御」について、パート2では「メモリの可視化」について、それぞれJavaとGoを比べてみました。 最後にパート3では、それらの動作を規定する「メモリモデル」について、わかりやすく解説されているリソースを紹介します。 長過ぎる! 3行で!! パート1: synchronized = 「排他制御」? Java synchronized vs Go sync.Mutex Goで再入可能なロック? 仮にGoで再入可能なロックを実装するなら? Javaが再入可能を選択した理由 パート2. sycnhronized = 「排他制御」+「メモリ可視性の保証」 Javaの

                                ちょっとJavaのsynchronizedをGoに移植しようとしたはずが、なぜか1万文字の作文ができた - エムスリーテックブログ
                              • Why choose async/await over threads?

                                A common refrain is that threads can do everything that async/await can, but simpler. So why would anyone choose async/await? This is a common question that I’ve seen a lot in the Rust community. Frankly, I completely understand where it’s coming from. Rust is a low-level language that doesn’t hide the complexity of coroutines from you. This is in opposition to languages like Go, where async happe

                                  Why choose async/await over threads?