開発物語

  • 神楽坂ショールーム
  • 資料請求・お問い合わせ
  • 概算見積もり

コンパイルされたマシン語とCPUの挙動(実行サイクル数)まで意識した高速化プログラミング

ネオレックスの技術者には、アセンブラやマシン語にも精通し、CPUの実際の挙動まで意識をしながらプログラムを書いている人たちがいます。

例えば、コンピューターに計算などのある処理をさせようとするとき、それを実現するためのプログラムの書き方(コーディング)は何通りもあります。

それらは同じ結果が得られるわけですが、CPUが実際に処理する分量=動作速度がかなり違ってくる場合があります。

以下のお題について考えてみたいと思います。

お題「変数aの値を15倍して変数bに格納する」

実は「15倍する」という計算は、コンピュータは元々それほど得意ではありません。
でも「16倍する」という計算は得意なんです。

私たちは普段、数を10進数で扱いますが、コンピュータは数を2進数で持ちます。
10進数では、1を、

  • 10倍すると「10」に、
  • 100倍すると「100」に、
  • 1000倍すると「1000」に、

となります。
計算するというより、桁をずらして後ろに0を補うだけですね。

同じように、2進数では、1を、

  • 2倍すると「10」に、
  • 4倍すると「100」に、
  • 8倍すると「1000」に、
  • 16倍すると「10000」に、

という風に、2の累乗の計算は桁をずらして後ろに0を補うだけということになりますので、コンピュータはこういう計算が得意なのです。

例えば「a = 5」とすると、2進数では「101」ですので、16倍は後ろに0を4つ補って「1010000」となります。 お題は15倍ですので、この結果からaを1つ分引いて15倍にします。

私たちが暗算する時に「8 × 999」を「8 × 1000から8を引く」とすると簡単になるのと同じ考え方です。

動作速度を比較

このコーディングの違いが具体的にどの程度の差になるかを見るために、C言語で書いたコードがどのようにコンパイル(変換)されるかを表にしてみました。C言語、アセンブリ言語になじみのない方は「実行サイクル」だけを見ていただければと思います。実行サイクルは各行の命令を実行するため掛かる時間を表しています。

共通条件

プログラムの開始番地 変数aのメモリ番地 変数bのメモリ番地
0x00000100 0x10203040 0x10203044

お題をそのままコーディングした場合
「お題をそのままコーディングした場合」の比較表

16倍してからaを引く場合
「16倍してからaを引く場合」の比較表

マシン語のダンプリスト比較
マシン語のダンプリスト比較表 マシン語のダンプリスト比較表

プログラムのサイズは偶然どちらも17byteと同じですが、実行速度は平均で2.4倍も速くなることが期待できます。

このように、同じ処理であってもプログラムの書き方次第で動作速度が大幅に違ってくることがあるため、コンパイルされたプログラムがどのようなマシン語となり、その処理が何サイクル程度になるのかというCPUの実際の挙動への意識が時に大変重要になります。

最近は、強力な最適化機能を持ち、こうした配慮があまり必要ないコンパイラも出てきています。また、一部の処理の実行サイクルを大幅に短縮したCPUも出てきています。

しかし、プログラムが最終的にマシン語となり、そのマシン語がCPUによって処理されるという原理には変化はありません。

マシン語やCPUへの配慮により、より良いシステムを開発することができる。あるいは、こうした配慮がなければ、思わぬパフォーマンスダウンや不具合に見舞われることがある。

私たちネオレックスは、このような思想を持って毎日のバイバイ タイムカードの開発に取り組んでいます。

今回の記事は、分かりやすさを優先し、インテルi386プロセッサとその当時のコンパイラという少し古いものの挙動をベースにまとめています。
本文中にあるように、最近のコンパイラやCPUは以前に比べて高性能になっています。例えば「b = a * 15;」とコーディングしても自動的に「b = (a << 4) - a;」と読み替えるコンパイラや、本記事で実行サイクルが9~38となっている「mul ebx」を2~3サイクルで実行できるCPUが登場しています。
このため、CPUやコンパイラの特性や挙動を理解していないと、動作速度を上げるつもりの工夫が逆に動作速度を遅くしてしまう結果となることもあり、注意が必要です。

(畠山 裕)

バイバイタイムカード for iPad 刷新プロジェクト その1

どうも、はじめまして、ネオレックスの永遠のルーキー、中村です。

私達が自信を持って提供させていただいているiPad打刻機、
バイバイタイムカード for iPad の刷新の話を数回に分けて書こうと思います。

続きを読む...

クラウドサービスの応答速度

先日バイバイ タイムカードのサーバレスポンスタイムを発表しました。

私たちは快適な操作感の提供を目指すうえで、サーバレスポンスタイム(応答速度)は、とても重要な要素だと考え、力を入れてきました。

続きを読む...

PDF生成モジュールの開発

バイバイ タイムカードの出勤簿や勤務表などのPDFを生成しているPDF生成モジュールが新しくなりました!

これまでは、一般に販売されているPDF生成モジュールを利用していたのですが、バイバイ タイムカードで要求されるパフォーマンスを実現出来なかったため、

「じゃあ作っちゃおう!」

っということになりました^^

続きを読む...

PDFの圧縮

PDFでダウンロードする帳票の種類や利用量が増えてくる中で、1つのプログラムで、設定によって様々な種類の帳票を効率よく提供するため、PDFファイルの圧縮に取り組みました。

結果、ファイルサイズが半分程度まで小さくなり、サーバーでのPDFファイルの生成時間、ダウンロード時間、更に、手元のPCでこれらのファイルを開く時間やスクロール操作の速さまで、全てが大きく改善されました!

実現方法はと言うと・・・

続きを読む...

4万人突破!

とうとうバイバイ タイムカードの利用者数が4万人を超えました!

プレスリリース:
利用者総数が4万人を突破 - ASP型 勤怠管理システム バイバイ タイムカード

毎日のように4万人もの人々が、出勤、退勤の時にバイバイ タイムカードで
打刻をしている。

「あ、いけね、バイバイ タイムカード忘れてた」とつぶやく人がいたり、

「おい、早くバイバイしろよ!」と残業続きの部下に声をかける上司の人がいたり・・・

続きを読む...

サーバーシステムを全面刷新!

バイバイ タイムカードのサーバーシステムが全面刷新しました!

昨年から今年にかけて、バイバイ タイムカードをご利用頂いている方の人数が1万人ちょっとから4万人弱と約3倍になり、今後もユーザーさんが増えていく見込だったため、思い切っての全面刷新となりました。

続きを読む...

BTデータ構造

バイバイ タイムカードのデータベースは、「1打刻1レコード」というデータ構造をしています。
(以下仮に、この方式を「BTデータ構造」といいます。「BT」とは、バイバイ タイムカードの略称です。)

「1従業員1日1レコード」という構造も考えられ、多分一般的にはそちらの方が多いだろうなとは思われますが、あえて選んだのが「1打刻1レコード」という方式です。
(以下仮に、「1従業員1日1レコード」の方を「一般データ構造」といいます。)

続きを読む...

バイバイ タイムカード開発の検討に至るまで

「勤怠管理業務に特化した、ASP型のシステムを開発する」っと考え始めたのは、2003年の4月頃でした。

当時ネオレックスは、飲食店をチェーン展開している企業向けに統合管理システムを開発し、販売していました。

続きを読む...

「バイバイ タイムカード」という名前

ASP型の勤怠管理システムを開発し、提供しようと考え始めたのは、2003年の4月頃でした。

その経緯やその頃に考えたことなどはまた別の機会に、としまして、今回は「バイバイ タイムカード」という名前についてのお話です。

続きを読む...

  • バイバイ タイムカード日記

このページの先頭へ