【IT】Swiftがトップ10入り、Pythonは3位から4位へ--10月TIOBEの人気言語ランキング
■ このスレッドは過去ログ倉庫に格納されています
TIOBEの人気プログラミング言語インデックスの最新版で、iOSアプリの開発に使われるAppleのプログラミング言語Swiftが10位にランクインした。一方で、Pythonは上位3言語から外れている。
PythonがTIOBEのランキングでトップ3に入ったのは9月のことだ。Java、Cに続いて3位となったが、10月のランキングではC++に越されて4位と順位を下げた。それでも前年の10月は5位だったことを考えると、Pythonの人気は上昇している。
TIOBEはGoogle、Bing、Wikipediaなど複数の検索ソースからの情報をもとに、どの言語が最も人気かを決める。
同じくプログラミング言語の人気度を測定するPYPL PopularitY of Programming Language Indexでも、Pythonの人気の高さは実証されている。10月のランキングで、Pythonは最も人気のある言語となった。PYPL PopularitYでは、Google Trendsのデータをもとに順位を決めている。
TIOBEとPYPL PopularitYはともに、プログラマーがどの言語に時間を投資するのかの決定を支援することを目的としている。
TIOBEの上位10言語は、Java、C、C++、Pythonに続き、Visual Basic .NET、C#、PHP、JavaScript、SQL、そしてSwiftである。PYPL PopularitYの順位は、Pythonを筆頭に、Java、JavaScript、C#、PHP、C/C++、R、Objective-C、Swift、Matlabと続いている。
TIOBEによると、ここ数カ月、10位の座は入れ替わりが激しいという。RubyやPerlが候補の常連だったこともあるが、このところはSwift、GoogleのGo、統計解析で用いられるMicrosoftのRが多いという。
一方で、「Swiftは、iOS向けのモバイルアプリ開発で用いられるプログラミング言語としては、間違いなくナンバー1だ。しかし、SwiftはiOSアプリの開発だけに対応し、Android向けではないため、開発者は『一度書けばどこでもディプロイできる』フレームワークに移行しつつある」とTIOBEは述べている。
TIOBEは合わせて、この1年の平均順位をベースとしたプログラミング言語の長期的な順位も公開している。ここでの上位5言語は、Java、C、C++、Python、C#であった（TIOBEは、SQLがチューリング完全言語とみなされるとして、2018年2月からランキングの対象に含めるようになったため、2017年のデータはない）。
https://japan.zdnet.com/storage/2018/10/15/88bf0aadcbc3b564551596eaebdc98a7/tiobeoct2018languagerankings.jpg
https://japan.zdnet.com/article/35126979/ 良く調べられる言語を人気だと定義しただけなので
良く使われている言語ではない 3位から4位になったけど、それでもPythonやっとけって記事じゃん Pythonは過大評価だよ
DB扱う業務システム作るならJavaの方が優れてる >>7
PythonがPascalの親戚だから我慢しろ Java はサポート有料化で一位なんてオラクルは笑いが止まらんだろ ぶっちゃけ 個人的にrubyばっか使ってる・・・。
もう慣れなだけ・・・ 詳しい人教えてください
Javaとc#の2択になったときに
C#選択するメリットってなにかありますか？ >>18
Javaは事実上サーブレットの道しかないが、
C#はUnityというプロから素人まで使ってるゲームツクールのすごい版みたいなのを扱える Javaはもう終わるよ
あんなもん好んで使うのはドカタだけ それでもfortranという生きる化石を使い続ける 人気じゃなくて、実際のコード量で比較した結果を知りたいな iphoneとandroidでネイティブ別で大変なのに
ここにmsのスマートデバイスが加わってきてたら地獄だったな Javaはリリース体制変えてこれから進化のスピードが上がるからね
ついでにライセンス体系も変えたからそこばかり注目浴びてるけど、無料のJDKは普通にあるし先進的機能をいち早く取り入れられるし、以前より状況は良くなってるんだよ >>32
VisualStudioを手放せないPGの方がよっぽど地雷 VB.NETがC#より上ってあり得んだろマジで
全てにおいてC#のが上だろ >>14
ちょっとしたバッチ処理を書くときに便利だから高給perl的に使ってるが、しっかりしたプログラム書くときは静的型付けの方が俺は好きだわ >>11
てか、javaで出来ることが多すぎて、python使わないと出来ないのが限定的なのかな。 >>37
ところがどっこい
フレームワークの選択次第で全く違う
フレームワークのために、言語が決まってしまうと言っても過言ではない >>1
＞統計解析で用いられるMicrosoftのRが多いという。
R言語はMSが作ってたのか、勉強になる記事だなあ > 人気プログラミング言語
「人気」ってなんだ？「C」が人気２位って時点でおかしいw
> Google、Bing、Wikipediaなど複数の検索ソースからの情報をもとに、どの言語が最も人気かを決める。
これ、習得しにくい言語ランキングってことじゃない？ >>40
俺の場合、python使う理由の8割くらいがNumPyだわ
Javaはmathライブラリで行列クラスを規格に含めちゃえばいいのにと思う
Javaで行列ライブラリを自作して、実際の演算部分をJNA使ってIntel Math Carnel ライブラリでAVX命令使うように最適化して…とやったことあるけど、
標準ライブラリに組み込まれていれば最初からこのくらいの最適化はされるだろうになあ numpy遅すぎね？
電卓代りにするなら便利だけど サーバ、ブラウザ、（クライアント）アプリで使えるJavaScriptに頑張って欲しいところだけど、
非同期ってのがちょっと慣れないなあ。 >>18
言語の力
良くも悪くもC#はえんたーぷらいず市場から脱落した。
その代わり言語の設計が自由になった。
.net coreがそうだしvar,async,linq,lambda,dynamic等がそうだ。
また8.0では全てのObjectをnot null化する大胆な計画を進めている。
お前が付いて行けるならC#に行け
さもなければJavaでいい。 >>43
開発してんのはR Development Core Team
MS(と言うか買収したRevolution analyticsか?)がやってるのはマルチスレッド対応への拡張 >>36
絹ごし豆腐と木綿豆腐とどっちが上かって言ってるようなもの。
お前みたいな奴がいるから、いつまでたっても.NETはバカにされるんだ。 >>18
その二択は簡単明瞭。
WindowsサーバならC#、LinuxサーバならJavaにほぼ自動的に決まる。 >>18
Microsoftにロックインされるメリットがあるのは確かだ 調べないでも直感的に書ける言語→不人気
いちいち調べないと書けない言語→人気 >>11
Pythonで業務システムなんてつくらんし
それが作れないから劣ってるってのが短絡的 Golangは糞仕様言語だなぁと思ったが
これはこれで良い感じだ
腕力自慢のIT土方の俺には向いてるかもｗ やっぱＪａｖａはプロ向きだな。
巨大な高層建築物などはこれ。
Ｃ＃は、素人でもとにかく手っ取り早く
動くものを作り上げたい向きでしょ。
でも、先端技術をどんどん取り込んで
進化してるんで、今後も大いに期待できる。 作るものがまずあって実現のために後から言語が付いてくる
言語から入るやつは間違いなくキモ童貞 >>58
十徳ナイフ化するモダン言語に対して三徳ナイフを貫くのがGoって感覚だわ >>60
作りたいものと開発環境て
同時に考えない？
それは俺が素人童貞だからなのか？ Javaが最高だと思ってる人は
あんまり他の言語を勉強してなさそうね >>46
numpyは速いよ
遅いのはnumpyの処理結果を受け取ってなんかしてるpython素の部分 ド素人だけどiPhoneアプリ作りたいんだけど、Swiftっての勉強すればいいの？ >>66
単体処理はほとんどCに丸投げだから速いんだが、式組み合わせるといちいち計算して結果書き出すからアホみたいに遅くなる
einsum使える所は使った方が断然速い
expression template的なことしないんかね >> 67
向こう５年はObjective-C(C)も必要。 これのせいで海外送金について調べても、検索結果が関係ない情報だらけになって困る。 波カッコが嫌なんだよ。あれ見たらイライラするんだよ。Pythonは丸かっこしかないからいい >>44
C++ならまだしもCは習得するだけならシンプルで簡単な言語だろ >>72
F#もいいぞ
他言語に強み全部パクられて出涸らし感あるけどな >>65
> Javaが最高だと思ってる人は
仕事だから使っているだけで、普段はプログラミングに関わらず
生活している人がほとんどだろう。 >>18
C#よりもJavaエンジニア(多くはJavaしか出来ない)の方が圧倒的に多いから人は集め易いぜ！ >>81
買い叩かれるレッドオーシャン、だけどブラック！(w VB.NETやJava、PHPの様な日本だとSIerがよく使う言語は
日本だと馬鹿にされがちだよね
でも大抵そういう連中はRuby on railsの馬鹿の一つ覚え >>11
企業が昔から馴染みのある言語を使い続けてるだけで、
webシステムなんかはそのうちpythonやrubyが主流になると思うんだけどなぁ。 >>84
実際VB.NETひとつ取っても、2013以降は言語仕様自体はまとも
開発者のオツムがVB6時代、下手するとVB4で止まってるという問題がある
それに加えて、上流がプログラミング書けない別働チームだったりすると最悪なやつが出来上がる
要件定義だけなら許せるけど、プログラミング書けない奴が設計までやると糞オブ糞になる vbはないわ…
C#erだけどscalaかgoやりたい これは従来のランキングと様相が大分違うね。集計方法が異なるのかな？ >>86
だって、.NETになったらVBのメリット無くなるやんw >>54
C++で作ると、完成すれば、競合製品との競走上、簡単に優位に立てる事が多い。
多少、書くのに手間かかることがあるが。 .NET開発は、ネットのサンプルが、C#ばかりになって、vb.netは無くなってきたし、
あきらめて、VBからC#に移行したわ。やってみたら、スムーズに移行できた。
確かに、タイプの量は、C#の方が少ないから、こっちの方が楽かもね。 ITの人材不足が深刻だって煽りまくってプログラミング教室が流行ってるけど
そこがこぞってRails推してるから素人はRailsさえ覚えれば自分もエンジニアになれるんだ！
って思って教室に高い学費払って安月給のスタートアップに入社して1～2年で路頭に迷う >>91
そもそも.netやJAVAはすべてのOS機能をサポートしてないし。
好みに関わらずC/C++を使わないといけない場面は多々あるかと >>94
特にC#は、C++を使う場面が多くなって、結局、最初からC++で書いた方が
すっきりすることが有ると聞いたことがある。 >>95
要件的にガッツリ低層レイヤへの直接アクセスが求められるシステムとか、RTOSみたいにナノ秒単位での制御がいるとかならそうだろうが、そういうシステムでVM系言語を利用すること自体、選択ミスな気がする >>97
前調べたけど、リアルタイムLinuxのリアルタイム性能があんま高くなかったというのと、
リアルタイムってのが処理開始までの時間が短いというのが定義だとすると
マルチコアってコア空いていたら勝手にリアルタイム性能高くなるから
本当にリアルタイムOSって必要なんか?とおもったんだがどうなんだろうか？
あと、Rustくらいになるとガベコレ切れるだろうし、LLVMが動く範囲ならC++代替可能なんだろうなと >>97
「そういうシステム」でありながら、かつリッチなUIも持たないといけない場合ってどうすりゃいいの？
Qtとか使うしかないの？あれ嫌いなんだけど >>71
どっちがええの？
Swiftのほうが簡単？ >>101
iOS作るのだったら単純にswiftのほうがいい。
C#だとXamarineってのを使うから、iOSだけじゃなくてWindowsアプリ、Android、Macデスクトップまで作れてしまうけど
ライブラリがラッパーでかぶせてあるから少し難易度が高い
あと、Unityでかなり本格的なゲームアプリもC#だと作れる。
ただ、初学であって特に他の言語経験がないのならswiftでいいと思う。
そこで学んだ経験はC#に移行しても生かせると思う C/C++がどんなに早いとしても、
webプログラムをC/C++で開発する仕事は聞かないなあ。
よっぽど効率悪いんだろうな。 >>99
自前でグラフィックライブラリとか、ウィンドウライブラリとか、作れないレベルの
雑魚なら、どんな言語をやっても同じだろう。 >>106
Webアプリの場合、ネットとDBが律速になるから
Webアプリ自体を速くしても大して意味が無いんだな >>107
＞自前でグラフィックライブラリとか、ウィンドウライブラリとか、
ゼロから自作？100パー無理ですわ
そもそも>>97ってレベル高いというか、ガチのIT専門開発だから自分とは別世界でした
自分は物理シミュレーション屋で、C/C++、Fortran、Python、R等で開発する程度だけど
そんなレベルなのにGUIがウンヌンとか言われて対応しなきゃいけないのが地味にきつい >>103
>>104
ありがとう
とりあえずSwiftから始めてみるかな～ >>99
レイヤー分ければええんちゃう？
低層C、中層Node+Express、表層Node+Reactとか
低層と中層はソケットとかで繋いでさ、表層はガッツリWebとか、デスクトップ風がお望みならElectronみたいなハイブリッドとかでいいんじゃね >>112
秀丸マクロだって言語といえば言語なんだから問題ない VB.NETに何があったらこんなランキングになるの？ >>79
elixerいいよな
でもパンピーにはオーバースペック >>115
VB.NETの検索がたくさん行われたらこんなランキングになる SQL？
俺の知らない間にプログラム言語に進化してたの？ >>1
Netflixは自前で配信システム（CDN）をISPコロケーションに構築しており、C言語とアセンブリ言語をソフトウェア実装に使っている
Senior Software Engineer - Kernel Developer
https://jobs.netflix.com/jobs/867538
Required Skills
Ability to work independently and collaboratively in all areas of the software development lifecycle
from requirements gathering to operations and maintenance
Ability to read and write code using the C programming language
Ability to work on large-scale software systems
Understanding of the way operating system schedulers work
Understanding of the way kernel virtual-memory systems work
Understanding of the way non-uniform memory access (NUMA) impacts the design of kernel subsystems
Ability to design and implement code that maximizes throughput within the constraints of PCI bandwidth, memory bandwidth, and CPU power
Understanding of 64-bit x86 architecture
Understand the interactions of the various hardware and software components of a modern computing system
and the tradeoffs that are inherent in system design decisions
Bonus Skills
Experience with FreeBSD
Experience with open-source software development
Ability to read and write x86 assembly code
AWSはクリックをする前のウェブサイトアクセスの段階までに過ぎず、ストリーミングはこのCDNが行う
誤解するものが多いがAWSはフロント部分に限られ、他は内製したうえで各国のISPにコロケーションから配信を行っている
abemaTVはこの点を致命的に誤解しており、AWSで赤字を垂れ流しているようなので頭が悪そうな連中のする失敗の典型と言える
バックエンドはC言語で実装しAWSとは無関係ということだ
Senior Software Engineer - Video Systems
https://jobs.netflix.com/jobs/867934
5+ years experience in multimedia software development, with excellent debugging and problem solving skills.
BS in Computer Science/Electrical Engineering or equivalent. MS or PhD a plus.
Expert in C++ or Java and object-oriented programming.
Working experience with video systems and/or streaming specifications, such as ISO/IEC 13818-1
(MPEG Transport and Program Streams), ISO/IEC 14496-12 (ISO base media file format),
Dynamic Adaptive Streaming over HTTP (MPEG-DASH), or Common Media Application Format (CMAF).
Solid understanding of video compression and processing, including coding standards such as H.264/AVC, HEVC, VP9 and AV1. goはエラーハンドリングが特殊でツラいから特殊用途向けで終わるんじゃない >>115
VB6から.NETへのリプレース案件多いって聞いたよ
C#に置き換えるより、ほぼほぼ糞コードを移行してそのまま動くから
プロジェクトにアサインされた連中が検索しまくってるのかもねｗ
>>118
SQLって書かれると？だけどストアドなら俺はプログラムだと思う
PL/SQLのバッチとか昔よく書いたなぁ >>51
便利な機能の追加は常にC#が先だし
UnityやXamarinはC#オンリー
それにVB.NETは色々と冗長で見にくいし
VB6上がりのクソコードが多いし最悪だ
両方やれるけどC#よりVB.NETの方が優れてるなんて言う奴がいるとしたら
それは無知か皮肉かどっちかだよ
そのうちC#だけ残して消える運命にあるんじゃねーの？ >>119
このレベルだと確かに数千万の給料出さないと来ないだろうなぁ…
普通のPGでじゃないや >>124
最近MSはC#放り投げてTypeScriptにかまけてる
.NET悪くはないんだが、そろそろ潮時かね >>126
放り投げてる？？
Xamarin買収してスマホをC#で開発できるようにするのに力入れてるのに >>119
Netflixはコンテンツもだが、システムもしっかりしてるな。 >>129
まあ、でも全部Cとアセンブラで実装しているってこともなさそうだけどな
世界が注目するAWS先進ユーザー、Netflixのすごさ
https://tech.nikkeibp.co.jp/it/atcl/column/17/122800596/010500001/?P=2
マイクロサービスの実践例は日本企業でもあるが、Netflixは規模がケタ違いだ。
Netflixのシニアソフトウエアエンジニアでクラウドネットワークエンジニアリングの
ジョン・ベネット氏によれば、2017年の時点で「何千ものマイクロサービスがある」。
re:Invent 2014のセッションでは「500以上のマイクロサービスがある」との説明があったので、規模を拡大させている。 >>119
CDNってことはバックエンドってよりはフロントのフロントのキャッシュサーバーな気がするが…
Kernel Developerって書いているから本当のカーネル以外をどこまで触るかわからんし >>119
なんでも自作とか
化石過ぎる
世界で最大の配信サービス会社は
akamai >>131
フロントのキャッシュではない
https://www.computerworlduk.com/cloud-computing/how-netflix-moved-cloud-become-global-internet-tv-network-3683479/
Content delivery
The cloud is only one part of the Netflix user experience. Everything that happens before they hit play takes place in AWS,
but the video content that follows comes from a separate system: Netflix OpenConnect, the company's proprietary content
delivery network (CDN). The OpenConnect appliances store the video content and deliver it to client devices.
CDNs are designed to deliver internet-based content to viewers by bringing it closer to where they're watching. Netflix
originally outsourced streaming video delivery to third-party CDN suppliers, but as the company grew, these vendors
struggled to support the traffic. Netflix needed more control over the service and user experience.
The company decided to design a CDN tailored to its needs.
It now installs OpenConnect appliances that store and deliver content inside local Internet Service Provider (ISP) data centres,
which isolates the Netflix service from the wider internet. Popularity algorithms and storage techniques help distribute the
content in ways that maximise offload efficiency. The system reduces the demand on upstream network capacity and helps
Netflix work more closely with the ISP networks that host its traffic.
"We designed OpenConnect caching boxes to hold our content, and wherever we can we install them inside of your internet
service provider's network, so that when you see those video bits you aren't actually transiting off of your operator's network," said Hahn.
The new system cut the appearances of the loathed buffering wheel by an order of magnitudes. It also allowed Netflix to
make the CDN software more intelligent. Now, whenever a customer presses play their device can get its content from
numerous places on the internet.
The investment paid off when a fire in an ISP data centre in Brazil burned down Netflix's entire stack of machines. Customers
who had been streaming from the ISP didn't experience any change in their user experience.
"Their devices already knew somewhere else to go get the data," said Hahn. "It didn't interrupt even one frame of streaming,
when we literally burned down the base." >>130
マイクロサービスはAWS側だろう
それこそクラウドでフロントサービスを開発する一番のメリットである柔軟性とリリース期間の短縮を享受できる
配信システムは独自カーネル、デバイスドライバを作ってあとはnginxという理解のため、C言語で完結しても良いが
ユーザーアプリケーションにするのは別にありえない話ではない。しかしオフロード効率を考えればC/C++/アセンブリに落ち着くだろう
https://openconnect.netflix.com/ja_jp/software/
Web Server NGINX NGINX was chosen for its proven scalability and performance.
The audio and video components that comprise each Netflix streaming title are served
directly to the customer client software via HTTP.
ビデオ配信ユーザーアプリケーションはYoutubeの例で言えばC++だが、その可能性はSenior Software Engineer - Video Systems で確認できる >>132
大規模になればなるほどアウトソーシングモデルはコスト的に正当化できなくなる
Google、マイクロソフトが自社でやるのは、それが一番安くつくからだ
NetflixのCDNはISPパートナーを使っているため、何でも自前という発想ではない >>135
Senior Software Engineer - Video Systems
のほうにJavaの文字が出てきているのが気になるけどな
個人的にはネットワーク律速な処理はスレッドが自由なJavaのほうがやりやすいとは思う。
配信システムのほうの英文を読んでみて、ビデオトラフィック以外にレコメンドの処理も重いことが書いているから
キャッシュ以外の処理もやっているんだけど、バックエンドのストレージまで世界中のCDNに分散させてしまうと
管理が大変だからAWSを使っている気がする >>137
>のほうにJavaの文字が出てきているのが気になるけどな
単にC言語＋OOPを使えるエンジニアを探しているだけだろう
Javaに慣れたCプログラマーならC++に移行するのは不可能ではない
ビデオ系処理の開発でJavaを使うのは最適化が煩雑かつ面倒になるため逆に難しい
>キャッシュ以外の処理もやっているんだけど、バックエンドのストレージまで世界中のCDNに分散させてしまうと
>管理が大変だからAWSを使っている気がする
バックエンドのストレージにAWSは使っていない
https://www.computerworlduk.com/cloud-computing/how-netflix-moved-cloud-become-global-internet-tv-network-3683479/
Content delivery
The cloud is only one part of the Netflix user experience. Everything that happens before they hit play takes place in AWS,
but the video content that follows comes from a separate system: Netflix OpenConnect, the company's proprietary content
delivery network (CDN). The OpenConnect appliances store the video content and deliver it to client devices.
これが二度目なので、いい加減覚えるように。「AWSはフロント部分」「バックエンドは自前CDN」 >>138
OpenConnectの仕組みからすると、回線も自前の海底ケーブルを引いてるようだな。
ただ、Senior Software Engineer - Video SystemsのほうにC言語という文言は出ていないから配信をC言語でやっているのは嘘だろ >>140
Senior Software Engineer - Video SystemsはC++のエキスパートと記述があり、職務はエンコーディングソフト開発のためJavaはC言語＋OOPのスキルを指している
Netflix OpenConnectはC言語でカーネル・デバイスドライバを実装、エンドにはnginxで配信
配信システムはカスタマイズしたデバイスドライバ・カーネル（C言語/アセンブリ言語）とnginx
ビデオエンコーディング（C++）
データベース（C）
SaaS系フロント（Java/Javascript）
https://github.com/Netflix/dynomite
https://github.com/Netflix/vmaf
こんなところだ >>141 >>139
Serving 100 Gbps from an Open Connect Appliance
https://medium.com/netflix-techblog/serving-100-gbps-from-an-open-connect-appliance-cdb51dda3b99
The goal was to leverage the new 100GbE network interface technology just coming to market in order to
be able to serve at 100 Gbps from a single FreeBSD-based Open Connect Appliance (OCA) using NVM Express (NVMe)-based storage.
配信システムに（C言語）デバイスドライバ・カーネルモジュールを活用していることは明らかだ >>142
デバイスドライバ・カーネルはたぶんKernel Developerのほうで作っているんだろうが・・・
Video Systemsのほうは何するわけ?
Javaのソースを触らないというのも根拠がない話
繰り返すがC言語という文言はないし >>143
>Javaのソースを触らないというのも根拠がない話
ビデオエンコーディングにC++ではなくJavaを使うと本気で思っているのか？
C言語は配信システムの一部を構成するカーネル開発に使っていると書いてある >>1
Netflixの「AWSはフロント部分」で「バックエンドは自前CDN」 >>144
Javaは配信、ネットワークの部分じゃないかねぇ。使うとしたら。
Video Systemsのほうに
Dynamic Adaptive Streaming over HTTP (MPEG-DASH), or Common Media Application Format (CMAF).
ってえあるし。 >>146
文言とか単語の有無じゃなくて文章読めよ
もしかして英語読めずにエンジニアやってんのか？ >>146
>Javaは配信、ネットワークの部分じゃないかねぇ。使うとしたら。
>Dynamic Adaptive Streaming over HTTP (MPEG-DASH), or Common Media Application Format (CMAF).
nginxがサポートしているので、それは無い
毎回思うが考えが浅く適当すぎだ
それと >>135 をもう一度読むこと
https://openconnect.netflix.com/ja_jp/software/
Web Server NGINX NGINX was chosen for its proven scalability and performance.
The audio and video components that comprise each Netflix streaming title are served
directly to the customer client software via HTTP. Video Systemsは多分こっちだろうな・・・
リアルタイムの配信ではなくてバッチ処理だけど、バックエンドと言えばバックエンドでAWSは使ってる
【集中連載】現地で見たNetflix “最強” の理由（3）高画質を可能にする最新エンコード技術とは？
https://www.phileweb.com/interview/article/201703/24/445.html >>151
それはどこでもふつうにやってる感じだろ。昔と比べてシークや解像度の変更がスムースだったり、大きいキャッシュが作られないとかはそれだろ。
MPEG-DASHの応用技術 | ＮＨＫ-ＥＳ- ＮＨＫエンジニアリングシステム
国際標準の動画配信方式であるMPEG-DASH（Dynamic Adaptive Streaming over HTTP）を応用し、番組途中への動画挿入・差し替え、マルチアングル映像・多言語音声切り替えなどが可能な動画配信サービスを提供するための技術です。
【特 長】
(1) 番組の途中に、視聴者ごとに異なる動画クリップを途切れなく挿入できます。
(2) マルチアングル映像や多言語の音声をそれぞれ切り替えて視聴できます。
http://www.nes.or.jp/transfer/catalog/71a-1.PNG
http://www.nes.or.jp/transfer/catalog/71a-2.PNG
http://www.nes.or.jp/transfer/catalog/2018/01/71a/ >>151
動画の数が投稿型並の数百万を越すサービスならともかく、限られたビデオの
エンコード処理計算に限るなら１回きり処理のためAWSも使えるだろう
この1回きりの計算をサービスのバックエンドに含めるべきかは、それを聞く連中のリテラシー・スキルによる
この場合は「配信バックエンド」と「エンコードバックエンド」を分けるべきだろう
データのエンコードは本番の商用環境から切り離された環境で行えるため、配信をしているバックエンドに負荷をあえてかける必要はないため「配信バックエンド」では行わない
よって専用の自社システムを構築したくないなら、AWSで行うのもあり得ない話ではない
毎回処理を行う「配信バックエンド」は自前CDNで行っているということだ
https://www.computerworlduk.com/cloud-computing/how-netflix-moved-cloud-become-global-internet-tv-network-3683479/
Content delivery
The cloud is only one part of the Netflix user experience. Everything that happens before they hit play takes place in AWS,
but the video content that follows comes from a separate system: Netflix OpenConnect, the company's proprietary content
delivery network (CDN). The OpenConnect appliances store the video content and deliver it to client devices. >>137
C/C++で自由にスレッド使えないと思ってる？ いや、ID変えて必死過ぎ。配信システムにAWSは使っているし、Video Systemsのほうで
c programming languageなんて出てこないし、言ってることはデタラメだよ
Javaはいろんなソース見て使い方出ていないから謎だけど、とにかく求人に書いてあるから
とちくるってC言語なんて言っちゃうよりましだよ >>157
残念ながらIDを変える趣味はない。AWSを使っていることにしたいようだが、フロントや軽い処理ぐらいに限定される
AWSの従量課金で赤字を垂れ流してるのはAbemaTVぐらいだろう
繰り返すがAWSは「ウェブフロント/SaaS」と「エンコードバックエンド（1回きり）」
自前CDNは「配信システムバックエンド」となる（独自カーネル・デバイスドライバとnginx）
Senior Software Engineer - Kernel Developer
https://jobs.netflix.com/jobs/867538
Required Skills
Ability to work independently and collaboratively in all areas of the software development lifecycle
from requirements gathering to operations and maintenance
Ability to read and write code using the C programming language
Ability to work on large-scale software systems
https://www.computerworlduk.com/cloud-computing/how-netflix-moved-cloud-become-global-internet-tv-network-3683479/
Content delivery
The cloud is only one part of the Netflix user experience. Everything that happens before they hit play takes place in AWS,
but the video content that follows comes from a separate system: Netflix OpenConnect, the company's proprietary content
delivery network (CDN). The OpenConnect appliances store the video content and deliver it to client devices.
https://github.com/Netflix/dynomite
https://github.com/Netflix/vmaf
https://openconnect.netflix.com/ja_jp/software/
Web Server NGINX NGINX was chosen for its proven scalability and performance.
The audio and video components that comprise each Netflix streaming title are served
directly to the customer client software via HTTP.
Serving 100 Gbps from an Open Connect Appliance
https://medium.com/netflix-techblog/serving-100-gbps-from-an-open-connect-appliance-cdb51dda3b99
The goal was to leverage the new 100GbE network interface technology just coming to market in order to
be able to serve at 100 Gbps from a single FreeBSD-based Open Connect Appliance (OCA) using NVM Express (NVMe)-based storage.
配信システムに（C言語）デバイスドライバ・カーネルモジュールを活用していることは明らかだ 昨晩から誰もロクに見てないのに
大量英文必死に貼り付けてる奴が怖い 繰り返すがNetflixが活用しているAWSは軽いサービスである「ウェブフロント/SaaS」と「エンコードバックエンド（1回きり）」
Netflixの自前CDNは「配信システムバックエンド」（独自カーネル・デバイスドライバとnginx） に使用されている >>160
これがC言語厨ってやつだよ
もしくは低レベルプログラミング至上主義者
言いたいことはそれだけだと思う >>162
何度でも繰り返すがNetflixが活用しているAWSは軽いサービスである「ウェブフロント/SaaS」と「エンコードバックエンド（1回きり）」に限られる
Netflixの自前CDNは「配信システムバックエンド」（独自カーネル・デバイスドライバとnginx） に使用されている
配信バックエンドにAWSを使って従量課金で赤字を垂れ流してるのはAbemaTVぐらいだろう
Serving 100 Gbps from an Open Connect Appliance
https://medium.com/netflix-techblog/serving-100-gbps-from-an-open-connect-appliance-cdb51dda3b99
The goal was to leverage the new 100GbE network interface technology just coming to market in order to
be able to serve at 100 Gbps from a single FreeBSD-based Open Connect Appliance (OCA) using NVM Express (NVMe)-based storage.
...trying to do encryption closer to the transfer of the data (either from the disk, or to the NIC) so as to take better advantage of Intel’s DDIO and save memory bandwidth.
カーネルモジュールの開発をしたことがあるなら、C言語が使われる必然的理由は分かるはずだが、無知な連中ほど過大な自信を持つらしい >>163
kernel developerのほうはそりゃC使ってるだろうよ。そいつらがnginxなどのミドルまで最適化してるんだろ
だからどうしたという話。
配信システムというと意味合いとして幅が広くなるから
video systems＝ダイナミックオプティマイザも含まれるし、
んで一回きりじゃなくてサービスに対してローンチが必要
【集中連載】現地で見たNetflix “最強” の理由（3）高画質を可能にする最新エンコード技術とは？
https://www.phileweb.com/interview/article/201703/24/445.html
ところが最近では、コンテンツの多様化とディスプレイの高精細化により、さらに高画質・大容量のデータを効率よく伝送できるエンコード技術が求められるようになってきた。
そこでAaron氏のチームは、映像を1～3分単位のチャンク（データのかたまり）に分解して配信する方法を2015年ごろに開発。これを昨年11月に始まったダウンロードサービスにも採用している。
現在はチャンク単位のエンコード処理をさらに発展させた、「ダイナミックオプティマイザー」と呼ばれる最新エンコード技術の導入も検討している。
世界で指折りの動画圧縮技術を研究するエキスパートをチームに招き、
「チャンク単位で映像の内容を判別しながら圧縮を最適化するアルゴリズム」の開発も進めているという。
～
新機能は今年の夏以降のローンチに向けて開発が進められている。
スマホでNetflixを楽しむユーザーにとっては待ち遠しい限りだ。また「モバイル再生でも高画質なNetflix」という売り文句は、
日本をはじめスマホで動画を楽しむすべてのユーザーに強く響くに違いない。 Netflixくらいだと当然、サーバーは自社管理だとおもいきや、調べるとAWSで有名な話だったか。
通常価格ではありえないだろうが、格安契約でコスト面もクリアしてるんだろ。
世界が注目するAWS先進ユーザー、Netflixのすごさ 2018/01/15
ネット動画配信大手の米Netflix。
時には米国のネットワークにおいて3割超のトラフィックを占めるほどの影響力を持ち、「FANG」（Facebook、Amazon.com、Netflix、Googleの頭文字を並べたもの）と呼ばれる巨大ネット企業の一角として名をはせる。
NetflixはパブリッククラウドサービスのAmazon Web Services（AWS）を、2009年に大規模導入した先進ユーザーとしても知られる。2017年末時点で、利用する仮想マシンは15万台超という。
米AWSが2017年11月末から12月初旬にわたって開催した年次イベント「re:Invent」では、Netflixだけで約20のセッションを担当した。
仮想マシンの選び方やチューニング方法、ストリーミング処理によるビッグデータ分析、機械学習、コンテナといった最新技術の活用法などNetflixの先進的な取り組みを聞こうと、世界各地から大勢の聴講者が詰めかけた。
先進的なクラウドユーザーが集まるre:Inventでも、Netflixは別格。世界最先端のユーザー企業といっても過言ではない。
https://tech.nikkeibp.co.jp/it/atcl/column/17/122800596/010500001/
NetflixはなぜAWSのヘビーユーザーなのか？ - 時価総額を5倍に増やしたNetflixの驚くべきビッグデータ経営
2014/07/16
Netflixは動画ストリーミング顧客から上がってくる1日数十億件のイベントを収集し、高精度のレコメンデーションを実現しています。
ペタバイト級のデータウェアハウスを持ち（数万時間の動画コンテンツ含む）、データを最大1万数千のHadoopクラスタで処理して、デバイスの向こうにいる顧客とコミュニケーションをします。
一部のコアシステムを除いて、すべてのシステムはアマゾンのパブリッククラウドAWSで動いています。
アマゾンにとっては常時10万インスタンスの単位で利用してくれるもっとも大口の顧客です。
■完璧なインフラを自社で作っていては間に合わない
2008年8月、Netflixが自社で運用していたDBシステムに障害が発生し、当時の主業務であったレンタルDVDの発送が3日間にわたって停止してしまう事態に見舞われました。
同社のインフラ担当VPによれば、「ポルシェ級」の作り込みをした自社専用システムで業務を処理していたところ、3日間も復旧ができず大きな損害が発生したということで、社内では大変なショックとして受け止められたようです。
これを機に自社インフラ路線を180度転換し、当時存在感を増しつつあったアマゾンのパブリッククラウドを活用する方針を決めました。
1?2年後に控えた、動画ストリーミング業態へのシフト計画も考慮されたことでしょう。
技術関係のVPがカンファレンスでシェアしている内容からまとめれば、AWSへのシフトは、次のような意味を持っていました。
・自社専用インフラの作り込みは、必ず、相応の時間を必要とする。
初期の想定処理量がその時間を経るうちに大きく拡大してしまう可能性もある。
また逆に、想定処理量を大きく下回る可能性もある。
・動いている標的に短時間でアプローチするには、インフラの規模に関する要件を捨象できるパブリッククラウドで行く方がいい。
・すべてがネットで完結する動画ストリーミング業態では、Return on Investmentではなく、Return on Agilityを追求した方が得策だ。
ということでAWSを選択します。
当時は選択できるパブリッククラウドがAWSしかありませんでしたから、もうそれに身を任せるという思いだったでしょう。
当時のAWSは、顧客数200万人規模の大口ユーザーへの対応は未経験であり、Netflixが繰り出す細かな要求を一種のProof of Concept案件として受け止め、そのエラスティック（伸縮自在）性に磨きをかけて行きました。
○AWSの利用料を節約する工夫
・Netflixがアマゾンに支払っているAWS年間利用料は、売上の3％程度と推測されている。だとすれば1億ドル?1.5億ドルの間。
・定常的に動いている処理はreserved instanceで、間欠的に発生する処理は利用単価の安いon-demand instanceでカバー。使わないインスタンスをこまめに課金からはずす。
・AWSのコスト最適化のためのツールIceを自社開発し、オープンソースとして公開。
http://blogs.itmedia.co.jp/serial/2014/07/netflixaws---5n-9282.html Netflixのクラウド移行が完了 2016/2/11
Netflixでクラウドの導入が始まったのは2008年8月、データベースに重大な障害が発生し、メンバーへのDVDの発送が3日間停止するという問題が発生した時です。
この時、データセンターにリレーショナル・データベースを設置するといったわずか一つの障害で垂直的に業務が停止してしまうシステムから、クラウドのように信頼性が高く、水平方向に拡張可能な分散システムに移行する必要があることに気づきました。
おかげさまで、7年におよぶ真摯な取り組みによって、2016年1月上旬にようやくクラウドへの移行が完了し、ストリーミングサービス用にデータセンターに最後まで残してあったBITSを停止することができました。
クラウドへの移行は多くの恩恵をもたらしています。Netflixのストリーミング視聴メンバーは2008年時点の8倍に増え、視聴回数はそれ以上に順調に伸びて、8年間で3桁も増加しています。
Netflixのプロダクト自体は急速な進化を続け、大容量を消費する新機能を多数組み込んでいるため、データ容量は継続的に増大しています。
そうした急速な増大に対応することは、社内のデータセンターではきわめて困難でした。
単純に十分な速さでサーバーを設置することができなかったからです。
ところがクラウドは弾力的な運用ができるので、数分で何千もの仮想サーバーやペタバイトの容量が追加され、そうした拡張が可能になりました。
2016年1月6日、Netflixは新たに130以上の国でサービスを展開し、本当の意味でグローバルなインターネット映像配信ネットワークとなりました。
世界中に配置されたAWSクラウドのリージョンを複数利用することにより、ダイナミックに方向転換し、グローバルインフラの対応能力を拡大し、Netflixメンバーに場所を問わず、より快適で楽しいストリーミング視聴を提供することが可能になりました。
コンピュータの拡張性やデータ保管のニーズ (ビジネスロジック、分散型データベースおよびビッグデータ処理/分析、推奨、トランスコーディング、Netflixのアプリケーションを構成するその他の何百もの機能) すべてにクラウドを活用しています。
動画は世界中に張り巡らされたコンテンツデリバリネットワーク、Netflix Open Connectを通じて配信し、効率よくメンバーのデバイスに伝送しています。
クラウドの導入によって、サービスの可用性も大幅に向上しました。
データセンターでは多くの障害が生じ、特にクラウド移行の初期段階ではクラウドに不可避な問題に直面しましたが、全体的な可用性は着実に増加しており、サービスの使用可能時間に関する目標の99.99%近くに達しています。
コストの削減は、クラウド移行を決定した主な理由ではありません。
しかし、ストリーミング視聴1回あたりのクラウドの費用は、データセンターにおけるその費用のほんの一部に収まっています。うれしい誤算です。
これはクラウドの弾力性によるもので、おかげでインスタンスタイプの組み合わせを継続的に最適化し、大容量バッファを維持する必要なく (コンピュータなどの) 設置面積をほとんど瞬間的に拡大・縮小することができるようになりました。
さらに、大規模なクラウド・エコシステムからしか得られないスケールメリットの恩恵も享受しています。
https://media.netflix.com/ja/company-blog/completing-the-netflix-cloud-migration >>163 >>119
一部の連中がAbemaはAWSと騒ぐので誤解していたが、AbemaTVでさえAWSを配信につかっていなかった
http://ascii.jp/elem/000/001/260/1260602/index-2.html
このストリームを作る作業をやったら、あとはAkamaiさんのCDN（コンテンツデリバリーネットワーク）
を介して映像をユーザーに届けているわけです※1。
―― やっぱり、Akamaiなんですね。
長瀬 ええ。Akamaiを介さないと、全部のアクセスをGoogleのクラウドで受けてしまって
レスポンスが悪くなるので、CDNを使ってキャッシュをインターネット上にばら撒くと言った感じですね。 >>164 >>165 >>166
とにかくNetflixはAWSというイメージを植え付けたいようだが >>167 でも分かる通り
AWSはあくまで軽量なサービスで活用すべきなのは少し考えれば分かるはずだ
https://newspicks.com/news/3345004?ref=user_111116&;u=oa14we&from=twitter
八田 浩
GOLF Net TV株式会社 取締役
2018年10月11日
"CDNへの依存度は企業によってまちまちだが、Netflixの場合、「すべてのユーザーに向けた、
すべてのコンテンツの配信」のうち、実に98%がOpen Connectを経由する。"
動画サービスが様々な要素で戦うとしても最終決戦の舞台の１つはこのCDNだと言うことが
そろそろ浸透してきました。NetflixがCDNの内製化に取り組んでずいぶん経ちますね。
コストインパクトとユーザビリティに直結します。 AWSでエンコードするって主張しているやつは、エンコード前の動画データをAWS
にアップロードして、エンコード後の動画データをAWSからダウンロードすると
いうのか？
AWSってトラフィック量で課金体系変わるんじゃなかったっけ？ Netflixの快適なモバイル視聴への取り組みと新機能を米国本社で見た
2018年9月27日
これまでの西田宗千佳氏の記事にもある通り、Netflixは映像エンコーディングを、全てAmazonのクラウドサービス「Amazon Web Services(AWS)」で行なっている。
配信は、世界中にあるISP(インターネットサービスプロバイダー)やIX(インターネットエクスチェンジ)に配置しているサーバーから行なう。
インターネットの基幹ネットワークに負荷をかけずに配信するネットワークを、Netflixは「Open Connect」と呼んでおり、現在はトラフィックのうち98%がOpen Connectで視聴されているという('17年の西田氏取材時点では95%だった)。
https://av.watch.impress.co.jp/docs/news/1144985.html >>167
AbemaはGCPな。AWSのGoogle版だ
> 長瀬 ええ。Akamaiを介さないと、全部のアクセスをGoogleのクラウドで受けてしまって
> レスポンスが悪くなるので、CDNを使ってキャッシュをインターネット上にばら撒くと言った感じですね。
この文言からCDN（Akamai）をキャッシュとして使っている。
Netflixより簡易なんだろうな まだNetflixだのAWSだの騒いでる馬鹿がいるのかｗ
頭おかしいんじゃねｗ プログラマーって、新しい言語が流行ると分厚い仕様書読んだりぐぐったり掲示板で質問したりして
勉強しないといけないのか >>176
違うね
最初は浅く広く、徐々に深く
初学者の立場の質問は決してしない、全部自分で調べる
勉強は義務じゃなくて興味があるから >>176
もう言語の違いは方言の違いみたいな感覚だからそんなに必死に勉強しなくても使えるようになるね 掲示板で聞いて答えが帰ってくるようなものってあんま勉強する意味ないよね、お金の面で
誰も答えられないようなものこそ勉強して金取るぞってなる そこそこ有名な言語をある程度使えるようになれば
他言語の習得は楽になる
ただフロントエンドとバックエンドは全然違う 言語よりフレームワークのお作法学ぶのに時間がかかる ぼくは、Swiftしかつかえないです(´･ω･`) >>42
oracle製のjavaっぽい何かでしょ >>107
確かに出来合いのものなら何使っても同じだわ >>181
同一言語で複数のフレームワークを触っていくと言語のありがたみがわかる
フレームワークはころころ変わるけど、言語ってのは数10年の寿命がある
基礎技術ってのはそういうもんだ >>176
ずっと勉強は続けないといけないけど、そのかわり仕事はあまりしなくていい。 >>188
最近は新しい機能を取り入れる速度が上がってるから言語も数年で古くなるけどな。
10年単位で使えるスキルとなると、コンピュータ・サイエンスとか数学とかになるね。 >>190
TOPのほうのメジャー言語なんか10年単位で少し入れ替わる程度だよ
少し落ち目でも仕事はあったりするし >>192
10年前のJavaしか知らないのならJavaの現場に関わらないで欲しい。
C#も同じだけど。 >>181
フレームワークとは違うけどカーネルモジュール作るのは苦労したわ >>193
ブランクがあるような話じゃなく、一つの言語に入れ込んで時代についていけるかという話でしょうが
まあ、何とかなるっていうのと、Java/C#なら型推論とREPLの使える言語を一つ趣味でやっておけば
多分時代に取り残されることもない 配信を重い処理
その他を軽い処理
扱いにしてるのがそもそも大間違い
映像レベルで解析してるみたいだし
当然ディープラーニングやら使っているのは間違いない
その辺のバッチ処理も多分全てAWSだと思われる
NetFlixが配信する全ての動画に対して行われるわけで処理量は膨大だろう。
一方AWSに限らずクラウドはネットワークコストはそこまで安くならないし
サービス使っていると中々チューニング難しい
だから配信を最適化するために自前でそこをやろうとするのは理解できる
しかしCPUやメモリバウンドならクラウド使ったほうが100％安い
だって全部自前で作ったら、常にピークに合わせて調達が必要だし。
AmazonやGoogleみたいに余剰分をクラウドとして売らないとペイできない。
その前提で配信システム実装自体は自前でも
そのホスティングはまた別の話だろう
浮き沈み激しいのに自前でホスティングするのは
コストメリットがあるとは思えない
かといってCDNという性質上
AWSでホスティングは多分ありえない
だからといってそこが自前かどうかは文言だけではわからん
と思ったけど
https://openconnect.netflix.com/ja_jp/
やっぱりアライアンス組んでISPに配信させてるじゃん
思ったとおりホスティングは自前じゃなかったね 俺はSEやPGじゃなくて機械系工学エンジニアなので
プログラムは高級な電卓として科学計算にしか使ってないけど最近はMATLABよりもPython使ってる
NumpyやScipyがとても便利で使いやすい
最近流行のディープラーニングもPythonだしこれ一つで事足りる感じ
フリーだしとてもいい >>199
Netflixの虎の子の配信サーバとそのネットワークを自社でカリカリに作りこんでます
まあ、それだけの話
ラストワンマイルはISPと協力して配信していますってことでいいだろ
問題なのは、フロントエンドとバックエンドってバカげた区分しかないシステム構成の概念とか
C言語も適材適所で使えばいいんだけどなんでもC言語とかC言語使っていないところでも使っているって言い張ったりそういうところ
一般的には配信サーバってフロントだし、AWSでトランスコードをしている動画システムのほうがバックエンドになるだろ
（んでAWSは一時的に大量のハードウェアリソース確保するような使い方だと安い）
Netflixはいかにして世界中のISPと協力し、優れた視聴体験を生み出しているのか
https://media.netflix.com/ja/company-blog/how-netflix-works-with-isps-around-the-globe-to-deliver-a-great-viewing-experience
> Netflixのトラフィックに海底を通る高額な回線を使うのではなく、まず米国のトランスコーディング用レポジトリから各ファイルをいったんオーストラリア国内のストレージ場所にコピーします。
このトランスコーディングリポジトリって出てくる点からしても多分トランスコードと配信システムが連携しているんだろ
で、しかもこれだと配信の後ろで動いているバックエンドとしてだ
んで、>>1の言語ランキング見てると、goとswiftっていうLLVM系言語が躍進しているから
ちょうどC++の領域が侵食されつつあるところが面白いのに
C言語至上主義とか、あと低レベルプログラミングってのもさらに進むと
ニコ動みたいにハードのほうへ行っちゃうニッチを持ち上げるのも気に食わん
ニコニコ動画をFPGA/ASICで高速化、ネット企業のドワンゴがハード技術者を募集
https://tech.nikkeibp.co.jp/dm/article/NEWS/20141128/391400/ >>201
LLVM系言語って、C/C++もLLVMでサポートしてるんだけど。
ちなみに、swiftはLLVM採用してるけど、goはLLVM使ってないんじゃなかった？
あと、FPGAやTPUのようにハードで問題を解決するのはこれからも続くだろう。
電力消費量が多くて発熱量も大きなCPUを高クロックでぶん回して解決するのはエコじゃない。 >>18
お前は何がつくれるか
それだけさ
言語だけ使えるとかならいらない子だ >>202
goは独自とLLVMを切り替えられる
C/C++だけからしたらgccでいいわけで、そのノウハウが他言語に移植されて行っている点が重要 そもそもgccのバックエンドの代替として開発が始まったのがllvmなわけで。
その後フロントエンドも開発されて、C/C++から見たらgccを置き換えるのがllvm。
swiftなど最近の言語がgccではなくllvmを採用しているのはllvmの方が新しくて
使い勝手が良かったからじゃないかな。llvmがなかったらgccを採用してただろう。 あ、あとLLVM選ぶのはライセンス的なものもあるかもね。
GCCはどうしてもGPLになるから。 >>205
LLVMの肝はLLVM IRで、これが言語開発者にとって使いやすかったということで、
GCCでは置き換えられないのでは?
あまり実情はしらないが、これのおかげで近年のスクリプト言語みたいで
実際に動作が早いコンパイル言語が出てきていると解釈している >>205
てかgccはいつまで残るの？さっさとllvmに置き換わってほしいけど
Linuxカーネルコンパイルができないのがネックなんだっけ？ >>199
>NetFlixが配信する全ての動画に対して行われるわけで処理量は膨大だろう。
これまで10年程度のもの全て合わせても数万ぐらいでYoutubeと比べれ微々たるもの
NetFlixも自社サーバーの運用はしている
CDNはそのキャッシュ
https://openconnect.netflix.com/ja_jp/
Open Connectにもそう書いてある
>一般的には配信サーバってフロントだし、AWSでトランスコードをしている動画システムのほうがバックエンドになるだろ
サーバーサイド（サーバーが処理する）ならバックエンド
だが配信バックエンドではない
自社サーバー＋CDNではないからだ
NetFlixの資料にもメディアクラウドという配信基盤と区別したレイヤーで定義している
動画の形式変換にAWSを使う理由は配信システムと違って、動画の形式変換は稼働時間が少なく、普段は遊んでいる状態だから >>210
>サーバーサイド（サーバーが処理する）ならバックエンド
この定義も厳密に言えばどうでも良い、ストレージやデータベース、内部ロジックをバックエンドとする定義もあるから厳密性を与えるのは難しい
自社サーバー＋CDNはストレージ、データベース、配信実装だから配信バックエンドと呼べば良いだけだ
>>201 のLLVMの勘違いを見れば非技術者だと分かるので、あえてツッコんでも意味はない
https://newspicks.com/news/3345004?ref=user_111116&;u=oa14we&from=twitter
八田 浩
GOLF Net TV株式会社 取締役
2018年10月11日
"CDNへの依存度は企業によってまちまちだが、Netflixの場合、「すべてのユーザーに向けた、
すべてのコンテンツの配信」のうち、実に98%がOpen Connectを経由する。"
動画サービスが様々な要素で戦うとしても最終決戦の舞台の１つはこのCDNだと言うことが
そろそろ浸透してきました。NetflixがCDNの内製化に取り組んでずいぶん経ちますね。
コストインパクトとユーザビリティに直結します。 >>211
>やっぱりアライアンス組んでISPに配信させてるじゃん
データセンターの火事がNetflixのサーバーを燃やしてもCDNのキャッシュのおかげでサービスを継続したという逸話だ
最近の知ったかぶりはコロケーションの意味も分からないらしい
https://www.computerworlduk.com/cloud-computing/how-netflix-moved-cloud-become-global-internet-tv-network-3683479/
"We designed OpenConnect caching boxes to hold our content, and wherever we can we install them inside of your
internet service provider's network, so that when you see those video bits you aren't actually transiting off of your operator's network," said Hahn.
The new system cut the appearances of the loathed buffering wheel by an order of magnitudes. It also allowed Netflix
to make the CDN software more intelligent. Now, whenever a customer presses play their device can get its content from numerous places on the internet.
The investment paid off when a fire in an ISP data centre in Brazil burned down Netflix's entire stack of machines.
Customers who had been streaming from the ISP didn't experience any change in their user experience. >>210
×これまで10年程度のもの全て合わせても数万ぐらいでYoutubeと比べれ微々たるもの
○これまでのもの全て合わせても世界中で13,300タイトルでYoutube/ニコニコ動画と比べれば微々たるもの
How many movies does Netflix have?
https://www.quora.com/How-many-movies-does-Netflix-have
Netflix offers a total of around 13,300 titles worldwide >>202 >>204 >>205 >>207
C/C++のLLVMフロントエンドの名称はclang
LLVMの基本知識なら検索すれば大体手に入るので、誤った情報を出すものがいない限りは繰り返す必要性は感じないが
gccと対比するなら通常はclangとなる >>214
GCCって
GNU Compiler Collection
の略だって知ってた？
>>207
別にgccはgccで残るだろ。
llvmに置き換えたければあなたの環境で置き換えればいいだけ。 clangはフロントエンドだけの呼称だろうに
gccと比べるならLLVMのほうがまだ近い
clangフロントエンドでバックエンドがgccな場合もあるのだし >>215
LLVMでおきかえるとかいう話はしていないし、ただLLVMが登場したことで、
crystalとかkotlin-nativeとか新機軸の言語が出てきた
だから、gccだけでllvmが出てこなかったらそういう新しい動きもなかったわけで、
llvmがなくてもgccが代わりになっていたというのはちょっと違うのではないか？というわけ
>>216
そうだよな、俺としてはGCCとLLVMっていってるのはツールまとめる仕組み全体のことをいってるわけで
なにも間違っていることは言っていないはず >>215 >>216 >>217
C/C++のフロントエンドならgccとclangを対比するのが普通だと言っている
特に騒ぎ立てるような内容とは思えない 話の流れとして主にバックエンドとしてのGCCやLLVMについて語っているのは明白なので唐突にフロントエンドの対比を披露されても意図がわかりにくいのでは。 >>219
>>201 >>202 >>204 でC/C++を倒す前提としてLLVMを援用しているのだからclangを出すのが不適当とは言えないはずだ >>221
だからC/C++を倒す前提としてLLVMを援用するのは妥当ではないということだ
clangが話題になった時点でその手の話は、ネットで検索した程度の知識では追いつかなくなる ネットで検索しただけの知識で語らないといけないの？ >>223
ネット検索しただけでなく経験にもとづくか、ミスリードさせない内容なら、わざわざ指摘しない
必須ではないがこの手の話題には自前コンパイラ、GCC internals(C)やLLVMのバックエンド・フロントエンド（C++）、アセンブラに経験・理解があるのが望ましい
PythonのようにCにバインドされることが特徴な言語ならともかく、バックエンドは二択に単純化はできない
今でもターゲットによっては自前でバックエンドのコード生成等を書く必要がある
gccもはじめのころはyaccから作っていたわけだが、その頃に比べれば全てにおいて楽になったことで言語が量産され新言語が生まれては消えるわけだが
新言語の特徴としてはコーディングを簡単にはするが、それによって書きたいロジックが実現できなかったり余計なオーバーヘッドや、
未確認のセキュリティホールが入ることもあるから、日本の会社だと少ないが自分で作ってみる経験を培うことだな ○日本の会社だと機会は少ないが自分でコンパイラを作ってみる経験を培うことだな それでも基本C/C++を使い続けるよ
やたら流行りの言語に飛びつく奴はah
覚えとけ
つ「慌てるネコは貰いが少ない」 能書き垂れている暇があったら有効なソースの一行でも書けよ >>226
また過剰反応か
具体的にどこが上から目線で奢りなのか詳しく >>54
最速かどうかより
心置きなく最適化できるかどうかだ >>231
>実務パーなの透けてるから
「上から目線の奢り」という表現に近そうだ まあ同じ言語であってもどんどん仕様が変わるからな
常に情報を仕入れて勉強しないと、この先生きのこれない >>176
どうせお前もそのうち複数の言語使うようになる
なぜなら便利だから
言語によって書きやすいもの、得意なものが違う
楽をするために、新たな言語習得に手を伸ばすのは時間の問題だ nak
‏
@nak_JPN
10月19日
派遣会社の事務所数の比較。
日本、ブッチギリの一位だから。
これ上前をハネられているという事でして。
甘んじて受け続ける日本人って、やっぱ変わってる。 pic.twitter.com/hmmGcCK1YF
https://twitter.com/5chan_nel (5ch newer account) >>217
すまん、>>215 の後半部分は >>208へのレスだった。 >>224
議論の流れ上出てきたバックエンドが二つなだけで、
バックエンドが二択だとはどこにも書いていないと思うけど。
誤解を与えるとか書いてるけど、そもそも誰もここの書き込みを参照して
コンパイラの構成を勉強をしようとは思わないだろ。 >>237
>議論の流れ上出てきたバックエンドが二つなだけで、
>バックエンドが二択だとはどこにも書いていないと思うけど。
印象は誰しも持つものだから、読解力の問題に過ぎない。そう思っていたのであれば意見としては受け止めておく
ただしGCCとLLVM以外のバックエンドに言及はしていないだろうし、もともと趣旨は二択のところではない
「GCCバックエンド」とLLVMの比較をするのであれば、自前コンパイラの経験はあったほうが良く、そのためにはアセンブラの経験も必要であり
順序というものがあると指摘してるだけだ >>237
>誤解を与えるとか書いてるけど、そもそも誰もここの書き込みを参照して
>コンパイラの構成を勉強をしようとは思わないだろ。
>>224 には「誤解を与える」とは書いていない
「ミスリード」とは書いたが（論点ずらしでなく）知識・経験が欠乏していると判断したなら、それを間接的に指摘して害があるとは思えない
文章的には自らも含めて独り言という形でしている以上は、厳密には指摘でさえない
もっとも本当に無知なら指摘として受け止める可能性もあるが、そこまで考える必要性はかんじない
妙な書き込みを発見して、理解・経験してから書いた方が良いと指摘すべきではないという意見という理解で良いのか？
>>226 >>231 のほうがよっぽど酷い態度だとは思うが >>217
>俺としてはGCCとLLVMっていってるのはツールまとめる仕組み全体
詳しく >>205
>C/C++から見たらgccを置き換えるのがllvm。
詳しく >>201
>ニコ動みたいにハードのほうへ行っちゃうニッチを持ち上げるのも気に食わん
>ニコニコ動画をFPGA/ASICで高速化、ネット企業のドワンゴがハード技術者を募集
詳しく >>215
>GCCって
>GNU Compiler Collection
>の略だって知ってた？
>>218 >>222 で解答済みだ
あえて言うなら >>217 あたりに言うべきだと思うが詳しく >>207
>これのおかげで近年のスクリプト言語みたいで
>実際に動作が早いコンパイル言語が出てきていると解釈している
詳しく >>238
> 「GCCバックエンド」とLLVMの比較をするのであれば、自前コンパイラの経験はあったほうが良く、そのためにはアセンブラの経験も必要であり
> 順序というものがあると指摘してるだけだ
一般的なコンパイラの知識は必要だと思うし、それを学習するために
自前コンパイラを作るというのはいい方法だと思うが必須では無いだろう。
ちなみに、そういう経験が無いと思ったの？ >>218
なんでC/C++のフロントエンドを比較するの？ ああ、すまん。対比だったな。
gccコマンドに対応するのはclangです
といちいち言及することでも無いだろう。 >>245
>一般的なコンパイラの知識は必要だと思うし、それを学習するために
>自前コンパイラを作るというのはいい方法だと思うが必須では無いだろう。
必須とは書いてないはずだが
さらに言えば「必須ではない」と前置きもしている
>ちなみに、そういう経験が無いと思ったの？
>>223 に対しての独り言なのだから ID:uJphLTH1 が自分のことだと思ったのであればそうだろう
違うと思ったのであれば、そうではないことになる >>247
>>220 で書いてあるから良く読むように ちなみに、>>205 でのgccはコマンドとしてのgccではなくGCC(GNU Compler Collection)のつもりで書いた。
紛らわしいと思ったが、Shiftキー押すの面倒で横着した。すまんかった。 >>245
>一般的なコンパイラの知識は必要だと思うし、それを学習するために
>自前コンパイラを作るというのはいい方法だと思うが必須では無いだろう。
必須とは書いてないはずだが
さらに言えば「必須ではない」と前置きもしている
どこに必須と書いたか引用してもらえないだろうか？ >>220
C/C++を倒すのにLLVMもclangも関係なくね？
そもそもどちらもC/C++よりのプロダクトだし。
LLVMがあるからまだまだC/C++は終わらんよという論理の展開ならともかく。 >>253
>>222 で解答している。すぐ下のやり取りも読まないという前提で返信しているのか どうでもいい議論なんて熱くなってやらずに、楽しくSwiftとPythonの話もしようぜ！ >>251
であるなら尚のこと >>214 で過剰反応する理由が分からないな なんか妙に肩に力はいってますねー
リラックスしようぜ！ 一体なんのためにやってるのさ
自分の正しさの証明？ 読んだ上で、やはり意図がわからない。
単にgcc, llvmと関係のある単語を出しただけという理解で良いか？ 写真を一切修正しない下着ブランド「エアリー」は、無理したくない女性たちの心をわかっている
http://bpp2.shutterdaddy.com/10.jpg >>207
>LLVMの肝はLLVM IRで、これが言語開発者にとって使いやすかったということで、
これについても詳しく >>259
>読んだ上で、やはり意図がわからない。 >>259
>読んだ上で、やはり意図がわからない。
>>253 に >>222 が解答できていないという意味か？
>>253
>LLVMがあるからまだまだC/C++は終わらんよという論理の展開ならともかく。
>>222
>だからC/C++を倒す前提としてLLVMを援用するのは妥当ではないということだ
>clangが話題になった時点でその手の話は、ネットで検索した程度の知識では追いつかなくなる >>245
>一般的なコンパイラの知識は必要だと思うし、それを学習するために
>自前コンパイラを作るというのはいい方法だと思うが必須では無いだろう。
必須とは書いてないはずだが
さらに言えば「必須ではない」と前置きもしている
繰り返すが、どこに必須と書いたか引用してもらえないだろうか？ >>263
> だからC/C++を倒す前提としてLLVMを援用するのは妥当ではないということだ
ここまではわかる。
> clangが話題になった時点でその手の話は、ネットで検索した程度の知識では追いつかなくなる
そもそも clangは >>214 まで話題に出てきていないわけで。 >>240
フロントエンドとバックエンドとIR（中間言語）全部含めてってことだよ
んで、C/C++のノウハウが共有されるのって、バックエンドを通してだから元々の意味合いは暗黙的にバックエンドになるし、
他の言語を含めるとなるとclangだけじゃない他言語独自のフロンエンドも含めてもらわないと困る
>>242
エンコードのサーバが減らせるって話が大部分だけど、最後にやっぱりレイテンシの短さに言及していて、
リアルタイムな動画配信への応用も考えてるっぽい
第3回 ドワンゴがFPGAを使った開発に乗り出したワケ
http://gihyo.jp/dev/serial/01/dwango-engineersoul/0003
> ――FPGAだからこそ実現できるサービスとしては，どういったものが考えられるでしょうか。
> 小嶋：ネタばれになるのでなかなか言えないのですが，実はFPGAには効率以外にもレイテンシが短いという大きなメリットがあります。
> その特性を利用したサービスを生み出せる可能性はあります。ネットワークからまずメモリに入ってCPUで処理するよりも，
> ネットワークから入ってきた瞬間に何かができる。それによって現状では難しいサービスを実現し，未来の可能性を広げたいですね。
>>244
新参言語に有利なベンチマークだとは思うが、ここまでCに迫っている。というか差がついていない
重要なのはCとの比較よりも、従来のインタプリタのスクリプト言語と全然速度が違う点だと思うが。
20の言語/環境でてきとうにベンチマークしてみた (Rust, Go, Crystal, Nim, Swiftなど)
http://safx-dev.blogspot.com/2015/11/20-rust-go-crystal-nim-swift.html あらあら、触ったらだめな人ですね＾＾
ID:Yqt/tfAT >>265
>> だからC/C++を倒す前提としてLLVMを援用するのは妥当ではないということだ
>ここまではわかる。
>
>> clangが話題になった時点でその手の話は、ネットで検索した程度の知識では追いつかなくなる
>そもそも clangは >>214 まで話題に出てきていないわけで。
「ここまではわかる。」といった時点ですでに理解しているということだな
C/C++を倒すためにLLVMを援用する妥当性と、C/C++フロントエンドのclangは同じ文脈だから無理やり切り離して考えるほうが不可解だ
clangという前提条件を入れてもなお、C/C++を倒すためにLLVMを援用するのであれば、LLVM開発に関する知見はある程度もっていないときついだろう
なぜならLLVMによってclangと他の言語フロントエンドに差異が生まれる原因に言及する必要が出るからだ
ID:uJphLTH1 が「わかる」ように質問しよう
（１）LLVMバックエンドを導入することによってC/C++フロントエンドであるclangに対して他のフロントエンドには競争的優位性が生まれるのか？
（２）（１）によって競争的優位性を持つ点がないなら、LLVMバックエンドのどの機能によってGCCバックエンドでは実現できない競争的優位性をもたせることができるのか？ >>266
>フロントエンドとバックエンドとIR（中間言語）全部含めてってことだよ
それを「ツールをまとめる仕組み」と呼んでいるのか？
あまり理解しているようには聞こえないが
>エンコードのサーバが減らせるって話が大部分だけど、最後にやっぱりレイテンシの短さに言及していて、
>リアルタイムな動画配信への応用も考えてるっぽい
検討違いの解答だ
FPGAはVerilog/VHDLを使うことになるが、「ニコ動みたいにハードのほうへ行っちゃうニッチを持ち上げるのも気に食わん 」という表現に問題がある
FPGAからASICに変換する際にはハードの知識は不要だが、ソフトウェアエンジニアの職務の範疇内だ >>267 >>268 >>1
たかが３行を書いただけで長文の過剰反応が続けて３つも来たほうが精神病理学的には興味深い
差し障りもないNetflixのCDNに関する情報提供に対して、アマゾンのAWS営業戦士が過剰反応したのが
発端としなぜかこうした無関係な議論にまでなった以上は「頭がイカレタ」なる称号はAWS営業戦士に送られるべきだろう
ハイブリッドクラウドが一巡しAWSが使えるパブリッククラウド分野が飽和している中でAWSのソリューションのみに特化した企業も
見当たらないわけで、そうするとNetflixのAWSに過剰反応するのはアマゾンの従業員ぐらいだ >>270
×FPGAからASICに変換する際にはハードの知識は不要だが、ソフトウェアエンジニアの職務の範疇内だ
○FPGAからASICに変換する際にはハードの知識は必要だが、ソフトウェアエンジニアの職務の範疇内だ >>210 >>211 >>1
>NetFlixが配信する全ての動画に対して行われるわけで処理量は膨大だろう。
これまでのもの全て合わせても世界中で13,300タイトル（2015）でYoutube/ニコニコ動画と比べれば微々たるもの
NetFlixの資料ではエンコーディングはメディアクラウドという配信基盤と区別した別レイヤーとして定義している
動画の形式変換にAWSを使う理由は、配信システムと違って動画の形式変換は稼働時間に空きがあり、普段は遊んでいる状態だからクラウドに向いているのだろう
How many movies does Netflix have?
https://www.quora.com/How-many-movies-does-Netflix-have
Netflix offers a total of around 13,300 titles worldwide
NetFlixも自社サーバーの運用はしている。CDNはそのキャッシュであるとOpen Connectのサイトにもそう書いてある
https://openconnect.netflix.com/ja_jp/
言語の話に戻すのであればエンコーディングの検証ソフトはC++で書かれている
https://github.com/Netflix/vmaf
VMAF is a perceptual video quality assessment algorithm developed by Netflix. VMAF Development Kit (VDK) is a
software package that contains the VMAF algorithm implementation, as well as a set of tools that allows a user
to train and test a custom VMAF model. For an overview, read this tech blog post, or this slide deck. >>269
C/C++を倒すためにLLVMは関係無いところまでは合意が取れてると思っていいのかな？
> （１）LLVMバックエンドを導入することによってC/C++フロントエンドであるclangに対して他のフロントエンドには競争的優位性が生まれるのか？
C/C++を倒すという話なのに、いつの間にかclangの話になっちゃった >>272
> FPGAからASICに変換する際にはハードの知識は必要だが、ソフトウェアエンジニアの職務の範疇内だ
ソフトウェアエンジニアがやったとしても、ハードドメインの知識は必要なんじゃん。
そもそも「ニコ動みたいにハードのほうへ行っちゃうニッチを持ち上げるのも気に食わん 」
という表現は、ソフトウェアエンジニアの職務内かどうかを問題にしているわけではないだろう。 言うほどソフトの範疇でも無い気はするがな
エンベデッドでもやってるならマシだけど そもそもドワンゴがソフトウェアとハードウェアの技術者混成のチームでやっている
第3回 ドワンゴがFPGAを使った開発に乗り出したワケ
http://gihyo.jp/dev/serial/01/dwango-engineersoul/0003?page=2
ハードウェアとソフトウェアの開発の違い
――実際に開発するうえで苦労された点はありましたか。
小嶋：今回，ハードウェア側のエンジニアも入っているのですが，その人たちとソフトウェア側の人たちとの考え方は違うんですね。
今はハードウェアの人たちがソフトウェアのほうに寄っていっているのですが，そこは難しいところです。ソフトウェアエンジニアがハードウェア側に寄るのと同じ難しさがあります。
宮崎：両方が寄っていかなくてはならないのですが，考え方が全然違いますね。ハードウェアの人たちはこうしたいという思いがあり，
ソフトウェアの人は自分たちのやり方が普通だと思っている。そういった常識のぶつかり合いがあります。
小嶋：プロジェクトの進め方も，ハードウェアの人たちはウォーターフォール式で最初にすべて決めるのが普通です。しかし，ソフトウェアはそうではなくて，
作りながら考える，アジャイル的な発想が浸透している。そこをうまく融合しなければならない。そこが最初の壁でした。 >>278
>>201で技術者募集していたのが2014年、>>277の記事が2017年。
文字通りゆっくりやってんだろ >>269
> （１）LLVMバックエンドを導入することによってC/C++フロントエンドであるclangに対して他のフロントエンドには競争的優位性が生まれるのか？
> （２）（１）によって競争的優位性を持つ点がないなら、LLVMバックエンドのどの機能によってGCCバックエンドでは実現できない競争的優位性をもたせることができるのか？
たぶん、あんま細かいこと聞いてもたぶんgccの中の人がカバにダンスさせるのは大変なんだよ！って逆切れして終わると思う
>>266のリンクのベンチマークで、swiftがCの速度上回っていたり、他の言語もCとほとんど同じ速度出しているのがLLVMバックエンドの優位性を証明している
Clang
https://ja.wikipedia.org/wiki/Clang
・背景
2005年初頭、アップルはLLVMシステムを自社で開発している様々なシステム内で利用するための作業を開始した[5]。アップルはObjective-Cを多用しているため、
GCCの性能向上に興味を抱いていたがほとんど進展が見られず、Objective-Cの性能を上げるためにGCCをアップル版に分岐させるか、
新しいコンパイラを採用するのを選択をせまられていた。そこで、アップルはC99、Objective-CおよびC++ をサポートするコンパイラを1から作成した。このClangプロジェクトは2007年7月にオープンソース化された。
GCCは巨大なシステムで開発がしづらい面もあり、長年のGCCの開発者の一人は「カバにダンスを踊らせるのはあまり楽しいことではない」と述べている[6]。 今日もお薬増やしておきますね
ID:NIUC+fPK >>274
まえは前段と後段のうち前段だけを無視したが、今度は（２）は完全に無視するわけだな
（１）と（２）の二段を答えるなら、まだ「生産的」なわけだが、まずそこから始めるべきだろう
>>214 は論評するわけでもなく中立的に観察を書いた三行なわけだが
あたり触りのないことしか書いていないのに過剰反応する神経が理解できない
>>226 >>231 の一方的な個人攻撃あたりには一切批判精神が生まれないわけで、随分と都合の良く精神回路が出来ているものだ >>280
>>>266のリンクのベンチマークで、swiftがCの速度上回っていたり、他の言語もCとほとんど同じ速度出しているのがLLVMバックエンドの優位性を証明している
ベンチマークとしての価値はほとんど無いな
フィボナッチ計算のベンチマークでは関数呼び出しのパフォーマンスぐらいしか測れない >>277
>そもそもドワンゴがソフトウェアとハードウェアの技術者混成のチームでやっている
ハードウェア技術者と言い切れる自信だけは大したものだな
Verilog/VHDLプログラミングをソフトウェアエンジニアの職務と定義する会社はいくらでもあるが
ドワンゴ内ではハードウェア寄りのソフトウェアエンジニアを「ハードウェア」と表現しているようにも読める
奇妙ではあるがドワンゴ内でそうだと言うならそうなんだろう
ハードウェア技術者となると半導体技術・電子・センサー等あたりを勝手に想像するが、その手の人材は
デジタル回路の設計プログラミングをするには「ソフトウェアプログラミング」の教育を一からしないと駄目という話は聞いたことがある >>285
>ハードウェア技術者となると半導体技術・電子・センサー等あたりを勝手に想像するが、その手の人材は
>デジタル回路の設計プログラミングをするには「ソフトウェアプログラミング」の教育を一からしないと駄目という話は聞いたことがある
捕捉だがFPGAに依存せずに、メモリやプロセッサをスクラッチから設計・テストしている半導体技術者であれ
ば再教育は不要のはずだ。もっとも日本の半導体技術者は家電・製造系が圧倒的に多いと思うが
Software Engineer: CPU and Memory Hierarchy
Apple
JOB SUMMARY: Are you passionate about changing the world? We have a critical impact on getting high quality
functional products to millions of customers quickly and we are hiring all levels from junior to senior roles.
You will be a software engineer developing test code to drive the CPUs, the caches, the fabric, the memory
controller, and the coherency point with the goal of finding bugs.subsystems in silicon.
Key Qualifications
You have the following:
Experience with low-level CPU code interacting with the MMU and dealing with load/store units
Experience with finding bugs in SoC designs and implementations
Deep understanding of CPUs, and memory hierarchy
Assembly language knowledge is a requirement
Skilled and interested in validation and debugging
Ability to work well on a team, but to be responsible and self-driven.
CPU Performance Engineer- Austin
Apple
In this highly visible role, you will be at the center of a chip design effort working with all disciplines,
with a critical impact on getting functional products to millions of customers quickly.
Key Qualifications
You should have a MS or Ph.D. with more than 5 years experience in CPU performance architecture, micro-architecture design, or performance analysis.
Strong CPU architecture knowledge, micro-architecture knowledge, and an understanding of competing architectures
Experience working in a performance modeling environment
Proficient in C and C++
Proficient in scripting languages such as Perl, Python and Ruby
Ability to problem solve and prove your own ideas
Knowledge and experience with common performance benchmarks and workloads
Knowledge of OS internals and compiler technology a plus
Description
- Collaborate with software and system teams to identify and profile critical workloads for CPU performance and power.
- Develop representative benchmarks for CPU critical workloads.
- Capture key workloads for simulation on CPU performance model.
- Identify hardware and software performance bottlenecks. Work closely with Architecture, Micro-Architecture, and RTL team in identification of solutions.
- Run and analyze workloads on simulators and prototype devices as well as work on developing and automating performance analysis infrastructure. 今日も更にお薬増やしておきますね
ID:DECKrUr9 この人の書いていることは概ね正しいんだろうけど、だから何なのかが全くわからない。
前の投稿に書かれている単語から想起する事項を書いているだけで、有り体に言ってbotの会話を見てる気分になる。 いや、ツッコミどころ満載なんだよ。
>>284とか、再帰のフィボナッチ数列は計算律速で
コンパイラ言語は末尾再帰最適化くらいかかっているから関数のオーバーヘッドなんか発生しない
ただおわらんね。これ
> ベンチマークとしての価値はほとんど無いな
> フィボナッチ計算のベンチマークでは関数呼び出しのパフォーマンスぐらいしか測れない
http://blog.shogonir.jp/entry/2018/04/29/121201
> 第2項目の計算が2回行われており、無駄が発生しているのがわかります。
> 今回は図にするため第4項目にしましたが、 n が1増えるたびに計算コストはほぼ倍になっていきます。
> 計算コストが倍々になっていくので、45項目あたりから時間が急激に増えてしまいます。
～
> このように、フィボナッチ数列の定義通りに実装すると計算コストがかかることがわかりました。 今夜も更にお薬増やしておきますね
ID:DECKrUr9 >>289
>コンパイラ言語は末尾再帰最適化くらいかかっているから関数のオーバーヘッドなんか発生しない
さすがに、この程度でブログを踏む気にはなれなかったので、その前提で読むように
「関数のオーバーヘッドが存在しない」ということだが、C言語で確認したところ
gcc/clangのいずれのアセンブラで出力させるてもcallを繰り返し、スタックフレームを積み上げている
clangのバージョンは6.0.0（-Ofast）、gccは8.2(-O3)だ
そのブログで何か違う情報があるなら、コードをそのまま貼り付けるように >>291
繰り返すが、たかが３行を書いただけで長文の過剰反応が続けて３つも来たほうが精神病理学的には興味深い
差し障りもないNetflixのCDNに関する情報提供に対して、アマゾンのAWS営業戦士が過剰反応したのが
発端であるが、こうした無関係な議論にまでエスカレートする必然性はなく「頭がイカレタ」なる称号はAWS営業戦士に送られるべきだろう
クラウドブーム・ハイブリッドクラウドが一巡しAWSが得意とするパブリッククラウド分野が飽和している中で
AWSのソリューションのみに特化した企業も見当たらないわけで、そうするとNetflixがAWSを配信バックエンドで使ってないとの情報で
過剰反応するのはアマゾンの従業員ぐらいだ ×gcc/clangのいずれのアセンブラで出力させるてもcallを繰り返し、スタックフレームを積み上げている
○gcc/clangのいずれでアセンブラ出力させても、callを繰り返しスタックフレームを積み上げている >>292
>>294
付記すると2つの再帰のうち1つはTCOをしているがcallによって関数コールは繰り返す
「関数のオーバーヘッドが存在しない」という文は検証した限りでは誤っている 日本はIT技術者の給料を上げろ。
日本はIT技術者は奴隷じゃないぞ 今朝も更にお薬メガ増やしておきますね
ID:eLboUhL1 当精神病院の入院患者による長文連続書き込みで
ご迷惑をおかけしております。
多重人格障害者のため，自分の書き込みに反論していますが
病気ということで，お許しください。 今夜は落ち着いているようなので、お薬減らしておきますね PHPの代わりにRubyを使おうと思っています ㌧クス。 >>296 確かに安すぎるよな、寝ても覚めても24時間考えてるのに。 ■ このスレッドは過去ログ倉庫に格納されています
