Apple、1万行の手動で最適化されたアセンブリー・コードを書いたカメラアプリ会社を買収

Apple、iPhoneのカメラでフル解像度毎秒30枚の撮影ができるアプリのスタートアップ、SnappyLabsを買収
Josh Constine 2014年1月6日

Appleはファウンダーがたった1人で運営しているカメラ・テクノロジーのスタートアップ、　
SnappyLabsを買収したという情報が入った[アップデート：2014/ 1/5 太平洋時間9：15am：Appleはこの買収を確認した] 。

SnappyLabsのファウンダー、John Papandriopoulosはメルボルン大学から電気工学の博士号を得た技術者で、
彼の発明したテクノロジーにより、SnappyCamはフル解像度でiPhoneのカメラで毎秒20コマから30コマの画像を
フル解像度で撮影することができる。
(中略)
PapandriopoulosはiPhoneのカメラで静止画の高速連写を可能にするSnappyCamをApp Storeで1ドルで販売してきた。
私が7月に紹介記事を書いた後、Papandriopoulosは「SnappyCamは9カ国で有料アプリのトップにランクインした」と
知らせてきた。この売上のおかでPapandriopoulosはベンチャーキャピタルに頼ることなく運営を続けることができたものと思われる。

Papandriopoulosは7月、私の取材に応えて「離散コサイン変換に関してインスピレーションが閃いた。
それによってJPG画像フォーマットを事実上まったく新しいものに改良できた」と語った。現在は削除されているブログ記事で
Papandriopoulosはこう説明している。

"まずわれわれは高速な離散コサイン変換(DCT)のアルゴリズムを研究した。
次いでARMのNEON SIMD コ・プロセッサのアーキテクチャに最適化された
新しいアルゴリズムの開発に成功した。最終プロダクトは1万行の手動で最適化された
アセンブリー・コードと 2万行の低レベルCコードとなった。ちなみにSnappyCamの
アプリは5万行弱のObjective Cコードからなる。
JPEG圧縮は（上記の）DCTと ハフマン・ロスレス圧縮という2つの部分からなる。
われわれは素晴らしく高速なDCTの実装に成功したが、するとハフマン圧縮が
ボトルネックとなった。の の部分については、われわれはARMプロセッサの
アーキテクチャに最適化され、高度にチューンされたアセンブリー言語のプログラムを書いた。"

http://jp.techcrunch.com/2014/01/06/20140104snappylabs/

3行で

パパンドレウ

>>2
爆速連写カメラアプリを作った
なんでこんなものができるか？→手動で書いた1万行のアセンブラでバリバリ最適化したから
Appleが買収

おっぱいプルンプルン動画撮影が捗るな

1人でやってるのになんで「われわれ」？

天才かよ

>>2
手動でゴリゴリに最適化し高速で連続撮影できる写真アプリを作った会社を買収した
ねこだいすき
フリスキー

> 離散コサイン変換

なるほどわからん

ぬるぬるやな

夢があるな

頭おかしいな

プログラマの負担は増す一方だ

行列関数を手動アセンブリとか変態さんです

小堺さん一家離散

動画撮影はもともと出来るじゃん
毎秒30fの連続撮影できるのが凄いってのがわからんな

手動でコードを書いたって普通じゃないの？
自動で書いてくれるソフトもあるの？

X68000のJPEGEDやな

JPEGの展開が
2分→2秒くらい

iOSに標準搭載されるんですねわかります

>>17
手動で準マシン語(アセンブラ)で書くのか変態レベルのプログラマ
普通のプログラマは高級言語で書いてコンパイラに自動でマシン語にしてもらう

>>6
会社とか組織は三人称だから英文そのまま訳したんじゃね

>>16
動画撮影だとH.264の劣化画質だけど、
静止画撮影だとJPEGの高画質で行けるってこと。
ただしJPEGは普通にやると演算量が多くてキツイ
(Motion JPEGだとVGAが関山)

>>17
普通はC言語とかで書いてアセンブラを出力する。
素手でアセンブラ1万行書く奴は21世紀にはまずいない

つかSIMDに確実にベクタ演算させたり明示的にFMA使わせたりするには
その部分だけでもアセンブラで書くしかないからな

ファミコンのゲーム開発か何か？

アイディア思いついた上に力技で手入力するなんてド変態

だからx86でもCPUの拡張命令を使う部分だけはアセンブラで書く

コンパイラではできない職人技的処理を変態プログラマがやったってこと？

ユニーバサルメルカトル図法で最適化すれば技術者なら難しいことではないね

ベーマガでもたまにBASICのプログラムの中にマシン語入れてる人いたよね。

エンコソフトのx264も最新のCPUだと実行時間の半分はアセンブラで書かれてるコードを実行しているらしい
ソース分量比ではどれだけの比になるかは知らんが

>>6
論文とかそういうのは一人で書いても、全部we

マシン語を一万かいたでござる

あー、高速な離散コサイン変換(DCT)のアルゴリズムを研究した。
次いでARMのNEON SIMD コ・プロセッサのアーキテクチャに最適化された
新しいアルゴリズムの開発に成功した。最終プロダクトは1万行の手動で最適化された
アセンブリー・コードと 2万行の低レベルCコードとなった。ちなみにSnappyCamの
アプリは5万行弱のObjective Cコードからなる。
JPEG圧縮は（上記の）DCTと ハフマン・ロスレス圧縮という2つの部分からなる。
われわれは素晴らしく高速なDCTの実装に成功したが、するとハフマン圧縮が
ボトルネックとなった。の の部分については、われわれはARMプロセッサの
アーキテクチャに最適化され、高度にチューンされたアセンブリー言語のプログラムを書いたわけね、わかるわ。

しかも一人で作ってんだろ
頭が良くて技術があったとしてもよくモチベが保つな

一太郎Ver4が重いと言われた時期に、新松を管理工学研究所は
オールアセンブラで書いた。

おもしろそうだからアプリダウンロードしようと思ったら、買収に伴って削除されてるじゃねえか

>>34
アセンブラってのを使えば最適化ってのができるの？

>>22
高画質ってことか　ありがと

手動で書くのとコンパイラさんにこれ書いてってお願いするのは違うのかい？

ここら辺は全くわからん
少しでも困ったらいつも某システムズさんに電話してるし

ぱぱんどりおぽーろす？

結局ノイマン式計算機を使いこなすなら手動っすよ。
起こり得る場合の数数えて、それぞれにサイクル数かぞえてコードを書く。
…ってobjective Cかよ！

ARMのNEON SIMDって、これって他のスマホとかでも
応用が利く場合はありそう？
つーか閃いたってのがすごいなｗ

>>34
この手の人は思いついたこと出しきらないと休めないタイプだと思う

>>39
たとえばHaswellのAVX2なんかだと32bitの整数を8個同時に
1クロックで積と和の演算できるんだけど
そんなのコンパイラじゃ勝手にやってくれない

まさにプログラムするために生まれてきたような人だな

マシンと直接話せるなんてキチガイだろ…

つまり動画のエンコード方式もこれにすれば

あっ

あのー、iPhone6のCPUメーカー分かっちゃったんですけど・・・

>>37 >>39
Cで書いてアセンブラを出力すると4命令になるけど、
アセンブラで書けば1命令になったりする。

たとえば「足し算して255を超えたら255にする(飽和加算)」
とか、Cで書いたら4命令になるけど、アセンブラの飽和加算命令を
使ったら1命令で書ける。単純計算で4倍速

少なともSIMDのベクタ演算に関してはプログラマが
ベクタ演算するように組まない限りコンパイラはスカラ演算しかしてくんない

>>44
最近のCPUのμOPとかの分割とかスケジューリングは判らないから
何でもアセンブラにしたから高効率とは限らないだろうけど、この場合
のようなSIMD利用には有効だろうなあ。

でもDCTってPCの場合だと最底辺のビデオカード、ビデオ回路でも
支援機能が付いてると思う。

買おうかと思ったらもうDL出来なくなってんな。

今時のコンパイラの最適化でも
SIMDをガチで使い切ろう思ったらアセンブラしかないんだろ？

お、俺のZ1fもそれぐらい出来るし

>>53
そう
ライブラリも実は部分的にアセンブラで書かれてるとか
割とある話

OoOな最近のCPUのアセンブリ言語コードってどうやって手動最適化するんだろう

一方webプログラマはJavascriptですら直接使うのがめんどくさいと言って
簡易化ライブラリを介して中間言語的に使う方向に走った

メモリのI/Oは足りるん？

>>53
DSPメーカーはライブラリ用意してくれてるから
C++からそれ呼べばいい

10 PRINT"Papandriopoulos"
20 GOTO 10

良く分からんがお前らが言うにはここで逆にこいつをスカウトするのが白人様企業なんだろ？

>>49
なるほど
けそのアセンブリっていうので書くと難しいからcとかJAVAでみんな書いてるって捉え方でいい？

カメラの性能ってソフトの影響もあるのか

>>59
SIMDの楽な利用方法はSIMDを明示的につかうようにアセンブラで書かれてるライブラリをそのまま利用するってわけね

これ、撮影だけじゃなくてjpegの展開とかにも使えるんじゃね？
Appleがこれを画像処理の標準としたら、iPhone更に爆速になるでぇ。

天才じゃん

>>56
アウトオブオーダーなら、逆にCPUが適切に並べ替えて
くれるから手動最適化しなくてもいいんじゃない？
むしろインオーダーでスーパースカラなやつとか、
手で書くなら命令並び替え必須。間違ってたらごめん。

>>62
うん

>>65
>>18みたいなのか

これって4K以上の30fps動画をiPhoneで撮れるってこと？
すごすぎだろ

>>62
あとアセンブラで書かれたコードはそのCPUと命令互換性があるCPUでしか再利用できないコードになってしまう
だからアセンブラは最終手段的な感じになる

それにくらべてジャップときたら・・・

>>20
>>22

アセンブラとかよくわからんがとにかく変態だって事はわかった

やっぱり離散コサイン変換か。
そうだよ。
これからはそうだと思ったんだよ。

お前らの会話さっぱりわからんw
やれば便利なことはプログラマなら誰でも知ってるけど
凄い面倒くさいからやらなかったことをやった人、ってことか

https://itunes.apple.com/jp/app/snappycam-pro-fast-camera/id463688713?mt=8

発想自体は誰でも思いつくレベル
ユニバーサルメルカトル図法を応用しただけ

>>73
80年代だったら普通だったんだけとね。

コナミとかハドソンの人にやらせたらもっと速いのできるで

機械の声が聴こえる...

次は16進直接入力で

俺がやったらあんま早くならん上にバグだらけになる
天才だと思う

>>73
違う
「俺も思いついてたけど、実際やったヤツが居るとは・・・」
的な間接ホルホルすら許さないレベルの全く新しい技術を
理論から実装までたった1人でやり遂げた、という話

今どきアセンブリでカリッカリチューニングとかあるんだな
これが天才か・・・

プログラミングの技術だけじゃなくて、大学レベルの数学や物理の知識ないと実装できなさそうだな。
そうとう頭いいんだろうな。

わからん

新しいアルゴリズムって書いてあるから
そうそう思いつく様なもんじゃないんだろうな

Canonとかがこの人雇ったら凄いことになるんじゃね？１秒間に１おくまんまいとか

頑張ったプログラマ引き抜けばいい

>>53
イントリンシック関数使えばアセンブラ触らなくてもSIMDは明示的に使えるには使える

あー離散コサインね。はいはい
俺も思いついてたけどね。

せっかくベクトル演算命令とか用意してあるんだから、動画のエンコード・デコード支援
くらいでしか有効に活用されてないってのはもったいないよな

フルスクラッチで一万行
機械人間だろこいつ

DCTってまだ高速化出来る余地があったんだ…
というかCPUに最適化しただけ？

よくやるわ

手動の最適化は一度やってみたいな
理論から実装まで１年くらいかかってそう

カメラスレができる度にミラーレスはクソ！動画からの静止画切り出しが実用的に成るのは５０年先！と言ってた奴等の立場は

やっぱりお前らの生活は数学に支えられているんだな

マシン語で一万行って、処理自体はそこまで大きくないよな
一つ一つの命令が単純だから

ほんとすげーわ
こういうのをプログラマっていうんだよな

あほな日本人は技術者だけ引っこ抜けばいいとか言うけど会社ごと買うのが正解だな

すげえなぁ
ジャップログラマはそんな余裕なさそう

>>96
繰り返したりにたようなと頃は使い回すから書くのだるいと思うよ

>>99
土方とアーティストの違いか

変態ということはわかった

お前らみたいな暇を持て余した大先生のサクセスストーリーはこのルートが一番現実的だろ
さっさと爆速アプリ作れよ

時間かければできるけど儲からないだろこれ
割に合う最適化なら皆やってる

>離散コサイン変換に関してインスピレーションが閃いた。

かっこいい

>>104
自分のアプリだし実現したいことの先に高級言語による
処理の遅さがあれば部分的にアセンブラでコード書くのは普通だよ

仕事ならそれなりにお金貰わんとやってられんが

パチ業界で働けるな。

>>106
1万行は割に合わない
ハードが進化すりゃすべて無駄

NEONの仕樣が変わるたびに全部書き直しにならへんか

pc98時代は高速化したい部分だけasmで書いたよな
このくっそ重い中間フレーム層すっ飛ばして
スマホやタブレットの実力を見たい気はする

そこまでの情熱が凄いわ
俺ならちゃんとしたカメラ使おうと思うのにw

>John Papandriopoulosは電子工学の博士号を持ちSnappyCamを2年間開発してきた。
>iPhone上で撮影プロセスをスピードアップし、バッファーし、画像を圧縮するしくみを学習するうちに、事実上JPEG画像標準を再発明した。

2013年8月1日
http://jp.techcrunch.com/2013/08/01/20130731fastest-iphone-camera/

開発期間2年間だそうだ

良い商品・サービスを見つける → 買収して自社製品に組み込む

これがAppleの歴史なんだよな

プログラム知識ほぼないけど1万行書き終わったらまた1万行見直しするの？
でbagfixのためになんども1万行のプログラムとにらめっこするの？

今のlinuxとかで使ってるjpeg用のライブラリのlibjpeg??turboもインテルのCPUで最適に処理できるようコアなとこはアセンブリで書かれてる
今のはどうだか知らんが日本人も関わってた
これのすごいのはアセンブリじゃなくて新しいjpeg用のアルゴリズムなんじゃないの

>>113
GoogleもMSもfacebookもやってることだな
日本企業に大金出してベンチャー買収する度胸なんて無い

>>108
無駄ではないよ
軽量化されればそれはそれで性能が上がった環境でも
より軽いままだから

それに所詮はライブラリなので一度軽量化してしまえば
その最適化されたプロセッサやその系統が有効な間は
いつまでも使える

>>114
普通はアセンブリでもブロック化する

>>84
NEONというARMのSIMDレジスタを有効に使える
新しいアルゴリズムだから優秀には違いないが
>>80で言うところの「可能だとは思うけど実際に
やったヤツがいるとは」の凄い版が正しいような。

プログラムの世界は間接ホルホルなんて存在しなくて
実装したものの勝ちってところがあるから。

＞毎秒20コマから30コマの画像をフル解像度で撮影することができる。

フルHDの動画をバラしたら同じことできないの？
って思ったけどフル解像度か

日本でITドカタやってたらこんなスキル絶対付かないだろうなあ

ちゃんと読んだけど何一つ解らなかった

「離散コサイン変換に関してインスピレーションが閃いた」
言ってみたい

>>91
簡単にいうとそう
DCTのコードをSIMDに特化
圧縮パートはCPUに特化
記事からは上が高速化に貢献してそう

>>109
一般的な並列演算機能をフルに使いきる何らかの
並べ替えを思いついただけだろうからたぶん大丈夫

>>114
大雑把なパターンや繰り返しがあるから
大抵は難しい作業にならない

よくわからんがiPhone6のカメラ機能に期待していいのか？
まぁ使わないけど

>>122
工場のラインを整理して生産数を増やしました
みたいな

俺も似たようなアイディアはあったんだけどな
先、越されたわ

>>117
> その最適化されたプロセッサやその系統が有効な間は

スマホだぜ？組み込みだぜぇ〜？
CPUが変わったらアウト、そうでなくても仕様変更が激しい組み込み業界
アセンブリでの最適化は終わっとる

像面位相差技術もこなれてきたしそろそろ携帯でも積んでくる会社出るかもね
AF速度はセンサーの小さい方が有利
フルHDはカメラの画素数にすれば２００万画素程度でしかないがジャストピンかつ秒30コマ連写なら撮れた画は使い道ある

iOS7から追加されたバースト撮影は旧端末だとかなり無理してしょぼい
これが流用されればどんな端末でも搭載カメラの最高画質で連射機能が一般化するんじゃないかな

>>128
演算を高速化する次元の違うアーキテクチャが登場しない限り通用しそう
圧縮パートは難儀かもな

>>128
モバイルはARMで当面決まりだし
問題ないだろ

>>98
マイクロソフトがレア社買収したら中の人皆逃げたのは有名やで
今回は一人親方みたいな会社だから有用だけど

>>128
まあ木っ端企業ではなく、仕様そのものに影響力が持てるアップルが買ったわけだし

俺もそうだと思って開発しようと思ってたんだよ

>>132
x86搭載タブレットも徐々に増えてきてるけどなｗ
巷で話題のMeMO Padはx86のATOM搭載だｗ

>>133
MSが買収したら中の人皆逃げたんじゃなくて
重要な人達がいなくなったから任天堂から見放されちゃったんだろ

DCTみたいな枯れた技術に今更挑戦して新しいアルゴリズム
考え付くとか凄いわ

世に出てよかったね
当時としては頭二つは抜けてた画像処理ソフトがあったんだけど
中の人が電波で発展しなかった

>>138
アルゴリズムそのものは汎用になってるんじゃないかな？
新しいプロセッサを使いこなす構造には誰かがやらないと
たぶんできないだろうからねえ
結局プロセッサのパワーで汎用コードをぶん回すのが
割とよくある話だし

高級言語はゆとり

>>140
アセンブリで組んだ時点でアルゴリズムとCPU仕様がガッチリ結合しちゃってるわけだが…
CPU仕様とアルゴリズムが一致しないのであればそもそもアセンブリ言語で組む必要がない…

OK?

すげー技術者だな

>>22
マイクロプログラムって呼ばれてる極めて高速な応答性を
要求されているプロセッサで動作するコードは、全部特殊なアセンブラだよ
行数でコード規模を評価するのも全時代的でアレだが、余裕で1万行は超えるわ
DSPとかデジカメのCCDなど

カメラソフト作って自動コンパイルして仕上げると、どしてもトロいソフトになっちゃうから
コンパイルした後の形で最初から作ったよ1万行書いた、おかげで爆早いってこと？

高級言語をコンパイルするとそんなリソースの無駄使いが生じるの？

>>142
そんな貧乏臭い高速化はしてないと思う
しらんけど

こういうのって処理部分を並列化させたらだめなんかな
チップを２０枚ぐらい積んで１チップあたり毎秒３枚の処理なら秒間６０コマの撮影が可能になるとか

>>142
FPGAでいいじゃん
俺の考えた最強のスマホカメラ作ってくれよ

とりあえず簡単な圧縮で時間稼いでおいて
あとからJPEG化すればいいんじゃないかと思ったが
メモリの許す限りずっと30fpsで撮れるという事か。

>>145
うん

だから、最近はCPUを設計する時に
高級言語が吐き出しやすそうな命令を高速に処理できるように設計してる

>>147
電力。
反論できる？

2万行のアセンブリって
かなりの量じゃね？

>>144
マイクロプログラム方式って現存してたのか。

68000の乗算命令あたりが最後かと思ってたw

よく分からんが
前時代的なアナログ根性が最強だったって話か

この辺の最適化技術ってコアの部分でプロセッサの固有命令使ってたりするから
移植性に問題があったり、移植自体がそもそも不可能だったりするわ。
(例えば、固有命令をエミュレートするシステムコールみたいなのを実装すれば動作するが
パフォーマンスが出ない)

以前、プアな16bitプロセッサに特殊な短縮巡回符号で符号化されたストリームデータの
リアルタイムデコード処理なら書いたことあるが、論理bit shiftのキャリー演算を多用したので
他のデバイスに移植する際に苦労した経験がある。

昔なら余裕でパクってただろうな

フリーでプログラム受けてる人って単価とかどれぐらいなの？ピンキリとは思うけど参考に欲しい

>>157
10年以上前にフリーでやってた事あるけど
その頃は60〜80万貰ってた

ARMもコアによって命令体系がまるで違うよな。
Mシリーズなんてv7なのにARM命令自体が実装されてないし。

iPhoneはライブラリの絡みでコアは全部同じの使ってそうだけど。
この辺A9コアのカスタムチップかなぁ。そういう意味では移植性はしばらく保たれそう。
こういう数学的センスのあるプログラマっていうかギークの方には憧れます。

>>36
ちょっと待てばosに搭載されるんだろ？

次のiPhone6の目玉機能になってたりしてなｗ
動画撮影もiPhoneのカメラがあればこの通り、みたいな。

>>136
知らんのなら黙れ

圧縮が遅かったので新しいアルゴリズム作りましたってか
ニュートンかっつの

>>162
？

> モバイルはARMで当面決まりだし
↓
> x86搭載タブレットも徐々に増えてきてるけどなｗ

この会話何かおかしいか？

ここまで誰も簡潔に説明できた奴いないから誰かもっと簡単に説明しろ

きになってDLしようと思ったら削除されてた死ねよ

なんだかさっぱりわからんｗ
アセンブラだのコンパイラだのいわれてもオレには漫画しか思い浮かばんわ

大学のときアセンブラで数十行程度の基本演算コード書いたけど
理解し実際に動かすのに数時間とかかったわ

ハードウェア直接いじってるのか
そりゃ買収されるわ

毎秒2-30ってことは動画じゃん

>>161
100％なるでしょ
次のiPhoneで映画でも撮るんじゃないか？
すでに誰かがiPhoneだけで映画撮ってたような気もする

すげーなこれ

>>22
インラインアセンブラとかよく使うよ
暗号ライブラリのモジュールなんかスクラッチでアセンブラ書いたし

今でもアセンブラは現役だ

>>168
誰でも最初はそんなもんだよ
で、経験積んでくると命令サイクル数えながらループのやり方変えるようになる

>>4
違くね？

爆速連写カメラアプリ→5万行弱のObjective Cコード
研究したアルゴリズム→1万行の手動で最適化されたアセンブリー・コードと 2万行の低レベルCコード
でしょ

iPhoneアプリ作ったことないから詳しくないけど
ARMを直接叩くようなアプリが
Appストアの審査を通るとは考えられない
もし通るならAndroidなんてレベルじゃないくらいやばいアプリが蔓延してるはず
つうかそもそもARM叩く権限なんかないはず

この人はアプリを売り込んだんじゃなくて
研究したアルゴリズムをプレゼンしたんじゃない？
だから買収に至った

簡易なデータベース作るレベルの自分には何が何だか良く分からない世界だな

>>174
Appストアの審査ってソースコード提出の義務あるの？

実際に現物を売ってたのになぜそういう勘違いができるのかさっぱりわからん

0と1だけのキーボードを持ってて、
チンコを擦るかの如く高速でマシン語を打ち込むケンモメンからしたら大したことないよな。

ただのMotion JPEGじゃないか
デジカメに搭載されてるカスタムチップなら
もっと高速に処理しているんじゃないのか

>>176
俺に聞くなよｗ
作ったことねえ言ってるだろ

軽く調べた感じだとMono使ったC#くらいは通るみたいだけど
どうなんだろね

てか俺が言ってるのはソースコード云々以前に権限ねえだろってことだから

前無料で落としたわ
かなり使える

スマホを持ってる奴はロックジョイというアプリをインストールしてみないか？

今なら登録の際、紹介コードに【モナーク】と入れるだけで1000ポイントゲットできる。

ポイントはアマゾンギフト券1000円分やiTunesポイントに交換できる

期間限定だから今がチャンスだ。

iPhone→ https://itunes.apple.com/jp/app/rokkujoi-o-denapurezentokyanpenga/i...
Android→ https://play.google.com/store/apps/details?id=com.buzzvil.lockjoy

MotionJPEGだってコーデックによって全然速度違う
昔メアド登録で使えたコーデックはそこらのmjpegコーデックの5倍以上早かった

>>174
こんな記事もあるし、iPhoneのObjective Cでインラインアセンブラ使えるんだろ。
むしろ、Androidみたいに審査自動じゃないから出来るんじゃないの。
いずれにせよマーケットで売られてるアプリがObjective Cうんこっつって高速撮影出来てるのは事実だから、ハード叩いてると予想するのが普通。

iPhoneでインラインアセンブラを使う(プログラム編[1]) - 強火で進め
http://d.hatena.ne.jp/nakamura001/20090114/1231936551

>>180
ARMはCPUだから権限もへったくれもない
CPU以外の外部にアクセスしようとすると権限で守られてるけど
GPUを利用しようって訳じゃなくて、CPUのSIMD命令でゴリゴリ書いたって感じなので
別に関係無いよ

ID:pF0u+6JbP　この人は嘘つきなの？

>>185
それ組込みの話でしょ
Appストアのアプリはもっと上位の層からしか動かないんじゃないの？

そんな低レベル層を叩けるなら
さっきから言ってる通りやばいアプリが蔓延してるはず

一方ロシアはハードウェアでインプリメントした

>>176
ある。
だからAndroidみたいにVirusやKey loggerだらけにならない。

>>187
事前審査方式みたいだから大丈夫なんだろ。

App Store - Wikipedia
https://ja.wikipedia.org/wiki/App_Store

アップル、意外と知らないiPhoneにウイルス対策ソフトがない理由とは？（追記）｜わかぽんたの気まぐれ日誌
http://ameblo.jp/plus2222/entry-11519606040.html


>>188
最近ロシア製でハードウェア方面で生きてる部分ってあるか？

>>187
BitmapデータをJpegに変換するために
CPU命令使ってメモリアクセスするだけだから権限なんて要らないはず

>>189
ソースコード提出しなきゃいけないのか
そうすると不正アクセスしてない証明が面倒になるかもなぁ

>>185
ARMコアにはHandlerとThreadみたいに権限が分かれていて、
一部の命令には特権がないと実行できない制限がかかっている。
それを利用してOSを作ることで、プロセッサ本体の動作を吹っ飛ばすみたいな
危険な命令を実行するプログラムは動作しません。

ただiOS上ではパフォーマンス重視の危険なアプリケーションも申請できるし
審査が通ればこうやってApple Storeに並ぶんだよね。
凄すぎて買収されちゃったけどｗ

>>187
Androidだって普通にアセンブラで掛けるけどroot無しで何でも好き勝手出来るわけじゃないだろ
どんな仕組みで動いてるのか知らんが、スレッドにアクセス権とかあって
別にアセンブラで書いたからって何でも出来るわけじゃないんじゃない

>>192
詳しい説明ありがとう
申請自体はできるのね

>>193
だからさっきからそう言ってるじゃない

>>190
一方ロシアは鉛筆を使ったですやん

自分の底の浅さに嫌気がさす、この世界には天才が多い、死にたい

＞「離散コサイン変換に関してインスピレーションが閃いた。
＞それによってJPG画像フォーマットを事実上まったく新しいものに改良できた

何言ってるかさっぱしわからんけど、すごそう

数学やってない奴がプログラムいじってもアレだなと改めて思った

>>196
ほんとな
俺は勉強する時間なくて常にに焦燥感を感じるようになった
技術について調べれば調べるほど新しい発見があるんだよな
それであれもこれも検証しなきゃってなって時間がなくなる

つまり、アセンブラで書く力量があれば今のスペックでもとんでもないパフォーマンス
のアプリをストアに出せるってことか？

1万行言うてもCとかの1万じゃないしな
一行は　あに入れるいに出すだけの
の命令文だぞ

数学できないプログラマがクズなのは事実だけど、世の中のソフトウェア開発の
工数比で99%は虫けらでもコーディング出来る様な内容なので生きていて問題ない。

汎用性を犠牲にして高速化はあるあるなんだけどね

iOSに、標準搭載されたら電子書籍アプリが完全に実本を超えた使い勝手になりそう

>>201
アニメーターみたいだな
1%の才能を99%の手足が支えるという所が

>>199
別にアセンブラ云々って話よりもDCTをプロセッサに最適化した
(新しい？)アルゴリズムで実装したって所がポイントなんだよ。
誰でもアセンブラで書けば早くなる訳じゃないし、一般的にはコンパイラの最適化に
対して労力比で勝てない。

日本のソフトウェアが海外IT企業の足下にも及ばないゴミってことだけわかった

>>22
JPEGって劣化じゃないのか
その技術使ってJPEG30連射動画作ったら、従来の動画映像よりもかなり綺麗になるってこと？

うまいことやればもの凄く低価格で4K60FPSのRAWシネカムが作れるって事?

これはJPEGの圧縮速度を飛躍的に早めたという話なのでRAWは関係ないと思う

>>121
ITドカタに技術が無いとは言わないが、.NETベースの自社フレームワーク
とVB、C#でのコーディング、EXCELとDBないしERPの連携あたりじゃ無理だろうな。
あれはあれで、細かく定義されてるけど面白みが無い。

1万行のアセンブラコードと言ってもDCTベースのエンコード・デコード中心だから
10-20程度の関数に分かれるんだろうから、一つのモジュールが数千行ってことは
無いんじゃないの。やる気があって少しずつでも進めれば不可能でもないはず。

と思いたい。

よくわかんねーからガンダムで例えてくれ

>>167
通常プログラムと言われてるものは
マシンに命令するための命令コードを
人間がわかりやすい文法で書いて
それコンパイラと呼ばれるソフトでマシン語に変換する
これをいわゆる高級言語と呼びます
CだとかPHPだとかPerlだとか
言語って簡単に言えばコンパイラを指してる
アセンブラってのは簡単に言えばマシンに直接命令できるコードのこと
高級言語のメリットはわかりやすいこと（ただし遅い）
アセンブラのメリットは処理が早いこと（ただしくっそ難解）

まー、普通の人にとってコンパイルといったらぷよぷよだもんな

アセンブラといえばアセンブラ0Xだしな

>>211
ビームライフルを職人が手作業で組み立てて
ザクのジェネレーター出力でも連射できるようにしたら
ジオニック社に買収された

アセンブラ１万行とか凄くてわろす

そんな技術よりも、
いい加減タイマーくらいつけろよボケ

10秒もどれるができるようになる

こうなるとカメラモジュールの転送速度が問題になってくるんだよね…

結構いい加減な情報が多い…

１人で１つのアプリのために数万行はマジキチｗ

>>16
数年前に携帯のデジカメ組み込みやったことあるけどフルHDのJPEGエンコードに百ミリはかかってたわ
VGAでも秒30枚は撮影できなかった記憶がある
ハードの性能差差し引いてもフルHDで秒30は神だと思う

HPCの分野でも最後にキチチューンかます部分はアセンブラで手動最適化するらしいが、
こんだけの行数やるやつは相当なキチ

>>222
フルHDじゃなくてフル解像度

>>222
Athlon500MHzでもVGA30fpsのmjpegでアナログキャプチャ出来てたけど
ガラケーはスマホと違って昔のPCに以下の低スペなの？

>>49
最近のコンパイラは、常人の予想をはるかに超える最適化をはじめて、
下手にアセンブラで書くより効率的になったりするけどね

>>224
書いてから気づいたけどもう想像もできない世界だわ
8Mピクセルだったけど一枚の撮影に一秒かかってたし

>>225
カメラモジュールからの引き抜きってのもあるかも
クロックも800MHzとかだったようなきがする

そもそも、DCTみたいなよく使われる処理は、
CPUに専用命令を実装して高速に処理できるようにすべき

>>113
Appleは、脱獄したハッカー連中が便利な機能を実装したら、
それと同様な機能をパクって実装とかしてるよな

今でもレスポンス求められる機器はアセンブリで書くよな

>>227
iPhone5のカメラも8Mだから単純計算で30倍だな

>>99
ジャップ土方プログラマもやるんだぜ
上から無茶ぶりな性能要求おりてくるから泣く泣くなｗ

この技術アップル製品より普通のデジカメに乗せてくれよ

>>233
普通のデジカメはCPUでソフトエンコなんてしないんじゃないのか

>>233
ハードゥエアエンコーダが乗ってるから関係ない
そもそも普通のデジカメはシャッターとか他の要素がボトルネックになって連写できない

俺ならiPhone捨ててGopro買う

正直、ハッカーとか優秀なプログラマーって形容していいのはこのレベルのプログラマーだと思うわ
スクリプト言語でしようもないウェブサイトとかファミコンレベルのソーシャルゲー作ってるプログラマーとは次元が違う

むしろこんなレベルの人間が高々1ドルでアプリを売ってた事が一番の驚き

下手に高い値段で売って埋もれるよりは安い値段で知名度上げた方がという戦略かも
実際にAppleがアプリではなく会社買ってくれたし

プログラムの話って面白いなあ
少し詳しく知ってたらもっとおもしろいんだろうなあ

>>239
実際そのとおりだと思う
blogでも技術宣伝気味にアピールして、買収の話始まった途端消してたし

何言ってんだよばかじゃねーの

アセンブラの１万行ってすごいのかすごくないのかよくわからんな

section .data ;data section declaration
msg db 'Hello World!',0AH
len equ $-msg ;string length

section .text ;code section declaration
global _start ;entry point (start of execution)
_start: mov edx,len ;string length
mov ecx,msg ;string start
mov ebx,1 ;file handle: stdout
mov eax,4 ;sys_write
int 80h ;kernel system call

mov ebx,0 ;return value
mov eax,1 ;sys_exit
int 80h ;kernel system call


こういうのだったよな

>>176
ないよ

>>233
アップルへのパテントとハードウェア代加算で
値段が+10万になるが大丈夫か

>>211
ハイパー化したZガンダムの量産化

工夫してDCT速くしたけど後段のハフマン符号化の
処理時間が目立ってきたわ (´・ω・｀)…

ようしお父さんアセンブラで書き直しちゃうぞｗｗｗ
という流れか。
可変bit長のデータ処理ってcで書いてると非効率で気分悪いもんな

webアプリも低級言語で書けば爆速なんだがやる奴があまりいない

確か2chもどきの掲示板なんかはCGIじゃなく単体で動く奴がベクターに沢山あったはず

このカメラアプリが買えないんだが…

>>248
そんな事はない
asm.jsとかあるし

カリカリちゅーんプログラマすげえな

そういえば、LLVM/clang 3.4がリリースされましたよと

こういう作業やってく奴はただのアスペかキチガイかよ
天才だーって言って煽ててもっと仕事やらせるのは良いかもしれないけど
普通の人間が目指そうとしちゃいけない世界です

>>211
テムレイがジャンク屋で拾ったパーツでf91を作った

離散コサイン変換に関してインスピレーションが閃いた。


一度は言ってみたいセリフ
全く意味はわからんけど

天才じゃん

アップル買収しすぎ

>>228
ハードウェアで処理(高コスト)
↓
アルゴリズムの研究が進んでソフトウェア実装の方が高速で低コスト

なんて話もある世界だから困る。
これWORDのLSB→MSB bit反転の話な。

>>243
たぶんこんな感じだと思うお

push lr
str r0,[r1]
lbs r0,4
bxor r0.1
bxor r0,2
bxor r0.3
lbs r0,4
bxor r0.1
bxor r0,2
bxor r0.3
lbs r0,4
bxor r0.1
bxor r0,2
bxor r0.3
lbs r0,4
bxor r0.1
bxor r0,2
bxor r0.3
pop lr
bx lr

CASIOが得意そうな分野だよな　これ

できる奴はアプリで稼ぐ
ますますIT業界はゴミ人材しかいなくなる

DCTの新しいアルゴ思いつくとか幸せだっただろな

>>29
それ俺だw

>>35
今考えればレベル的には今回のよりそっちの方がすごいな。
開発環境も昔のほうがプアだったし。

所詮コンパイラの吐いたコードを手動最適化するのと、一からアセンブリ言語でプログラムするのではレベルが違う。

>>48
とこが作ってもARMアーキテクチャだから結局同じだって。

>>72
20年前から…

>>114
普通は気が遠くなる程一万行を眺める事になる。

>>179
電池節約の為にデジカメのはそこまで高速化してないと思う。
逆に言えば、今回の買収したのも結局長時間撮影すると過熱して使い物にならない可能性も無いとはいえん。

>>243
わー、386なコードだw

>>259
ARMか？

>>261
IT業界がごみになってもITの発展は促進される

秒３０コマ撮影どころか６０コマ撮影できる廉価カメラもあるが携帯でこれができるのは素晴らしい
ペリアの２秒６１コマはフルHDだっけか
秒１５コマに落としていいから像面位相差積んでAF追従してくれれば夢が広がる

自分で揺らすんじゃないんだ・・・・

>>271
>>1 はフル解像度での話だよ。
そんな廉価カメラ聞いたことないし
そもそもSDじゃ書き込みが追いつかない

>>273
ペリアはフルHDなのにこっちはフル解像度だからすごいと感心したんだが
ニコン1は第一世代からAF追従じゃなきゃ秒60コマ撮影可能でレンズキットも２万円台で買えたから廉価カメラだが
アスペは人にケチつける前に自分の読解力と知識見なおせ

>秒３０コマ
>ペリア
あたりの記述に低学歴オッサン臭が漂う

>>274
あれはごく少数枚数だけとりあえず撮っといて
のんびり圧縮しながら書き込んでるから比較にならないじゃん。
そんなのなら俺でも書けるわ。

20枚、60fpsだと0.3秒とかしか撮れないんだろ？

大昔のアセンブラは65535行超えたら0行から始まるんだよなｗ
仕事での制御コードなら1製品3万行ぐらいは書いてたはず、
ソースリストではその15倍ぐらいに膨れたけど。

同一ハードで仕様が決まってるiPhoneとかでしか今じゃこんなことはできんな

アセンブラでは、変数を入れてる番地で直接いじるけど
それがCのポインタってこと？

アセンブラもCも知らんだろｗ

>>34
そーゆーのが楽しい人なんだろうよ

どうせgo toだらけなんだろ

保守しようとしたら死んじゃう