作者: oopFoo (3d) 2024年在 PTT 的推文記錄
※ 選擇年份: 所有年份(543) 2024年(59) 2023年(175) 2022年(128) 2021年(150) 2020年(21) 2019年(4) 2018年(6)
※ 選擇看板: 所有看板(59) PC_Shopping(39)
第3頁 第2頁 第1頁
※ 選擇看板: 所有看板(59) PC_Shopping(39)
第3頁 第2頁 第1頁
2024年第59篇~第41篇
- 推 : npu主要是筆電用的，能效比高。桌上型npu就比較不重要。主要還是微軟主導，不然gpu一直加上去還比較合理。微軟要copilot在背景一直跑，所以才需要npu。 98F 36.224.209.165 09-27 09:38推 : 是這樣沒錯，反正amd的桌面也沒有，就先把 105F 36.224.209.165 09-27 09:50… 共有 6 則推文，點此顯示
- → : nb_shopping，前幾天一堆人扼腕錯過特價。今天不要錯過了。 1F 58.114.66.74 09-18 20:04→ : 花錢版好可怕，限量一台還是一下子掃光 14F 58.114.66.74 09-18 20:58
- → : 就成本壓最低。市場完全不會升級的一堆。現在調回原價了。不過應該很快能等再降價 27F 114.45.129.8 09-16 12:18
- 推 : 希望新去處更好 5F 09-01 09:55
- → : 不是製程問題，雖然是出廠即灰燼，但真的就是電壓在某些情況請求不正確，導致過高這個是intel的微碼bug
反正現在延保，有問題趕快rma。 14F 58.114.66.74 08-08 21:34→ : 有問題就RMA啊。Intel已經說氧化的有盡量 24F 58.114.66.74 08-08 21:44… 共有 7 則推文，點此顯示 - 推 : 多核效能低下，是很奇怪。聽說bios拼命更 5F 58.114.66.74 08-07 22:02→ : 新。也許MT還有提昇空間。 8F 58.114.66.74 08-07 22:03→ : 看techpowerup，pbo也提昇有限。 17F 58.114.66.74 08-07 22:04→ : 應該不是積熱，這代散熱功耗，好很多。 21F 58.114.66.74 08-07 22:06… 共有 6 則推文，點此顯示
![]()
- → : 縮缸的是ringbus，所以限制電壓不要超過ringbus可承受的範圍，後面就沒事了。 2F 58.114.66.74 08-02 22:14→ : LunarLake是gg的n3，記憶體黏的方法跟蘋果方法是一樣的。LunarLake是單soc所以沒膠水問題。15代ARL也是幾乎全部GG製程，膠水 27F 36.224.243.196 08-03 11:19… 共有 10 則推文，點此顯示
- → : 外勤人員是辦公室的，跟製程關係不大。
Pat是太相信元Intel Fab的人可以把良率搞定。不知現在的Intel Fab已不是他當初知道的Intel FAB。所以這次痛下決心，請外人來整頓。 38F 111.248.88.105 08-02 10:22… 共有 13 則推文，點此顯示 - 推 : 筆電的cpu功耗最重要。現在分成兩個ccx，一個是lowish power island，平常就用這個高功耗的ccx可以關掉。你串在一起無法關掉省電。ringbus很耗電的。上一代的反應不好就是功耗降不下來。這個跟MTL的lpe有點像 12F 36.224.200.235 07-31 12:39… 共有 7 則推文，點此顯示
- → : 跟infinity fabric，latency無關。
我當然懂了，寫3d程式20年以上了。 8F 111.248.88.105 07-31 09:57→ : 現代的高效能多線序程式是gpu-like。跟以前的想法差異很大。但這講起來不是一兩篇講的完的。而且也不是這裡大多數的人能了 40F 36.224.200.235 07-31 12:45… 共有 6 則推文，點此顯示 - 推 : 謝謝馬修大 274F 07-26 12:19
- → : Linux Kernel就是很好的敏捷案例。APTON大的"安燈系統"比我剛才想打的一串的好，精簡清楚。 11F 07-26 13:29→ : (顧客，pm，主管）決定功能，工程師決定時間與作法。
不過夢想很豐滿，現實很骨感。當壓力來的時候，加班，壓時間，各種非敏捷的作法通通上來，能夠徹底執行敏捷的團隊還 46F 07-26 19:35… 共有 43 則推文，點此顯示 - → : 就出廠即灰燼。我現在都建議限制power在230w左右。 2F 58.114.66.74 07-25 08:52
- → : 現在對AI的期待太高了，AI是好用，但有它的侷限。
就像5年前的AI自駕，吹太高了，如果當初簡單
開始，只專注高速公路，也許現在早就有普及的自駕 49F 07-22 06:33→ : 問題是，要減少誤差，你需要多多少資料？減半是需要 82F 07-22 13:30→ : 多50%?多2x?3x?4x?。這幾個model都是用約40年的資料 84F 07-22 13:32… 共有 6 則推文，點此顯示 - → : dotNet也只能用wasm的byteCode，JIT都需要wasm的vm處理，主要是wasm的vm優化不足，c#的compiler的frontEnd在wasm也算是簡易沒優化的。wasm的c#應該不是vm inside vm，
wasm的限制很多，例如只有32bit，只有4GB的memory。vm的byteCode也是極精簡，不像java/dotNet。很多地方都需要再 8F 07-07 02:12… 共有 11 則推文，點此顯示 - → : 現在還有人推NoSQL?99%的情況選Sql才對吧。這篇重點沒抓到 10F 07-02 06:11
- 推 : 你知道wasm跟js是怎麼互相call？資料怎麼傳？你這個要搞清楚。wasmGC是用來解決一部份這類的問題。wasm你需要管理記憶體，不然光是copy就吃掉一堆效能。而且wasm的compiler本來就比java/c#差很多，效能差是正常的。所以不用c/c++或直接wasm assembly，還要規劃好資料的傳遞，不然根本直接 6F 07-02 06:17… 共有 14 則推文，點此顯示
- 推 : 往高頻走，只能camm了。 13F 58.114.66.74 06-14 07:42推 : 普通人都是一次買齊記憶體，很少人是中途才加上去的。而且中途加，相容性更差，幾乎都是建議全換。所以只有一根不是問題。camm2真的是大福音，相容性問題大大減少 23F 114.45.169.156 06-14 09:06
- 推 : 這是window的鍋，基本上出問題的是opengl遊戲。window的opengl沒有把正確的解析度給遊戲。window的opengl dll很老了，完全沒修正。這個要怪微軟。 11F 111.248.98.94 06-07 09:33推 : 一些很老的dx遊戲也是有受影響。這些如果 18F 111.248.98.94 06-07 11:27… 共有 10 則推文，點此顯示
點此顯示第2頁