BlinkDL:
We don't need attention any more. RWKV-7 "Goose" 🪿 1.5B is coming: SotA base LM at its size, 100% RNN, fully multilingual (100+ languages & code), and honest: no eval-maxxing, no HQ-annealing, no post-training. Release in 3 days. More to come, including reasoning models.
https://twitter.com/BlinkDL_AI/status/1882799092335833396
We don't need attention any more. RWKV-7 "Goose" 🪿 1.5B is coming: SotA base LM at its size, 100% RNN, fully multilingual (100+ languages & code), and honest: no eval-maxxing, no HQ-annealing, no post-training. Release in 3 days. More to come, including reasoning models.
https://twitter.com/BlinkDL_AI/status/1882799092335833396
BlinkDL:
RWKV-7 (9M & 26M params) solving Othello via CoT: github.com/Jellyfish042/R…🙂
https://twitter.com/BlinkDL_AI/status/1876649801632395421
🔥7🥰3🤷♀1🎉1🤮1🐳1🆒1
https://youtu.be/GZPqDvG615k
视频中提到的论文：
Andrew Koenig. Why Are Vectors Efficient. Journal of Object-Oriented Programming, Volume 11, Number 5, September 1998, Page 71-75
https://dblp.org/db/journals/joop/joop11.html#journals/joop/Koenig98f
视频中提到的论文：
Andrew Koenig. Why Are Vectors Efficient. Journal of Object-Oriented Programming, Volume 11, Number 5, September 1998, Page 71-75
https://dblp.org/db/journals/joop/joop11.html#journals/joop/Koenig98f
YouTube
In search of the perfect dynamic array growth factor
This video has a page on 0DE5 with exercises and resources
https://www.0DE5.net/stimuli/in-search-of-the-perfect-dynamic-array-growth-factor
Chapters
00:00 - Intro
03:29 - Golden Ratio
05:11 - 1.5 Factor
07:08 - Lankinen Algorithm
09:53 - Larger simulations…
https://www.0DE5.net/stimuli/in-search-of-the-perfect-dynamic-array-growth-factor
Chapters
00:00 - Intro
03:29 - Golden Ratio
05:11 - 1.5 Factor
07:08 - Lankinen Algorithm
09:53 - Larger simulations…
🔥1
&'a ::rynco::UntitledChannel
https://youtu.be/GZPqDvG615k 视频中提到的论文： Andrew Koenig. Why Are Vectors Efficient. Journal of Object-Oriented Programming, Volume 11, Number 5, September 1998, Page 71-75 https://dblp.org/db/journals/joop/joop11.html#journals/joop/Koenig98f
事实上：
（刚写完在原视频评论区底下发的，懒得自己翻译了，机翻过来作为补充说明）
实际应用和内存分配器比视频中展示的要复杂（也更智能）得多，以至于很多说法都不太适用。
首先，正如视频中提到的，现实世界的应用程序往往同时分配多个数组。使用视频中展示的空闲列表分配器（例如 glibc malloc），不同的重新分配的数组会填补调整大小过程中产生的空隙，所以总体内存使用不会像最初的例子那样糟糕。
此外，许多现代分配器会主动控制和减少内存碎片（分配之间未使用的空隙）。
一些分配器（如 jemalloc 和 mimalloc）有"大小类别" (size class) 的概念，将相似大小的内存分配在一起（浪费一点内存把它们填充到统一大小），而不同大小的分配则完全分开。一个页面可以专门用于分配 481 到 512 字节的内存块，另一个则用于 513 到 640 字节的分配，以此类推。不同大小的数组完全不会相遇，因为它们属于不同的大小类别，而一个页面内的空闲空间会被其他具有相似大小的数组或数据结构的分配所填充（因为它们数量众多）。
其他分配器虽然没有大小类别，但会强制内存分配呈现特定模式以减少碎片，代价是稍微过度分配。伙伴分配（Buddy allocation）是一个著名的技巧，最早出现于 1960 年代，只在预先划分的分区内分配页面内存，如今在 jemalloc 等分配器中仍在使用。其他分配器如 TLSF 则试图将内存分配到最适合的位置，以在受限的内存和时间限制内减少碎片。
对于足够大的内存块分配，例如跨越多个操作系统页面的分配，realloc() 可能就像是将占用的页面重新映射到更大的连续内存地址一样简单。完全不需要复制数据，唯一的变化发生在虚拟地址映射表中，改变虚拟地址指向的物理内存块。
最后，对于使用垃圾回收的语言/分配器，许多垃圾收集器（如用于 V8 JavaScript、JVM、CoreCLR C# 等的收集器）在进行垃圾回收时会主动进行内存压缩，所以内存碎片对它们来说根本不是问题。
这并非否定作者的工作——这是一个很好的方式来可视化和比较内存分配。只是我恰好读过一些这方面的内容，注意到某些说法有点过度简化了 :)
最后，如果你正在自己设计一个动态数组，你大可以根据你对用户扩容频率的预期以及你愿意浪费多少内存，简单地选择 1.5 或 2 作为增长因子，然后让分配器处理剩下的事情。如果你仍然犹豫不决——就选 2 吧。这个选择已经足够好了！
参考资料：
- Glibc malloc 内部实现：https://sourceware.org/glibc/wiki/MallocInternals
- jemalloc 实现说明：http://jemalloc.net/jemalloc.3.html#implementation_notes
- mimalloc：https://microsoft.github.io/mimalloc/index.html
- 伙伴分配：https://en.wikipedia.org/wiki/Buddymemoryallocation
- TLSF：http://www.gii.upv.es/tlsf/files/papers/ecrts04_tlsf.pdf
（刚写完在原视频评论区底下发的，懒得自己翻译了，机翻过来作为补充说明）
实际应用和内存分配器比视频中展示的要复杂（也更智能）得多，以至于很多说法都不太适用。
首先，正如视频中提到的，现实世界的应用程序往往同时分配多个数组。使用视频中展示的空闲列表分配器（例如 glibc malloc），不同的重新分配的数组会填补调整大小过程中产生的空隙，所以总体内存使用不会像最初的例子那样糟糕。
此外，许多现代分配器会主动控制和减少内存碎片（分配之间未使用的空隙）。
一些分配器（如 jemalloc 和 mimalloc）有"大小类别" (size class) 的概念，将相似大小的内存分配在一起（浪费一点内存把它们填充到统一大小），而不同大小的分配则完全分开。一个页面可以专门用于分配 481 到 512 字节的内存块，另一个则用于 513 到 640 字节的分配，以此类推。不同大小的数组完全不会相遇，因为它们属于不同的大小类别，而一个页面内的空闲空间会被其他具有相似大小的数组或数据结构的分配所填充（因为它们数量众多）。
其他分配器虽然没有大小类别，但会强制内存分配呈现特定模式以减少碎片，代价是稍微过度分配。伙伴分配（Buddy allocation）是一个著名的技巧，最早出现于 1960 年代，只在预先划分的分区内分配页面内存，如今在 jemalloc 等分配器中仍在使用。其他分配器如 TLSF 则试图将内存分配到最适合的位置，以在受限的内存和时间限制内减少碎片。
对于足够大的内存块分配，例如跨越多个操作系统页面的分配，realloc() 可能就像是将占用的页面重新映射到更大的连续内存地址一样简单。完全不需要复制数据，唯一的变化发生在虚拟地址映射表中，改变虚拟地址指向的物理内存块。
最后，对于使用垃圾回收的语言/分配器，许多垃圾收集器（如用于 V8 JavaScript、JVM、CoreCLR C# 等的收集器）在进行垃圾回收时会主动进行内存压缩，所以内存碎片对它们来说根本不是问题。
这并非否定作者的工作——这是一个很好的方式来可视化和比较内存分配。只是我恰好读过一些这方面的内容，注意到某些说法有点过度简化了 :)
最后，如果你正在自己设计一个动态数组，你大可以根据你对用户扩容频率的预期以及你愿意浪费多少内存，简单地选择 1.5 或 2 作为增长因子，然后让分配器处理剩下的事情。如果你仍然犹豫不决——就选 2 吧。这个选择已经足够好了！
参考资料：
- Glibc malloc 内部实现：https://sourceware.org/glibc/wiki/MallocInternals
- jemalloc 实现说明：http://jemalloc.net/jemalloc.3.html#implementation_notes
- mimalloc：https://microsoft.github.io/mimalloc/index.html
- 伙伴分配：https://en.wikipedia.org/wiki/Buddymemoryallocation
- TLSF：http://www.gii.upv.es/tlsf/files/papers/ecrts04_tlsf.pdf
🥰8👍3🔥3👻1
Forwarded from Hacker News
Steam Brick: No screen, no controller, just a power button and a USB port (🔥 Score: 150+ in 2 hours)
Link: https://readhacker.news/s/6mS63
Comments: https://readhacker.news/c/6mS63
Link: https://readhacker.news/s/6mS63
Comments: https://readhacker.news/c/6mS63
Steam Brick Mod
No screen, no controller, and absolutely no sense, just a power button and a USB port.
Brick your Steam Deck - one way or another…
👍1
转发给你喜欢听KiLLKiSS的朋友
https://www.bilibili.com/video/BV1Zi6vYiESC
https://www.bilibili.com/video/BV1Zi6vYiESC
Bilibili
转发给你喜欢听KiLLKiSS的朋友_哔哩哔哩_bilibili
参考文献：【转发给你身边喜欢影色舞的朋友】https://www.bilibili.com/video/BV1HGeJeKEWE/, 视频播放量 386394、弹幕量 6171、点赞数 28167、投硬币枚数 3816、收藏人数 10126、转发人数 9350, 视频作者 喝海水梓可, 作者简介 别人都是被推荐，我都是被退件。，相关视频：KiLLKiSS 高松灯 Cover.，【官方live视频】Ave Mujica「KiLLKiSS」（Ave Mujica 4th LIVE「Adventus」）【限…
🤯6