作者查詢 / oopFoo
作者 oopFoo 在 PTT 全部看板的留言(推文), 共7282則
限定看板:全部
看板排序:
全部PC_Shopping4013home-sale1200Soft_Job1064Stock230GameDesign229Emulator217Steam102C_Chat32nb-shopping31Oversea_Job19Lifeismoney18nCoV201918MobileComm15Tech_Job15Military12cat11HatePolitics10TY_Research7WorkinChina7Printer3D6PlayStation5AI_Art4Gossiping4Old-Games3Test3DigiCurrency2TWSU2car1Digital_Art1Storage_Zone1<< 收起看板(30)
6F推: 你知道wasm跟js是怎麼互相call?資料怎麼傳?你這個要搞清07/02 06:17
7F→: 楚。wasmGC是用來解決一部份這類的問題。wasm你需要管理07/02 06:19
8F→: 記憶體,不然光是copy就吃掉一堆效能。而且wasm的compiler07/02 06:20
9F→: 本來就比java/c#差很多,效能差是正常的。所以不用c/c++或07/02 06:22
10F→: 直接wasm assembly,還要規劃好資料的傳遞,不然根本直接07/02 06:24
11F→: js+typedarray就好了。07/02 06:25
12F推: js的效能是非常好的,不要有錯誤的觀念。所以除非你的07/02 06:35
13F→: wasm程式規劃的很好,不然比js差是正常的。c#除非移植到07/02 06:36
14F→: wasmGC,不然高效能是很難的。07/02 06:38
15F→: https://web.dev/case-studies/google-sheets-wasmgc07/02 06:39
17F推: webgl/glsl來跑lanczos是最快,最簡單,相容性最好的方法07/02 06:46
18F→: webgl/glsl處理影像容易,程式也容易,只是入門難而已。07/02 06:47
19F推: https://stackoverflow.com/questions/5429945707/02 06:58
20F→: 從這篇追回去,你大概就知道怎麼做了07/02 06:59
10F→: 現在還有人推NoSQL?99%的情況選Sql才對吧。這篇重點沒抓到07/02 06:11
14F推: 辛苦了!!生日快樂!!06/20 11:57
16F推: 感謝58.114.66.74 06/18 20:06
35F推: tomshardware報導intel回覆說還沒找到真正36.224.239.145 06/15 13:54
38F→: root cause。這個microcode上個月就有了,36.224.239.145 06/15 13:55
39F→: 當時就聽說還是沒有完全解決問題。36.224.239.145 06/15 13:57
13F推: 往高頻走,只能camm了。58.114.66.74 06/14 07:42
23F推: 普通人都是一次買齊記憶體,很少人是中途114.45.169.156 06/14 09:06
24F→: 才加上去的。而且中途加,相容性更差,幾114.45.169.156 06/14 09:07
25F→: 乎都是建議全換。所以只有一根不是問題。114.45.169.156 06/14 09:07
26F→: camm2真的是大福音,相容性問題大大減少114.45.169.156 06/14 09:08
35F推: 推,坐等後續。58.114.66.74 06/12 19:47
14F→: Hetzner的egress比AWS便宜多多,這家是拼58.114.66.74 06/07 19:30
15F→: 價錢58.114.66.74 06/07 19:30
30F→: 20A本來就是過渡製程。18A才是主力,就像58.114.66.74 06/08 05:57
31F→: Intel 3才是主力,Intel 4只是過渡。現在58.114.66.74 06/08 05:58
32F→: Intel 4也差不多要停產了,全力產Intel 358.114.66.74 06/08 06:03
11F推: 這是window的鍋,基本上出問題的是opengl111.248.98.94 06/07 09:33
12F→: 遊戲。window的opengl沒有把正確的解析度111.248.98.94 06/07 09:34
13F→: 給遊戲。window的opengl dll很老了,完全111.248.98.94 06/07 09:34
14F→: 沒修正。這個要怪微軟。111.248.98.94 06/07 09:35
18F推: 一些很老的dx遊戲也是有受影響。這些如果111.248.98.94 06/07 11:27
19F→: 是老微軟的話,一定會出patches來維護。111.248.98.94 06/07 11:27
20F→: 現在的微軟就算了,所以我就說還買window111.248.98.94 06/07 11:28
21F→: 的掌機嗎?Linux對各種相容性的問題,都會111.248.98.94 06/07 11:29
22F→: 找到方法解決。微軟以前是相容性最好,現111.248.98.94 06/07 11:29
23F→: 在是,都是你的問題。111.248.98.94 06/07 11:30
28F推: 嗯真的耶,以前都是用glut。所以是glut的111.248.98.94 06/07 13:53
29F推: 鍋?不對,以前用的是wGL,那還是微軟的鍋111.248.98.94 06/07 13:57
30F→: 沒錯。好吧,應該是以前程式在querySystem111.248.98.94 06/07 14:00
31F→: 沒有好用的api來full screen。所以以前可111.248.98.94 06/07 14:05
32F→: 已的,現在這種情況就不行了。111.248.98.94 06/07 14:05
1F→: e-core的clustered decoder實在太可怕了36.224.250.107 06/04 12:24
354F→: 現在的gpt有點像幾年前的自駕ai,看起來好58.114.66.74 06/04 18:49
355F→: 像馬上要實用了,但其實還差蠻遠的。現在58.114.66.74 06/04 18:50
356F→: 的LLM運用還是有很多問題,在某些地方可以58.114.66.74 06/04 18:51
357F→: 幫忙,但沒吹的那麼有用。40tops的npu確實58.114.66.74 06/04 18:53
358F→: 是目前夠用了,但LLM+RAG並沒有想像中的58.114.66.74 06/04 18:54
359F→: 精準。還需要各種方法補強。怕還沒補好,58.114.66.74 06/04 18:54
360F→: 這次的ai泡沫就爆了。58.114.66.74 06/04 18:55