Crunch 是一個由 Felix Winkelmann 創(chuàng)建的新項目，旨在為靜態(tài)類型的 Scheme 子集提供一個高效的編譯器。該編譯器基于 R7RS（?。?biāo)準(zhǔn)，運(yùn)行在 CHICKEN Scheme 系統(tǒng)之上，生成可移植的 C99 代碼，可以在任何擁有良好 C 編譯器的平臺上編譯和執(zhí)行。

為什么需要另一個 Scheme 實現(xiàn)？

盡管已經(jīng)存在大量的 Scheme 解釋器和編譯器，但大多數(shù) Scheme 系統(tǒng)需要復(fù)雜的運(yùn)行時系統(tǒng)，依賴眾多庫，或者性能較慢。Crunch 的目標(biāo)是提供一個小型、便攜的編譯器，生成接近自然的 C 代碼，具有最小的依賴和運(yùn)行時系統(tǒng)，專注于生成高效代碼，即使?fàn)奚艘恍?Scheme 的高級特性。

主要特點

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

使用方式

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

限制

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

未來計劃

Crunch 仍處于 alpha 階段，有許多改進(jìn)空間。未來的計劃包括支持多值返回、更好的可選參數(shù)支持、更多的 POSIX 系統(tǒng)調(diào)用和庫函數(shù)支持等。

評論:

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

小編評語:

Crunch 項目的出現(xiàn)填補(bǔ)了高性能、輕量級 Scheme 編譯器的空白，為嵌入式系統(tǒng)和性能敏感的應(yīng)用提供了新的選擇。盡管目前還有一些限制，但其強(qiáng)大的優(yōu)化能力和模塊化設(shè)計使其具有很大的潛力。期待未來的改進(jìn)和發(fā)展，Crunch 有望成為 Scheme 生態(tài)系統(tǒng)中的一個重要工具。

Valhalla – Java 的史詩重構(gòu)

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

圖片

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

Project Valhalla 已經(jīng)進(jìn)行了 10 年，現(xiàn)在進(jìn)入了最后階段

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

為什么值類如此重要？

值類的引入將極大地簡化 Java 開發(fā)者的代碼編寫和維護(hù)工作。傳統(tǒng)的對象封裝方式會導(dǎo)致大量的內(nèi)存開銷和性能損失，而值類則可以在保持面向?qū)ο缶幊虄?yōu)勢的同時，提供類似基本類型的性能。這對于高性能計算和大規(guī)模應(yīng)用尤為重要。

未來展望

隨著 Project Valhalla 的推進(jìn)，Java 社區(qū)可以期待一個更加現(xiàn)代化和高效的編程環(huán)境。這些改進(jìn)不僅將提升現(xiàn)有應(yīng)用的性能，還將為未來的創(chuàng)新奠定堅實的基礎(chǔ)。

評論:

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

小編評語:

Project Valhalla 的進(jìn)展無疑為 Java 生態(tài)系統(tǒng)帶來了新的活力。值類的引入將使 Java 在性能和內(nèi)存管理方面更加出色，值得所有 Java 開發(fā)者關(guān)注。

Xiaomi Home Integration for Home Assistant

https://github.com/XiaoMi/ha_xiaomi_home

圖片

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

安裝方法

• 終端安裝：

打開終端，進(jìn)入 Home Assistant 配置目錄：cd config

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

進(jìn)入目錄：cd ha_xiaomi_home

安裝：./install.sh /config

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

• HACS 安裝：

進(jìn)入 HACS 設(shè)置，選擇“溢出菜單”中的“自定義倉庫”。

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

支持設(shè)備

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

控制方式

• 云控制：通過小米云服務(wù)實現(xiàn)。
• 本地控制：需要小米中央網(wǎng)關(guān)（固件版本 3.4.0_0000 以上）或內(nèi)置中央網(wǎng)關(guān)的小米設(shè)備（軟件版本 0.8.0 以上）。如果使用的是其他地區(qū)的設(shè)備，建議啟用小米 LAN 控制功能，但需要注意該功能可能引起異常。

評論:

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

Multilspy: 構(gòu)建適用于所有語言服務(wù)器的通用 LSP 客戶端

https://github.com/microsoft/multilspy

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

主要特點

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

使用示例

安裝 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(...)

評論:

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

Veo 2: 先進(jìn)的視頻生成模型

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

圖片

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

主要特點

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

示例視頻

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

評論:

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

小編評語:

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

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 的性能，特別是在多租戶無服務(wù)器環(huán)境中的表現(xiàn)。SQLite 本身已經(jīng)非常快速，但在大規(guī)模應(yīng)用中仍存在一些瓶頸，尤其是在并發(fā)性和多租戶場景下。

主要發(fā)現(xiàn)

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

實驗結(jié)果

實驗?zāi)M了一個多租戶無服務(wù)器運(yùn)行時環(huán)境，每個租戶擁有自己的嵌入式數(shù)據(jù)庫。結(jié)果顯示，Limbo 在 p999 尾部延遲上表現(xiàn)尤為出色，比傳統(tǒng) SQLite 提高了 100 倍。然而，在 p90 和 p99 上，性能提升并不明顯。

評論:

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

小編評語:

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

新技術(shù)大幅降低大語言模型內(nèi)存成本

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

圖片

日本初創(chuàng)公司 Sakana AI 開發(fā)了一種名為“universal transformer memory”的新技術(shù)，能夠顯著降低大語言模型（LLMs）的內(nèi)存使用成本。這項技術(shù)利用神經(jīng)網(wǎng)絡(luò)優(yōu)化 LLMs，使其能夠保留重要信息并丟棄冗余細(xì)節(jié)，從而在保持性能的同時減少內(nèi)存占用。

技術(shù)原理

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

實驗結(jié)果

研究人員在 Meta Llama 3-8B 模型上測試了 NAMMs，結(jié)果顯示，使用 NAMMs 后，模型在自然語言和編碼任務(wù)上的性能有所提升，同時節(jié)省了高達(dá) 75% 的緩存內(nèi)存。此外，NAMMs 還能在不同模態(tài)的任務(wù)中保持優(yōu)勢，例如計算機(jī)視覺和強(qiáng)化學(xué)習(xí)。

任務(wù)依賴行為

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

評論:

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