V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  ipwx  ›  全部回复第 62 页 / 共 200 页
回复总数  3997
1 ... 58  59  60  61  62  63  64  65  66  67 ... 200  
@ericwood067 拿 GPU 和 CPU 比本来就不对啊。。。
@ericwood067 GPU 和 CPU 的处理方式根本就不同啊。。。你去看看 GPU 计算模型大概就明白了
P.S. 其实可以认为 GPU 本来就是最大的“专用芯片”,只能完成它设计意图内能做的事情。

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

重要的事情说三遍
另外这还要看你的 hash 算法是怎么支持 GPU 的。用 GPU 做通用计算要调用特殊的 SDK 的,比如 CUDA 。

我怀疑你调用的 hash 算法并没针对 M1 GPU 进行优化(我都没听说过它有通用计算的 SDK )。它可能还是调用的 CPU 。
? 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 就是绑定参数,后面的字典给参数。
2021-07-25 12:13:01 +08:00
回复了 LeeReamond 创建的主题 问与答 防止 sql 注入的原理是什么?
@LeeReamond 为啥我觉得预编译写起来更快 2333

大概是 C++/Python 的库都比较好用?
2021-07-25 12:09:33 +08:00
回复了 ljzxloaf 创建的主题 Java Java 目前实现全异步的方式有哪些
Actor model 很好用的。不过我不太熟 java,jvm 上只知道一个 akka 。
如果参与过牛逼的项目是不会担心没法证明自己的。牛逼的项目,后端难度可比前端高多了。
1 ... 58  59  60  61  62  63  64  65  66  67 ... 200  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2716 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 32ms · UTC 15:11 · PVG 23:11 · LAX 08:11 · JFK 11:11
Developed with CodeLauncher
♥ Do have faith in what you're doing.