[過去ﾛｸﾞ] Go language part 5 (1002ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
52: デフォルトの名無しさん [sage] 2022/03/02(水) 00:08:09.90 ID:A3d3IcmJ(1/3) AAS
>>46
了解。では感想だけ。
今時はグラフはsvgで作るのかーとちょっと驚いた。ググったら結構あるみたいだけどさ。まあそれはさておき、
> f(x) = 2.6396 x + 1186.8
完全にリニアで、2kBはスタックとして、残り0.6はちと多い。G構造体は以下(前スレ805内のリンク内)
https://github.com/golang/go/blob/master/src/runtime/runtime2.go#L403-L498
にあるが、51個もメンバがある巨大構造体で、こんなに必要なのか？とは思う。
まあ「税金」として0.6kBかかるのなら、無理にスタックを1kBにケチる意味はないから、デフォ2kBは妥当な判断に見える。
これについてはlinuxと比較しないと妥当性は検討出来ないが、
妥当性を検討するためにはLinuxを見る必要がある。これは同様に(前スレ805内の記事11章)以下にある。
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/sched.h#n657
見た目goよりでかいし、ifdefが多すぎて数える気にすらならない。
とはいえlinuxのはプロセスと共用だし、そもそも大量に起動する用途向けではないので多少大きくても問題ない。
おそらくあれこれ機能を足していくうちに肥大化したのだろうとは思う。
ただこれに対抗するならgoのはでかすぎ。
10倍起動するつもりなら、サイズは1/10に抑えないと並べない。(今は多分数分の一程度)
JSはここら辺はただのFIFOで、1ジョブ当たりポインタ数個分で実装出来る程度の機能しかない。だから速い。
Goのも既に肥大化しすぎてる。
ちょっと考えてみ？600Bytes=ポインタ*75個分で、一体何の制御をしたらそんなに必要なのかと。
51個のメンバがある＝起動/停止時にその51個のメンバをチェック/更新するコードを通す事になる
＝起動/停止時に「税金」的に数百サイクルは必要、となる。
101: デフォルトの名無しさん [sage] 2022/03/04(金) 17:03:59.90 ID:k6Ka/u1X(1) AAS
>>100
>>96
175: デフォルトの名無しさん [sage] 2022/03/11(金) 14:45:54.90 ID:laeBnhbM(1) AAS
Dust信者暴れないでください
209: デフォルトの名無しさん [sage] 2022/03/12(土) 12:59:10.90 ID:6Ov0/1Y8(1) AAS
荒らしまくるRusterと不愉快仲間たち
250: デフォルトの名無しさん [sage] 2022/04/01(金) 21:03:43.90 ID:Nf7Dhk5p(2/2) AAS
map/reduce/filterみたいな操作をたくさんするとき、マジで面倒だったしジェネリクスあればいろんな場面で助かる
308: デフォルトの名無しさん [sage] 2022/04/30(土) 04:35:01.90 ID:JVPX2fHb(1) AAS
ほしゆ(・ω・)
434: デフォルトの名無しさん [sage] 2022/06/26(日) 19:36:20.90 ID:n40xbeTi(1/2) AAS
モックって何使ってる？
gomock, testfy, mockery
オススメは？
587(1): デフォルトの名無しさん [sage] 2022/09/06(火) 00:56:32.90 ID:jgCBXC4T(1) AAS
ヒント:httpは同期通信
673(1): デフォルトの名無しさん [sage] 2022/10/14(金) 19:27:35.90 ID:BY1P2csp(1) AAS
Googleのたかが1プロジェクトが C++で始まるからと言ってGoの終わりを感じ始めるなんてどういう審美眼で生きてんだよ。
874(1): デフォルトの名無しさん [sage] 2025/05/17(土) 21:51:30.90 ID:4wFqfo1S(1) AAS
Goも別にC/C++ほどにはプログラマを信用してないと思うけどな
GCはあるし、変数は必ず初期化されるし、ポインタへの算術演算も禁止してるし
そもそもCの置き換えを目指すような低レイヤーを扱う言語じゃないので
894(1): デフォルトの名無しさん [sage] 2025/05/18(日) 14:05:05.90 ID:eaOArS/2(3/12) AAS
>>892
呆れた
表層的知識でPromiseの理解と実装をできないからそんな勘違いを犯すんだな
JavaScriptならasync/awaitはPromiseのシンタックスシュガーだ
Promiseを作って返したらそのままasync対応したことになるのが一番の基礎だぞ
907: デフォルトの名無しさん [sage] 2025/05/18(日) 16:10:19.90 ID:eaOArS/2(8/12) AAS
>>906
なんだ少しは理解してるじゃないか
言語の中でepollなどでイベントループを抱え込んでいてそれがPromiseもasyncも無い大昔からJavaScriptは同じ
つまりasync/awaitなんか関係なく初めからイベントループを内蔵している
これはWebブラウザという無数に非同期タスクが飛び交う必要性からその仕様となった
そのためC#などより早く非同期タスクが実現されてきた
そのためC#などようなステートマシン変換なんか必要とせずに単なるシンタックスシュガーだけでasync/awaitも導入できている
920(2): デフォルトの名無しさん [] 2025/05/19(月) 00:01:41.90 ID:M5liwQEO(1/2) AAS
Goの話しろよ…
横から少し突っ込むと、 >>915 が言ってるのは>>912にある「シンタックスシュガー」について、その糖衣構文が実際には何を行っているのかが分かっているか？ということ
C#でもRustでも、ユーザー側のコードにはステートマシンは出てこないけど、async関数はステートマシンに変換されてる (だから await の前にある変数をそのまま参照できる)
これはJSでも同じ
>>918 についていえば言語の仕様の違いなので仕方ない
JSではsleepみたいにブロックする関数 (CPUを使うような仕事ではないのに待たされる関数) はどうしようも無い
C#だとそれを逃がす方法 (Task.Run) もあるけど、これはスレッドプールと関係するから、シングルスレッドのJSだと使えない
いずれにせよGoと関係なさすぎ
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.194s*