首页 注册 登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  ipwx  ›  全部回复第 62 页 / 共 200 页
回复总数  4000
1 ... 58  59  60  61  62  63  64  65  66  67 ... 200  
❮ ❯
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 分块的）。读也亦然。
2021-07-25 16:16:57 +08:00
回复了 LeeReamond 创建的主题 › 问与答 › 防止 sql 注入的原理是什么？
顺便发送参数也不是变成字符串。你可以翻一翻各个数据库自己的文档，肯定是有二进制协议的。这很显然，数字用数字的格式发送，字符串用字符串的格式发送，全程不会混淆，自然不会被注入。

可以说 prepared statement 其实并不是防注入而发明的，而是为了更快（省去编译优化 SQL 的过程，可以多次复用）。只不过因为它的原理，它天然不会被注入而已。
2021-07-25 16:13:42 +08:00
回复了 LeeReamond 创建的主题 › 问与答 › 防止 sql 注入的原理是什么？
@LeeReamond 不是。

这些数据库服务器或者嵌入式数据库都有更底层的协议的（不是纯粹的 SQL ）。那些协议可以把带参数的 SQL （或者干脆预编译成字节码）和参数本身分开来打包传送给服务器（或者给嵌入式数据库的核心 API ）。数据库系统是直接拿着 SQL 或者字节码 + 这些参数工作的。

譬如 PostgreSQL https://www.postgresql.org/docs/9.3/protocol-flow.html#PROTOCOL-FLOW-EXT-QUERY

先发送 SQL，PostgreSQL 解析并编译这个 SQL，然后发送参数，最后执行。编译过的 SQL 可以不用再发送一遍，直接发送新的参数，可以继续执行。
2021-07-25 12:14:02 +08:00
回复了 LeeReamond 创建的主题 › 问与答 › 防止 sql 注入的原理是什么？
@LeeReamond 举个例子，Python 标准库操作 Sqlite

cur.execute("select * from lang where first_appeared=:year", {"year": 1972})

这里 :year 就是绑定参数，后面的字典给参数。
1 ... 58  59  60  61  62  63  64  65  66  67 ... 200  
❮ ❯
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2829 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 36ms · UTC 11:41 · PVG 19:41 · LAX 03:41 · JFK 06:41
Developed with CodeLauncher
♥ Do have faith in what you're doing.