V2EX › ipwx 的所有回复 › 第 62 页 / 共 201 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 ... 58 59 60 61 62 63 64 65 66 67 ... 201

❮

❯

2021-07-28 17:36:02 +08:00

回复了 Imindzzz 创建的主题 › TypeScript › 前端同学，你到现在还没用 typescript 原因是什么？

可是 webstorm + js + vue.js 的体验很好啊。

甚至可以识别 vuex 的 state，在代码提示里面正确给出属性。

2021-07-28 01:08:35 +08:00

回复了 ETONG 创建的主题 › 程序员 › 在 html 里面可以直接写 PHP 代码吗

建议楼主用 url_rewrite，做虚拟静态化

2021-07-28 01:04:51 +08:00

回复了 aladdinding 创建的主题 › NAS › 买白群晖好还是自己倒腾黑群晖好

@oxromantic ummm 我还是会开一段时间上传的（ BT ）

2021-07-27 16:01:36 +08:00

回复了 aladdinding 创建的主题 › NAS › 买白群晖好还是自己倒腾黑群晖好

@aladdinding 教你一招：找个老移动硬盘插到 nas 上当下载盘 2333 坏了就换一块不心疼。

下载了之后，每过一段时间把完成的任务移动到 nas 上。

2021-07-27 10:50:54 +08:00

回复了 ericwood067 创建的主题 › MacBook › M1 的 MacBook 进行 hash 运算的速度不行， M1 是不是更像是专用的芯片

@ericwood067 比起这个我更好奇你是什么 hash 算法能用 GPU 加速。

2021-07-27 10:47:25 +08:00

回复了 ericwood067 创建的主题 › MacBook › M1 的 MacBook 进行 hash 运算的速度不行， M1 是不是更像是专用的芯片

@ericwood067 这么说吧，理论上对于 GPU 擅长的事情，所有 GPU 的性能比 CPU 的性能，计算模型上就差了 1000 乃至 10000 倍。根本不是一个量级的。

GPU 做通用计算已经是折了不知道多少效率之后呈现出来的结果了。

2021-07-27 10:46:42 +08:00

回复了 ericwood067 创建的主题 › MacBook › M1 的 MacBook 进行 hash 运算的速度不行， M1 是不是更像是专用的芯片

@ericwood067 拿 GPU 和 CPU 比本来就不对啊。。。

2021-07-27 10:46:28 +08:00

回复了 ericwood067 创建的主题 › MacBook › M1 的 MacBook 进行 hash 运算的速度不行， M1 是不是更像是专用的芯片

@ericwood067 GPU 和 CPU 的处理方式根本就不同啊。。。你去看看 GPU 计算模型大概就明白了

2021-07-27 10:46:04 +08:00

回复了 ericwood067 创建的主题 › MacBook › M1 的 MacBook 进行 hash 运算的速度不行， M1 是不是更像是专用的芯片

P.S. 其实可以认为 GPU 本来就是最大的“专用芯片”，只能完成它设计意图内能做的事情。

GPU 不是通用计算芯片！
GPU 不是通用计算芯片！
GPU 不是通用计算芯片！

重要的事情说三遍

2021-07-27 10:45:02 +08:00

回复了 ericwood067 创建的主题 › MacBook › M1 的 MacBook 进行 hash 运算的速度不行， M1 是不是更像是专用的芯片

另外这还要看你的 hash 算法是怎么支持 GPU 的。用 GPU 做通用计算要调用特殊的 SDK 的，比如 CUDA 。

我怀疑你调用的 hash 算法并没针对 M1 GPU 进行优化（我都没听说过它有通用计算的 SDK ）。它可能还是调用的 CPU 。

2021-07-27 10:44:01 +08:00

回复了 ericwood067 创建的主题 › MacBook › M1 的 MacBook 进行 hash 运算的速度不行， M1 是不是更像是专用的芯片

? M1 的 GPU 居然可以被拿来做通用计算了吗？

可以认为 GPU 通用计算才是在 GPU 的原本功能上开发出的新功能。

2021-07-25 20:37:31 +08:00

回复了 lzjamao 创建的主题 › 程序员 › 基于 mmap 相比于 fwrite 写日志，是否有性能优势？

@ryd994 另外什么少一两次拷贝影响的问题。flush 真正影响的是，机械磁盘的寻道很慢好不好。能缓冲写入的，就得缓冲写入，不然频繁小数据写入，拖累整个系统其他进程的速度。

2021-07-25 20:36:38 +08:00

回复了 lzjamao 创建的主题 › 程序员 › 基于 mmap 相比于 fwrite 写日志，是否有性能优势？

@ryd994 因为 mmap 内核管啊，内存哪怕崩溃了 mmap 刚放进去的东西还在，系统会记得把东西放进磁盘的。

https://stackoverflow.com/questions/5902629/mmap-msync-and-linux-process-termination

顺便 fprintf 要是没缓存不就更频繁写入文件了么。要是有缓存不就又二次缓冲了么（蛋疼）

2021-07-25 18:08:55 +08:00

回复了 lzjamao 创建的主题 › 程序员 › 基于 mmap 相比于 fwrite 写日志，是否有性能优势？

@BiteTheDust 毕竟 fwrite 到 mmap 还得复制一份。mmap 的正确操作不是直接写入么 2333

2021-07-25 17:03:03 +08:00

回复了 MasterCai 创建的主题 › Apple › 2021 年 7 月， M1 芯片还有办法安装没有上架 MAS 的应用吗

不明白 @MasterCai 你纠结到底是应用里面检测环境然后拒绝执行，还是内核代劳了应用成功拒绝执行，这两个形式上的区别有啥意义。本质不都是应用拒绝执行么？

2021-07-25 17:02:14 +08:00

回复了 MasterCai 创建的主题 › Apple › 2021 年 7 月， M1 芯片还有办法安装没有上架 MAS 的应用吗

@MasterCai 可是我觉得就算是苹果系统内核根据应用给的 option 来拒绝执行，本身也是应用在拒绝执行啊。

就好像你调用了系统 API 拒绝执行是一个道理啊。

2021-07-25 16:55:47 +08:00

回复了 lzjamao 创建的主题 › 程序员 › 基于 mmap 相比于 fwrite 写日志，是否有性能优势？

@sagaxu 主要是省了 flush 啊。你普通写入为了避免程序崩溃看不到最后的日志，很多时候要频繁 flush 的。

2021-07-25 16:47:29 +08:00

回复了 lzjamao 创建的主题 › 程序员 › 基于 mmap 相比于 fwrite 写日志，是否有性能优势？

不怕内存崩溃 => 不怕进程崩溃

话说回来依赖 mmap 如果系统宕机或者断电了，那也就没机会写回磁盘了。这点和 flush 就不一样了

2021-07-25 16:46:46 +08:00

回复了 lzjamao 创建的主题 › 程序员 › 基于 mmap 相比于 fwrite 写日志，是否有性能优势？

然后楼主你举的那个日志的例子很特殊，是永远顺序往下写的。写满一个 4096 块就不会再动了，系统完全有机会每次写满 4096 再刷新。而且因为是 mmap，每次写一条日志就不需要 flush （因为你不怕内存崩溃），相当于避免了频繁 << 4096 大小的文件写入，自然变快了。

缺点也很明显了，日志不是完全实时的。

2021-07-25 16:43:45 +08:00

回复了 lzjamao 创建的主题 › 程序员 › 基于 mmap 相比于 fwrite 写日志，是否有性能优势？

mmap 比 fwrite 快的主要原因，不是因为不需要一次内存拷贝么 2333 。fwrite 需要把内容拷贝到内核去，但是 mmap 直接就是内核的。

然后 mmap 写回磁盘的最小数据单位是 page size，一般 linux 上面是 4096 。好处是 flush / cache 都是 linux 内核管的，和虚拟内存走相同的方式。而且就算进程崩溃了，因为 mmap 是虚拟内存块，所以该写回的还是会写回。那么坏处就很显然了，如果每次都只改某些 4096 块的某些小地方，要写回的东西还是蛮多了（因为写回一次是按 4096 分块的）。读也亦然。

1 ... 58 59 60 61 62 63 64 65 66 67 ... 201

❮

❯