  |
はてなキーワード:GCとは
pixivの百合文芸小説コンテストが久しぶりに開催されることになった。途中で挟まれた百合文芸マンガ原作コンテストをカウントしない場合、3年ぶりの開催となる。
協賛（共催？）社はまたもや変わっており、中でも重要なのはGCノベルズだろう。
今回の百合文芸は「大賞」枠がなくなり、主な賞は「コミック百合姫賞」（両部門合わせて1名）、「GCノベルズ編集部賞」（長編部門より1名）、「特別賞」（両部門合わせて1名）となっている。このうちGCノベルズ編集部賞は書籍化確約を掲げている。
GCノベルズとはどんな所ぞやと調べてみると、代表作としてはあの有名な『転生したらスライムだった件』があるほか、百合作品も『
「人斬り」少女、公爵令嬢の護衛になる』や『「お前ごときが魔王に勝てると思うな」と勇者パーティを追放されたので、王都で気ままに暮らしたい』といったタイトルが刊行されているようだ。最後に挙げた『おまごと』は2026年1月8日からアニメが放送されるということで、百合方面の作品展開には乗り気なタイミングかもしれない。
こうして各賞を俯瞰してみると、今回の対戦環境は①大賞がない、②受賞枠が少なめ、③長編異世界モノの投稿がさらに増えそう、といった点に特徴づけられそうだ。
③はGCノベルズのレーベルカラーから容易に推測できることだ。
GCノベルズの刊行作品はほとんどが異世界モノで、GCノベルズ編集部賞も異世界モノから選ばれる可能性が高い。あだしまやわたなれのような青春ラノベならワンチャンなくもないが、間違っても硬派な歴史モノや純文学が受賞するとは誰も考えていないだろう。
それに加えて百合姫賞の方では第4回で異世界ファンタジーが受賞し長期連載された実績があるので、GCノベルズ編集部賞と百合姫賞の両方を視野に異世界モノを執筆する流れは出てきそうだ。
そして①、②から考えると、いくら文学的に優れた作品や文章の美しい作品を書いても大きな賞は貰えない可能性がある。コミカライズを目指す百合姫賞と書籍化確約のGCノベルズ編集部賞がカバーできる範囲はかなり狭いからだ。
さらに百合姫賞と特別賞は短・中編部門と長編部門の「両部門合わせて」1名。書泉百合部賞は短・中編部門より1名ということで、はっきり言って長編の受賞枠は少ない。また、今回、長編は8万字以上という条件が設けられて応募のハードルが上がっており、総合的に考えると長編部門は「大多数の異世界モノ」と「少数のかなり気合が入った作品」という景色になるだろう。
ぐつぐつと煮詰まったバトルが繰り広げられそうな長編部門、そして長編を断念した者が大量流入するであろう短・中編部門。
ツリーに残っているということは壁が話したことではないってこと
dorawiiより
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20251127171501# -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaSgIhgAKCRBwMdsubs4+SKzjAP45KiJeja9ltZG3lUiRQs8ErvfSce5FKCsbZEoyrSp1PwEAz31wzu1M2ydlsaCDN6mXYkrImadvAxK6g8L5S27e+gc==QSwJ-----ENDPGP SIGNATURE-----
ここでは、以下をすべて加味した総合エコシステム体験スコア を算出します：
含める要素
✅価格・省電力
✅ 独占タイトルの強さ
項目 加点理由
サブスク（PS Plus /PC Game Pass） +2 大量のゲームに触れられる
UHDBlu-ray（映像用途）+1～1.5映画プレイヤーとして唯一性
独占タイトル（FF7R・スパイダーマン等） +2 他で遊べない体験
→総合：13～14.5
② Switch2（総合版）
項目 加点理由
携帯性・遊べる場所の自由度 +3～4 外・旅行・ベッド…体験幅が巨大
独占タイトル（ゼルダ・マリオ・ポケモン等） +3～4世界トップ級のIPパワー
レトロ資産（FC～N64/GB/GBA/GC期待含む）+1.5～3 “時間を超えた価値”
マルチメディア性（映像アプリが弱い） -0.5～-1 非ゲーム用途は弱い
→総合：13～15.5
「映像体験/ハイエンド志向」PS5/PC UHDBD、4K映像、AAA最高品質
「総合ゲーム体験/人生で触る時間」 Switch2携帯性＋任天堂IP＋レトロ資産
★総評
固さが全然いい感じじゃないがな🤪
もっと弱い力でもなめらかに引っ込ませていくことができるもんじゃないとそそられないよね😦
dorawiiより
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20251026165037# -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaP3SzgAKCRBwMdsubs4+SCz2AP0csDRPi7LbMtlG42YlQ744+l5q2RZBvMWsHoS9LusNaQEA67bstUmpJCMEU6Q2nbPJ+BF89Zpq8P7Ivq0A5a+T7AA==M+GC-----ENDPGP SIGNATURE-----
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20251002164056# -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaN4siQAKCRBwMdsubs4+SBjhAP4srJfYDm8RGtcBFA94NieART5pyZiIqN97i8eMEHmDAgEA7vYEr2hZMvI/htOCyh7HvytpROtxi8gQqV8H5wFP+gc==UJ34-----ENDPGP SIGNATURE-----
お前の感想をいくら草とか生やして文字数稼いで書き込んでも発言力が増すわけじゃないからな
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20250916192137# -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaMk6MwAKCRBwMdsubs4+SJB5AP9deWWgeHmb8YOYuJcsi1E3LRKKCCQRUVyexXOtMaMubgEA0YKNrXa9F+gceVd52JlZYhgHOdG7jsJovKEl3eM92g0==yh2S-----ENDPGP SIGNATURE-----
間接的にそこはかとなく馬鹿にしてるね
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20250820192827# -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaKWjTQAKCRBwMdsubs4+SPLXAP9mr7hX46KmJmVJozc2WJG0TQtGcXyjqsQ3VXX656enrQEA8/WdE7kfnYl9peVXF9IcQ+KiID8NPupbfxL/ahoQ+gc==Tvyp-----ENDPGP SIGNATURE-----
最後にレスしたら勝ちみたいなので効いてて草とかで？とか鳴き声レベルでも被せ続ければいいと延々と投稿するようなレスバ気質持ってるのは男限定じゃないか。
-----BEGINPGP SIGNEDMESSAGE-----Hash: SHA512https://anond.hatelabo.jp/20250706184823# -----BEGINPGP SIGNATURE-----iHUEARYKAB0WIQTEe8eLwpVRSViDKR5wMdsubs4+SAUCaGpGZgAKCRBwMdsubs4+SLqzAQCw7aVUCOiZ6kPyVgV3cooYTfr+B+wg5+X7VAzjs3UQvAD+PNuKPOlMPYQSJ2QZW65jmcfzRsKB028VqwZ1DJOgSAM==gc/K-----ENDPGP SIGNATURE-----
https://falsandtru.hatenablog.com/entry/evaluation-items-of-cache-algorithms
キャッシュアルゴリズムには実装可能性(現実的に意味のあるものが実装可能か)が言語に依存するものがある。(W-)TinyLFUはキーをブルームフィルタに変換できなければならないためこの変換コストが高いJavaScriptなどでは低レイテンシな実装が困難となり用途が制限される。またLinked ListはGCの管理により非常に低速となるためARCやLIRSなど履歴保持にLinked Listを使用するキャッシュアルゴリズムはGCなしで実装できる言語かによってレイテンシと適用範囲からのLRUに対する優位性、ひいては有用性が大きく異なる。さらにLinked Listで実装されるLRU自体も同様に低速となるため配列で実装されたClockのほうがLRUより高速となる可能性がありビット演算により高速化されたClockはLRUより高速となる可能性が高い。LRUはJavaScriptにおいて主要というか事実上唯一のキャッシュアルゴリズムだがほとんどの場合より高速なClockに対して何ら優位性がなくGC管理下の遅いLRUを無意味に使い続けているだけである。
2-Quequeアルゴリズムをライトバックキャッシュ目的で実装したときにこれは感じた。
巨大ファイルの全置換えの場合、FIFOであふれたものをそのまま書きだしたほうが早いとかどういうことだよ。
鈴川エディタやEmEditorで少ないメモリー使用量で巨大テキストをファイルを編集できるとうたってるが、.NETでも見事に再現できたぞ。
1.2億行×100文字の全置換えでGCのメモリー使用量は340MB程度で、行の操作は86MB程度、合わせて426MBだ。
その辺の.NET製テキストエディターコンポーネントに組み込んでも500MBぐらいで済むと思う。
（その代わりワークファイルは30GBぐらいは行ってるはず）
鍵はropeというデーター構造を使用することとropeにアクセスする際、ディスクに保存する機構を付け加えるだけだ。
特にソースコードで見るべき個所はBigList.cs、Node.cs、DiskPinableContentDataStore.csの所だけだ。
多少遅くて構わないなら、ディスクに保存することはそこまで難しくはない。
メモリーマップドファイルは何かと面倒なので使ってないが、.NETでMMDataStructuresとかメモリーマップドファイルを扱うやつがあるんで、メモリーマップドファイルでも行けるはずだ。
benchmark start
size:120000000
AllocatedGC Memory:66,304bytes
AllocatedGC Memory:101,257,168bytes
AllocatedGC Memory:101,247,232bytes
AllocatedGC Memory:333,371,424bytes
AllocatedGC Memory:333,257,000bytes
AllocatedGC Memory:331,904,816bytes
clear buffer
AllocatedGC Memory:66,304bytes
AllocatedGC Memory:86,939,136bytes
AllocatedGC Memory:87,272,912bytes
clear buffer
AllocatedGC Memory:69,448bytes
BigListに1.2億行*100文字=12GBのテキストを突っ込んでみた。
文字列操作のタスクマネージャーから見たメモリー使用量は500~900MB程度。
benchmark start
size:120000000
AllocatedGC Memory:66,304bytes
AllocatedGC Memory:101,257,168bytes
AllocatedGC Memory:101,247,232bytes
AllocatedGC Memory:333,371,424bytes
AllocatedGC Memory:333,257,000bytes
AllocatedGC Memory:331,904,816bytes
clear buffer
AllocatedGC Memory:180,072bytes
AllocatedGC Memory:4,916,166,568bytes
AllocatedGC Memory:4,916,146,904bytes
clear buffer
AllocatedGC Memory:172,104bytes
https://github.com/oonyanya/FooList/commit/e795913ef8c8fbd16e59d54048ff68a202ca7c1b
BigListの一部を再帰なしにしたけど、C#の最適化すごいな。
再帰なし。ブランチ rewrite_nonrecursive、Commit 84b25c1
https://github.com/oonyanya/FooList/commit/84b25c172b2f8792ad2d1a645c0b25ff7bf8093d
benchmark start
AllocatedGC Memory:61,240bytes
AllocatedGC Memory:199,685,064bytes
AllocatedGC Memory:199,698,944bytes
AllocatedGC Memory:345,442,528bytes
AllocatedGC Memory:345,442,552bytes
AllocatedGC Memory:345,442,672bytes
clear buffer
AllocatedGC Memory:82,728bytes
AllocatedGC Memory:41,048,400bytes
AllocatedGC Memory:41,048,464bytes
clear buffer
AllocatedGC Memory:82,984bytes
再帰あり
benchmark start
AllocatedGC Memory:60,752bytes
AllocatedGC Memory:199,622,776bytes
AllocatedGC Memory:199,636,920bytes
AllocatedGC Memory:369,227,696bytes
AllocatedGC Memory:369,227,696bytes
AllocatedGC Memory:369,227,840bytes
clear buffer
AllocatedGC Memory:82,728bytes
AllocatedGC Memory:40,996,432bytes
AllocatedGC Memory:40,999,688bytes
clear buffer
AllocatedGC Memory:82,984bytes
この前私とGCの姉さん、経理課の身長152cmのメガネ君と派遣のおっさんの3人で動物園にサウナに行ってきた
サウナを出て動物園のアーケードで飲むかちとせで広島焼きでも手繰るかって話をした
メガネ君と姉さんがそろそろ夏だし花園でガチベトを食べようと言い出した
花園の方に移動して適当なベト飯屋に移動してカエルや豚のガツを食べた
美味しかった
ベトナム料理屋はみんなでワイワイ楽しめるようにたいていカラオケが置いてあるのでみんなで歌を歌って楽しんだ
姉さんが「派遣くんも歌ったら？」って言ったが頑なに拒否してた
C#などコンパクションあり世代別GCを使った場合の話。参照型だとまた話は変わってくる。
http://s170199.ppp.asahi-net.or.jp/vivi/docs/buffer/edit_buffer.php#measure
つらい。
gap_vectorは少し早い。
何だよ。フィナボッチ数列にバランスの取れたノードを放り込んで再構築って。
操作自体はAVL木のリバランスよりははるかに楽だけど、こっちはこっちで訳が分からん。
ただ、テキストの操作はgap_vectorなみにやりやすい。
なお、既存のライブラリーはライセンス的な意味で地雷だったりする。
CPUが違うので参考程度に。
構築速度：gap_vector ＜rope ＜＜＜ list
メモリー使用量：gap_vector ＜rope ＜ list
64、ゲームキューブ、Wii Uは当時から失敗のイメージしかないだろ
SS、PSによる、高性能かつCDによる大容量かつ低価格のゲームが席巻してたのに
PS2、DC時代はGCでようやくROMに移行して頑張るかと思いきや独自のゴミディスクとクソ微妙なコントローラーで完全に失速
調子に乗ってWii Uとかいうどこに需要があるのか分からんゲーム機だして大爆死
一方でゲームボーイ部門はほぼずっと好調で、DSは後にiPhoneを産むパラダイムシフトを起こした傑作
そのあたりの反省とWii Uの反省を踏まえてSwitchで大成功
相当懲りたのかSwitch 2では変なことせずに正統進化してほぼ完成形なので
