Crunch 是一個由 Felix Winkelmann 創建的新項目，旨在為靜態類型的 Scheme 子集提供一個高效的編譯器。該編譯器基于 R7RS（小）標準，運行在 CHICKEN Scheme 系統之上，生成可移植的 C99 代碼，可以在任何擁有良好 C 編譯器的平臺上編譯和執行。

為什么需要另一個 Scheme 實現？

盡管已經存在大量的 Scheme 解釋器和編譯器，但大多數 Scheme 系統需要復雜的運行時系統，依賴眾多庫，或者性能較慢。Crunch 的目標是提供一個小型、便攜的編譯器，生成接近自然的 C 代碼，具有最小的依賴和運行時系統，專注于生成高效代碼，即使犧牲了一些 Scheme 的高級特性。

主要特點

• 高效編譯：Crunch 生成的代碼性能高，適用于編寫游戲、虛擬機、性能敏感的庫等。
• 嵌入式系統支持：Crunch 適合用于編寫裸機代碼、設備驅動程序和操作系統內核。
• 類型推斷：使用類型推斷，避免了大部分類型注解，使代碼保持簡潔。
• 模塊化：支持 CHICKEN 的模塊系統和宏，可以無縫集成到現有的 CHICKEN 項目中。
• 優化：提供了多種優化技術，如單態化、內聯、循環優化等，確保生成的 C 代碼緊湊且高效。

使用方式

• 嵌入：在 CHICKEN Scheme 程序中嵌入靜態類型代碼片段。
• 獨立程序：將 Scheme 代碼編譯為獨立的 C 程序。
• 包裝編譯代碼：生成 Scheme 包裝器，以便在 CHICKEN 中使用編譯后的 C 代碼。
• 庫模式：作為庫函數使用，將 Scheme 代碼動態轉換為原生代碼。

限制

Crunch 有一些顯著的限制，例如不支持多值返回、一級續體、尾遞歸優化等。但這些限制并不妨礙大量典型的 Scheme 代碼的編譯。

未來計劃

Crunch 仍處于 alpha 階段，有許多改進空間。未來的計劃包括支持多值返回、更好的可選參數支持、更多的 POSIX 系統調用和庫函數支持等。

評論:

• 網友 davexunit：很高興看到更多探索靜態編譯 Scheme 的項目。Crunch 與 PreScheme 的最大區別之一是手動內存管理與引用計數的不同。
• 網友 nudpiedo：如果我理解正確，Crunch 可以讓 Scheme 在 ESP32 等微控制器上運行，對吧？它的體積小巧，也非常適合編譯為 TypeScript/Deno/WASM，同時保留 s-expr 的強大功能和運行時可能性。

小編評語:

Crunch 項目的出現填補了高性能、輕量級 Scheme 編譯器的空白，為嵌入式系統和性能敏感的應用提供了新的選擇。盡管目前還有一些限制，但其強大的優化能力和模塊化設計使其具有很大的潛力。期待未來的改進和發展，Crunch 有望成為 Scheme 生態系統中的一個重要工具。

Valhalla – Java 的史詩重構

https://inside.java/2024/12/16/devoxxbelgium-valhalla/

圖片

Java 語言架構師 Brian Goetz 在 Devoxx 2024 大會上詳細介紹了 Project Valhalla 的最新進展。這一項目旨在彌合 Java 類型系統中類和基本類型的裂痕，通過引入值類（value classes）實現這一目標。值類的特點是“編碼像類一樣，工作像 int 一樣”，并且提供扁平且密集的內存布局。

Project Valhalla 已經進行了 10 年，現在進入了最后階段

除了值類，該項目還引入了無空限制類型（null-restricted types）、增強的確定賦值分析（beefed up definite assignment analysis）和嚴格的初始化（strict initialization）。這些改進將使 Java 的類型系統更加一致和高效。

為什么值類如此重要？

值類的引入將極大地簡化 Java 開發者的代碼編寫和維護工作。傳統的對象封裝方式會導致大量的內存開銷和性能損失，而值類則可以在保持面向對象編程優勢的同時，提供類似基本類型的性能。這對于高性能計算和大規模應用尤為重要。

未來展望

隨著 Project Valhalla 的推進，Java 社區可以期待一個更加現代化和高效的編程環境。這些改進不僅將提升現有應用的性能，還將為未來的創新奠定堅實的基礎。

評論:

• 網友 thunderbong：項目 Valhalla 的進展令人興奮，特別是值類的引入，這將徹底改變 Java 的類型系統，期待早日見到正式發布！
• 網友 coder_john：值類的引入確實是一個重大突破，但我也希望 Java 能夠繼續保持向后兼容性，畢竟很多企業還在使用較老的版本。

小編評語:

Project Valhalla 的進展無疑為 Java 生態系統帶來了新的活力。值類的引入將使 Java 在性能和內存管理方面更加出色，值得所有 Java 開發者關注。

Xiaomi Home Integration for Home Assistant

https://github.com/XiaoMi/ha_xiaomi_home

圖片

小米官方發布了 Xiaomi Home Integration，這是一個支持 Home Assistant 的集成組件，允許用戶在 Home Assistant 中使用小米 IoT 智能設備。此集成組件要求 Home Assistant 版本為 Core ≥ 2024.11.0，操作系統版本 ≥ 13.0。

安裝方法

• 終端安裝：

打開終端，進入 Home Assistant 配置目錄：cd config

克隆倉庫：git clone https://github.com/XiaoMi/ha_xiaomi_home.git

進入目錄：cd ha_xiaomi_home

安裝：./install.sh /config

更新到特定版本（例如 v1.0.0）：git checkout v1.0.0，然后重新運行安裝腳本：./install.sh /config

• HACS 安裝：

進入 HACS 設置，選擇“溢出菜單”中的“自定義倉庫”。

輸入倉庫地址：https://github.com/XiaoMi/ha_xiaomi_home.git，類別選擇“Integration”，然后點擊“添加”。

支持設備

小米 Home Integration 支持大多數小米智能家居設備，但不支持藍牙設備、紅外設備和虛擬設備。它支持多賬戶登錄，并允許不同賬戶的設備添加到同一區域。

控制方式

• 云控制：通過小米云服務實現。
• 本地控制：需要小米中央網關（固件版本 3.4.0_0000 以上）或內置中央網關的小米設備（軟件版本 0.8.0 以上）。如果使用的是其他地區的設備，建議啟用小米 LAN 控制功能，但需要注意該功能可能引起異常。

評論:

• 網友 WaitWaitWha：我認為這不是真正的 Home Assistant 集成，因為它仍然依賴小米云服務。真正的集成應該是所有活動都在 Home Assistant 內部完成。
• 網友 Someone1234：小米增加對 Home Assistant 的支持，前提是可靠的話，確實提升了他們的產品競爭力。
• 網友 gpi：希望未來能有更多本地支持，減少對小米云的依賴。
• 網友 nevi-me：終于等到了小米的 Home Assistant 集成，我家里有幾盞小米燈泡，一直沒能集成到 Home Assistant，現在終于可以嘗試了。
• 網友 seanvelasco：低檔的中國手機品牌，如小米和華為，會在系統應用中顯示廣告。希望智能家居設備不會走上這條路。
• 網友 pammf：我只會在需要混合不同廠商設備或廠商應用有局限時使用 Home Assistant。否則，我會直接使用廠商提供的應用。

Multilspy: 構建適用于所有語言服務器的通用 LSP 客戶端

https://github.com/microsoft/multilspy

Multilspy 是一個由微軟開發的庫，旨在簡化創建語言服務器客戶端的過程，以便查詢和獲取各種靜態分析結果。該項目是作為 NeurIPS 2023 論文 "Monitor-Guided Decoding of Code LMs with Static Analysis of Repository Context" 的一部分開發的。論文介紹了 Monitor-Guided Decoding (MGD)，這是一種使用靜態分析指導代碼生成的方法，確保生成的代碼符合各種正確性屬性，如符號名稱的準確性、方法調用的順序等。

主要特點

• 跨平臺：支持多種編程語言，包括 Java、Rust、C# 和 Python。
• 簡化使用：自動處理平臺特定的服務器二進制文件下載、設置/拆除語言服務器、JSON-RPC 通信、維護和傳遞手調優的服務器和語言特定配置參數。
• 簡單 API：用戶可以通過簡單的 API 執行各種靜態分析請求，如查找函數定義、引用、類型完成、懸停信息等。

使用示例

安裝 multilspy 后，可以通過以下代碼示例來使用它：

from multilspy import SyncLanguageServer
from multilspy.multilspy_config import MultilspyConfig
from multilspy.multilspy_logger import MultilspyLogger

config = MultilspyConfig.from_dict({"code_language": "java"})
logger = MultilspyLogger()
lsp = SyncLanguageServer.create(config, logger, "/abs/path/to/project/root/")

with lsp.start_server():
    result = lsp.request_definition("relative/path/to/code_file.java", 163, 4)
    result2 = lsp.request_completions(...)
    result3 = lsp.request_references(...)
    result4 = lsp.request_document_symbols(...)
    result5 = lsp.request_hover(...)

評論:

• 網友 lukax：有趣的是，他們使用了 Jedi Language Server 作為 Python 的語言服務器，而不是微軟自己的 Pylance（Pylance 僅限于 Microsoft 產品的官方構建中使用）。
• 網友 LakshyAAAgrawal：我是 Monitor-Guided Decoding 的作者，這是一個確保 LLM 生成代碼時能夠獲得與人類編碼者相同的反饋（如自動完成、函數簽名、函數參數數量、代碼庫中可用的各種 API 名稱等）的技術。然而，構建這樣的技術需要一種語言無關的方式來接口各種語言特定的靜態分析和索引功能。Language Server Protocol (LSP) 正好適合這個需求！
• 網友 antmarti：作為語言服務器的主要維護者，我們依賴社區貢獻來支持其他編輯器（如 NeoVim、Atom、Rider 等）。這些信息分散且容易過時，手動步驟也很多。希望 multilspy 能夠提供一個集中管理不同語言服務器配置的倉庫，這對社區來說將是一個巨大的幫助。
• 網友 PLenz：作為一個語言服務器實現者，我非常愿意為 multilspy 添加我的配置，這將有助于提高整個生態系統的互操作性和穩定性。

Veo 2: 先進的視頻生成模型

https://deepmind.google/technologies/veo/veo-2/

圖片

Veo 2 是 DeepMind 推出的最新視頻生成模型，能夠在保持高分辨率（最高可達 4K）的同時生成逼真的視頻內容。該模型不僅能夠忠實執行簡單的指令，還能模擬復雜的物理現象和多種視覺風格，提供廣泛的相機控制選項，從而創造出多樣化的拍攝角度和運動效果。

主要特點

• 增強的現實感和保真度：Veo 2 在細節、真實感和減少偽影方面顯著優于其他 AI 視頻生成模型。
• 高級運動能力：通過理解物理原理和精確執行詳細指令，Veo 2 能夠高度準確地表示運動。
• 更多的相機控制選項：能夠精確解釋指令，創建各種鏡頭風格、角度和運動組合。
• 卓越的表現：在人類評估中，Veo 2 在整體偏好和準確跟隨指令方面表現出色。

示例視頻

• 低角度跟蹤鏡頭：一輛橄欖綠的肌肉車在城市燈光下漂移，輪胎煙霧和光暈效果營造出強烈的視覺沖擊力。
• 冰上芭蕾：一位穿著白色長裙的滑冰者在云層中優雅地滑行，背景是夢幻般的色彩和柔和的云朵。
• 海灘上的狗：一只可愛的達克斯獵犬戴著游泳護目鏡跳入清澈的泳池，水下的動態畫面充滿活力。

評論:

• 網友 simonw：我嘗試了預覽功能，生成的視頻非常有趣。特別是“一只鵜鶘騎自行車沿海岸小路行駛”的場景，四個版本中有兩個完美實現了這一場景。
• 網友 sigmar：Veo 2 在用戶偏好測試中以 2:1 的比例擊敗了 Sora Turbo，雖然兩者在自然運動和物理模擬方面仍有相似的局限性，但 Veo 2 略勝一籌。
• 網友 lukol：上次 Google 發布 Gemini 時，OpenAI 很快推出了 Sora 預覽版。這次 Veo 2 看起來比 Sora 更進一步，感覺像是一個反擊。
• 網友 fernly：盡管這些視頻看起來很酷，但目前還無法用于制作連貫的電影或廣告，因為保持復雜場景中的連續性仍然是一個挑戰。

小編評語:

Veo 2 的推出標志著視頻生成技術的重大進步。雖然在處理復雜場景時仍有一些局限，但其在細節和真實感方面的表現令人印象深刻。隨著技術的不斷改進，未來生成的視頻可能會更加逼真，甚至難以與真實視頻區分。這對于視頻創作者來說無疑是一個巨大的福音，但也帶來了倫理和安全方面的挑戰。希望科技公司在推進技術的同時，能夠充分考慮這些潛在的風險。

In Search of a Faster SQLite

https://avi.im/blag/2024/faster-sqlite/

研究人員在《Serverless Runtime / Database Co-Design With Asynchronous I/O》論文中探討了如何通過異步 I/O 和存儲分離來顯著提升 SQLite 的性能，特別是在多租戶無服務器環境中的表現。SQLite 本身已經非常快速，但在大規模應用中仍存在一些瓶頸，尤其是在并發性和多租戶場景下。

主要發現

• 異步 I/O 的優勢：通過使用 io_uring，應用程序可以在 I/O 請求提交后繼續執行其他任務，從而提高了并發性和資源利用率。
• 存儲分離：將查詢引擎和存儲引擎解耦，進一步減少了延遲。
• Limbo 項目：研究人員使用 Rust 重寫了 SQLite，稱為 Limbo，實現了高達 100 倍的尾部延遲減少。

實驗結果

實驗模擬了一個多租戶無服務器運行時環境，每個租戶擁有自己的嵌入式數據庫。結果顯示，Limbo 在 p999 尾部延遲上表現尤為出色，比傳統 SQLite 提高了 100 倍。然而，在 p90 和 p99 上，性能提升并不明顯。

評論:

• 網友 efitz：這篇文章討論了無服務器計算（如 AWS Lambda）中中央數據庫的局限性。我在 6-7 年前遇到過類似的問題，通過將數據加載到 SQLite 數據庫并存儲在 S3 中，成功解決了這一問題。這種方法不僅速度快，而且避免了重復工作。
• 網友 scheme271：SQLite 的一大優點是其廣泛的測試套件。問題是，Limbo 是否也有類似的測試套件？特別是如果它使用了像 io_uring 這樣快速但難以編寫且容易出錯的功能。
• 網友 samwillis：這是一篇很棒的文章。之前有人嘗試為 PostgreSQL 帶來異步 I/O，但后來停滯了。最近的提案是允許交換存儲管理器，而無需分叉代碼庫。這使得許多 PostgreSQL 組織都能受益。

小編評語:

SQLite 作為輕量級數據庫的代表，已經在眾多應用場景中證明了自己的價值。然而，隨著無服務器計算的興起，傳統的同步 I/O 成為了性能瓶頸。Limbo 項目通過引入異步 I/O 和存儲分離，為這一問題提供了一個全新的解決方案。雖然在某些情況下性能提升有限，但在極端負載下的表現令人印象深刻。未來，我們可以期待更多類似的優化技術，進一步推動數據庫技術的發展。

新技術大幅降低大語言模型內存成本

https://venturebeat.com/ai/new-llm-optimization-technique-slashes-memory-costs-up-to-75/

圖片

日本初創公司 Sakana AI 開發了一種名為“universal transformer memory”的新技術，能夠顯著降低大語言模型（LLMs）的內存使用成本。這項技術利用神經網絡優化 LLMs，使其能夠保留重要信息并丟棄冗余細節，從而在保持性能的同時減少內存占用。

技術原理

• Transformer 模型的響應依賴于其“context window”，即模型接收的用戶輸入內容。優化 context window 的內容可以顯著提升模型性能，這一領域被稱為“prompt engineering”。然而，較長的 prompt 會導致更高的計算成本和較慢的性能。
• Sakana AI 的 NAMMs（neural attention memory models） 通過決定是否“記住”或“忘記”每個 token 來優化 prompt，從而減少不必要的 token 數量，提高速度并降低成本。

實驗結果

研究人員在 Meta Llama 3-8B 模型上測試了 NAMMs，結果顯示，使用 NAMMs 后，模型在自然語言和編碼任務上的性能有所提升，同時節省了高達 75% 的緩存內存。此外，NAMMs 還能在不同模態的任務中保持優勢，例如計算機視覺和強化學習。

任務依賴行為

• NAMMs 能夠根據任務自動調整行為。例如，在編碼任務中，模型會丟棄不影響代碼執行的注釋和空白字符；而在自然語言任務中，則會丟棄不影響序列意義的語法冗余部分。

評論:

• 網友 vlovich123：這項技術與微軟的 HeadKV 論文相比如何？后者聲稱可以減少 98% 的內存占用，同時保持 97% 的性能。
• 網友 odyssey7：經過幾年的算法和硬件優化，未來是否會出現不再需要大量核電站來滿足 AI 數據中心電力需求的情況？
• 網友 solarkraft：令人難以置信的是，現在的語言模型可以在我的中高端筆記本電腦上流暢運行，這在幾年前是不可想象的。
• 網友 iandanforth：這表明大型模型已經知道哪些信息是有用的，哪些是無用的，非常有趣。
• 網友 lawlessone：這就像是 prompt 的垃圾回收器，非常實用。