タグ別アーカイブ: Intel

レット・イット・ビープ:Googleの自動走行車がクラクションを鳴らすようになった | TechCrunch Japan

「当社の警笛アルゴリズムが改善されたため、われわれはクラクションを世界に発信し始めた」。

文のばかばかしさは置くとして、このニュースは実に興味深い。Googleは、これまでしばらくの間、自らの存在を他のドライバーに知らせる手段として、クラクシヨンを使用するテストをしてきたようだ ― ただし鳴らすのは室内でのみ。そうすることによって、人間の評価者は「警笛アルゴリズム」が的確かどうかを判断することができる。

関連記事

Intel buys computer vision startup Itseez to improve navigation in self-driving cars

NuTonomy raises $16M to make self-driving taxis a reality by 2018

Transportation technology will be the next Internet protocol

能力が何らかの社内基準に達したことで、自動走行車はクラクションを2種類の方法で使用できるようになった。危険が差し迫った時、例えば反対車線の車が向かってきた時等には、昔ながらのけたたましいクラクションが鳴る。しかし、駐車場で誰かがバックして近づいてきたような時には、「短く静かな警笛をピッピッと鳴らす」と報告書に書かれている。

ブーブーや「ピッピッ」以外にも、Googleカーは歩行者、特に視覚の不自由な人々に車の接近を知らせるための、ハム音を発生できる。これは多くの電気自動車に課せられた問題であり、エンジン音の模倣からUFOライクなさえずりまで、様々な案がテストされてきた。Googleの説明にあるハム音は前者に近いと思われ、「個性」を出すために何らかの工夫がこらされているようだが詳細は明らかにされていない。町でGoogleカーに遭遇した幸運な読者は、最初のレポートを書けるかもしれない。

引用元: レット・イット・ビープ:Googleの自動走行車がクラクションを鳴らすようになった | TechCrunch Japan.

スラムダンクを全周360°から再生できる―Intelがユニークな3Dビデオ合成のReplay Technologiesを買収 | TechCrunch Japan

IntelがReplayに注目した理由は、テクノロジーとしてクールだという点に加えて、コンピューターのハードウェアに密接に関係していることが挙げられる。レンダリング・サーバーには非常に多数のIntelチップが装備されている。NBAのスラムダンク・コンテスト中継で魔法のように3Dビデオが登場した裏には、アリーナの周囲に設置された28台の超高精細度カメラと、撮影された映像を瞬時に3D合成するReplayのソフトを搭載したサーバーの働きがあった。このサーバーには無数のIntelチップが搭載されていたわけだ。

引用元: スラムダンクを全周360°から再生できる―Intelがユニークな3Dビデオ合成のReplay Technologiesを買収 | TechCrunch Japan.

【後藤弘茂のWeekly海外ニュース】ARMがIoT向けにOSを無償提供開始 – PC Watch

IoT向けの開発ボードとソフトウェアスタックの提供で思い浮かべるのは、Intelの「Galileo」や「Edison」のプラットフォームだ。ARMのmbedは、Intelとぶつかるように見える。それに対して、ARMでIoTを担当するKris Flautner氏は、次のように答える。

「Intelのソリューションは、我々から見ると非常にハイエンドのモノで、ミニPCだ。それに対して、IoTで我々がフォーカスするのはもっと小さなモノだ。非常に安価で非常に小さく非常に低消費電力な、それが我々の側が見ている市場だ。両者は全く異なる」。

ARMの方はIoTのローエンドデバイスまで全てをカバーするソリューションであり、Intelのように、大型のチップによる高コストなソリューションとは異なるというのがARMの見方だ。言い換えれば、ARMは、IntelがまだIoTの土俵の上に登ることができていないと考えているようだ。

引用元: 【後藤弘茂のWeekly海外ニュース】ARMがIoT向けにOSを無償提供開始 – PC Watch.

スタックの誤謬―大企業が新分野参入でいつも失敗する理由を考える | TechCrunch Japan

スタックの誤謬はある意味で人間性の本質に基づくものだ。われわれは自分が熟知している分野こそ価値があると考えたがる。読者が仮に巨大なデータベース企業でチップを設計しているとしよう。CEOがあなたに「われわれはIntelやSAPと競争できるだろうか?」と尋ねたとする。「私がチップを開発したのはRDBソフトを走らせるためでそれ以上のことは分かりません」と正直に答えるエンジニアはまずいないだろう。逆に、それまでに蓄積されたチップ設計のノウハウをもってすれば、その上にERPアプリを走らせるという新たなレイヤーを重ねるのは簡単だと考えるに違いない。ERPなどといっても所詮はテーブルとワークフローにすぎない。

成功を阻むボトルネックは、ツールの詳細を知らないことによるのではなく、顧客のニーズを理解できないところに存在する。データベースのエンジニアは顧客が必要とするサプライ・チェーンの管理についてほとんど何も知らず、企業がどんなソフトを必要としているか理解できない。もちろんそうした分野を知っている専門家を雇い入れることはできる。だがそれは〔その企業の〕コア・コンピテンシーを向上させることにはならない。

引用元: スタックの誤謬―大企業が新分野参入でいつも失敗する理由を考える | TechCrunch Japan.

Timestamp-Counter Scaling for Virtualization White Paper – 教育は参考資料

CPU は温度の高低などによって周波数を上げたり下げたりするが、Intel の x86 CPU の Timestamp-Counter(TSC) は暫く前から CPU の実周波数とは独立して常に一定の時間でサイクルを刻む Constant TSC になっている。さらに CPU が深いスリープ状態になった場合にも TSC は止めずに動く Invariant TSC だ。

さらに仮想マシン用の機能としてゲストが TSC を読む RDTSC 命令を読んだ場合、ホスト側の CPU のリアル TSC に対して仮想マシンごとに設定されたオフセット値を足した値を返す TSC offset 機能が実装されている。RDTSC 命令は頻出実行命令だが、TSC offsetting があれば性能を落とさずに、かつ仮想マシン毎に矛盾のない値を返すことができる。ただ異なるホスト間のマイグレーションを行う場合、サーバーに装着された CPU の世代や周波数が異なっているかもしれない。CPU 周波数が高い CPU と低い CPU では TSC の刻みが異なるため、TSC offsetting だけではこの差を吸収できない。

今回、提示された機能はゲストが RDTSC 命令を使った場合にリアル TSC に係数をかけた値を返す TSC multiplier という機能だ。TSC offsetting と TSC multiplier を組み合わせることで、仮想マシンに設定された仮想 CPU 周波数どおりの進み方をする TSC を、異なる性能サーバー間をマイグレーションする環境下でも手に入れることができるようだ。

ただ現在のところ詳細は記述されていない。

引用元: Timestamp-Counter Scaling for Virtualization White Paper – 教育は参考資料.

Apple独自のWebクローラー「Applebot」、公式に認める – ITmedia ニュース

Appleがサポートページで公開した情報によると、Applebotは他社クローラーと同様にサイトのrobot.txtを尊重し、Applebotへの指示がない場合はGooglebotへの指示に従うという。

UserAgent表示には「Applebot」のほか、「Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/600.2.5 (KHTML, like Gecko) Version/8.0.2 Safari/600.2.5 (Applebot/0.1)」が含まれる。

Appleは2013年、Siriが受けた質問の参照先としてWolframAlphaに加え、米MicrosoftのBingを追加していた。

引用元: Apple独自のWebクローラー「Applebot」、公式に認める – ITmedia ニュース.

今後のNUCはどうなる?:米Intelがファンレス仕様の新型NUCを発表、“Broadwell”ベースNUCの投入計画も (1/2) – ITmedia PC USER

同社は、本会議にあわせて新しいNUC(Next Unit of Computing)として、組み込み向けAtomを採用した「DE3815TYKHE」を発表した。同製品は“Thin Canyon”(シン・キャニオン)の開発コード名からも分かるとおり、シンクライアントをメインターゲットに開発したNUCだ。

SoCにはBayTrailベースのAtom E3815を採用。最大動作周波数は1.46GHzのシングルコアで、5ワットのTDPに抑えられているため、ファンレス動作を実現している。メモリインタフェースはシングルチャネルのDDR3L-1066で、最大8Gバイトのメモリを搭載可能となっている(SoCのスペックでは、発表時は最大4Gバイトとされていた)。

ただし、安定したファンレス動作を実現すべく、2.5インチHDD/SSDを搭載するスペースを、基板横に設けているため、これまでのNUCとは異なり、40(幅)×116(奥行き)×190(高さ)ミリの細長いケースデザインへと変更された。また、オンボードストレージとして4GバイトのeMMCを搭載し、HDDレスでVirtual Desktopなどのデスクトップ仮想化環境を構築することもできる。

引用元: 今後のNUCはどうなる?:米Intelがファンレス仕様の新型NUCを発表、“Broadwell”ベースNUCの投入計画も (1/2) – ITmedia PC USER.

GoogleがサーバをIntelからIBMの「OpenPOWER」陣営に乗換え、Intelにとっては大打撃 – GIGAZINE

Googleが公開した新サーバ用のマザーボードは、IBMが開発したCPU「Power8」を搭載しています。Power8は最大周波数5GHzの12コア(96スレッド)、96MBのL3キャッシュを搭載するCPUで、従来モデルのPower7に対してシングルスレッドパフォーマンスが1.6倍、並列実行可能スレッド数を倍増したもので、2013年8月に発表されていました。GoogleはこのPower8搭載サーバ用マザーボードを、現在開催中のIBM Impact2014で発表するとしています。

これまでGoogleの巨大サーバ群はすべてIntelチップを搭載したもので、IntelにとってGoogleは大量の受注が見込める上顧客でした。GoogleがIntelサーバからIBMサーバに乗り換えることは、その関係が終了することを意味します。乗換に伴ってGoogleはハードウェア・ソフトウェアの両方を刷新する必要があるため、今回の決定はトラブル発生の危険を伴う大きな決断だったと言えます。

このようなリスクを冒してでもGoogleがサーバを乗り換えた理由としてWIREDは、「GoogleはIntelに頼りっきりの状態を継続することの方がはるかにリスクが高いと考えているのではないか」と推察しています。Googleがデータサーバを今後も増強し、さらに新サービスを次々投入していくためには、より高性能なサーバが必要になります。そのために、Intelに依存している今の姿勢を改めてIBMに大量の発注をかけることで「IBMサーバをIntelサーバに対抗できる存在へ育てる」というリスク分散策を採ったのではないか、という見方です。なお、IBMはPOWERマイクロアーキテクチャに基づくオープンな開発環境を促進する団体「OpenPOWER Foundation」を設立し、日立・Micron・Samsungなどの有力なIT企業がこれに参加することで、サーバ関連事業が勢いづいています。

引用元: GoogleがサーバをIntelからIBMの「OpenPOWER」陣営に乗換え、Intelにとっては大打撃 – GIGAZINE.

3Dプリンタ銃問題に対応できるかもしれない特許について | 栗原潔のIT弁理士日記

クレームは長いんですが、実質的に言っていることは、「設計データに対応する承認コードを受信した時だけ製造を許可する製造機械」といった感じでかなり範囲が広いです。「3DプリンタのDRM」特許とも呼ばれています。

権利者はThe Invention Science Fundですが、これはNPEとして有名なIntellectual Ventures(IV)の一組織である発明者部隊です。IVは他社から特許権を買い集めて、権利行使するという典型的NPEのオペレーションに加えて、社内でも一から発明を行なっています(そういう意味では、IVは、他のいわゆるパテントトロール的NPEとは微妙に違います)。

この特許の優先日(実質出願日)は2007年12月21日です。この時期はスタラタシス社による3Dプリンタの基本特許が2009年に切れる直前で3Dプリンタの民生部門での普及が予測されていた時期です。この特許の明細書には、3Dプリンタについての記載がないので、先を読んでいたのか、単なる偶然なのかは不明ですが、やはり広い特許を取るためにはタイミングは重要です(テクノロジーが普及してからその分野で広い特許を取るのは困難です)。

引用元: 3Dプリンタ銃問題に対応できるかもしれない特許について | 栗原潔のIT弁理士日記.

本の虫: Linux Torvalds、最近のCPUのPage Faultのコストにご不満の様子

syscallトラップのパフォーマンスは興味深いものだ。

15年前[訳注:この記事が書かれたのは2004年なので、1989年頃]、IntelとMicrosoftと会議があった(残念ながら、私はこの会議に参加していなかったので、この話は伝聞なのだが)

Microsoftというのは、Intelの最大の顧客のひとつなので、Intelの代表はよくMicrosoftを訪問して、最新のプロセッサーを紹介したり、カーネル開発部に新しいプロセッサーの機能をサポートするようロビーしたり、どのような機能を追加すれば、もっとも役立つかという知見を吸い上げたりしていた。

この会議で、Intelの代表がたずねた。「でさ、たったひとつだけ、速くして欲しいところがあるとすれば、どこ?」

躊躇なく、カーネルの開発主任が答えた。「無効命令のfaultingの高速化」

Intel社員は笑い転げた。「いやぁ、Microsoftのエンジニアは愉快でいらっしゃる」というわけで、会議は冗談で締めくくられた。

研究所に戻った後、IntelのエンジニアがWindowsカーネルのプロファイルをしたところ、驚くなかれ、彼らはWindowsがかなりの時間を、無効命令例外をさばくためにつかっていることを発見したのである。何だと! ひょっとして、Microsoftのエンジニアは冗談を言ったのではなかったのか?

冗談じゃない。

この当時の80386チップで、V86モードからカーネルモードに移行する最速の方法は、無効命令を実行することだったのだ! そのため、Windows/386は、無効命令をsyscall trapに使っていたのであった。

この話の教訓? よくわからない。たぶん、何か物を作ったならば、それが作成者の意図しない方法で使われるだろうということか。

引用元: 本の虫: Linux Torvalds、最近のCPUのPage Faultのコストにご不満の様子.