V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  secondwtq  ›  全部回复第 13 页 / 共 121 页
回复总数  2401
1 ... 9  10  11  12  13  14  15  16  17  18 ... 121  
挖出个老贴 /t/62637
2022-08-14 20:12:24 +08:00
回复了 gps32251070 创建的主题 程序员 关于编程语言内存对齐的疑问
上面是 load ,不知道楼主打算怎么做 store 。现代 CPU 中单独的 store 指令比 load 更 cheap ,因为只需要往 store buffer 里面压一压,不会造成新的依赖。
按照拼的思路,你得做两次 load+两次 store ,本来一个 store 解决的事情,至于么 ...
直接存的话有和 load 一样的问题

另外根据 https://travisdowns.github.io/blog/2019/06/11/speed-limits.html#load-split-cache-lines ,在 Zen 系列上不仅跨 64 byte 边界的访问会影响性能,跨 32 byte 也有可能
2022-08-14 19:44:22 +08:00
回复了 gps32251070 创建的主题 程序员 关于编程语言内存对齐的疑问
第一,进行内存对齐的一般是编程语言的*实现*,不是编程语言

然后,就 x86 来说,一般编程语言的实现取 a ,b ,c 的方法是 mov ax, [s]; mov rbx, [a+8]; mov cx, [a+16],按照你那种紧凑的布局无非就是变成了 mov ax, [s]; mov rbx, [a+2]; mov cx, [a+10],都是三次
也就是说一般根本不会先整个 word size 读过来再拼接,拼来拼去的做法在 SIMD 里倒是比较常见

就算按照楼主的说法,不对齐,先取,再拼,省了一个 load ,多了几个位运算,不一定划算
楼主可能认为 load 很 costly ,其实大多数 load 都还好,只有 cache miss 的 load 才 costly

现代 x86 实现里面,非对齐的访问一般是不会有性能损失的,但是仅限于在一个 cache line 里面,如果跨了 cache line 就相当于 CPU 要帮你自动做两次+拼接,要是跨了页就更好玩了。对于在 L1D$里的数据,在对齐的情况下,每次 load 的延迟和占用的资源基本都是确定且最小的,而如果出现了跨 cacheline 或跨页,就会出现有些 load 和对齐的没区别,有些 load 则非常慢的情况,平均下来是降低了性能的
这个在 GPR 操作上影响还算小的,如果涉及到 SIMD ,连续 load 一串数据,对于 XMM load ,四分之一会出现跨 cache line ,对于 YMM 是二分之一,对于 ZMM 是百分百 ...

有没有需要紧凑布局的情况呢?当然也有,就是真的需要“节省内存空间”的时候,比如大量并行+数据量大的情况下如果你的算法不能优化到 cache 里面,DRAM 喂不饱 CPU 很正常,这时需要尽量利用内存带宽,而 ALU 运算就基本无所谓了,不仅 padding 可以不用,bitfield 也可以用上
2022-08-14 03:22:45 +08:00
回复了 pepsiwant 创建的主题 Windows windows 11 的蓝屏死机概率是不是大幅提高了?
这个每次蓝屏大概都是同一个原因,你把这个“原因”找到并解决了,就从经常蓝屏变成零蓝屏了
要是写过程序就能理解,程序里面大部分的 bug ,有个触发条件,满足这个条件必复现,解决方法有二,要么修掉 bug ,要么回避掉条件
主题里面这个故障,描述只反映出了系统不正常,系统简单分三层,应用软件层,OS 层,硬件层。OS 应该隔离掉应用软件的问题不影响整个系统,所以应用软件层不用管。OS 层其实可以再细分成通用的 OS 和硬件自定义的所谓“驱动”,这几个里面目前原则上不好确定是谁的问题。

这时候就要引入一些经验结果了,社区上对 Windows 11 的评价不统一,但有多少人是一天蓝屏好几次的?一个广泛使用的商业性质的基础软件的稳定版本,有多大可能出现如此严重的缺陷。有没有一种可能,所谓“蓝屏死机概率”,对于五成人基本可以忽略,对于三成人是百分之一,对于一成人是百分之十,对于楼主是百分百?
我暂时的推论是“windows 11 的蓝屏死机概率是不是大幅提高了”这个问题和楼主的故障根本就没有关系。就算 Windows 11 蓝屏概率提高了十倍,楼主把自己系统的那个具体的问题修复掉之后,照样稳如老狗。

> 可能的远因是什么,微软有表态吗?
这个也是经验结果,一般新东西确实比老东西更“不稳定”,然而这是完全正常的现象,微软没有必要“表态”。
替代方案:给你所提到的那些软件提 PR 把你遇到的问题修好 ...
我用 Linux 就时不时这么干,虽然一般不会提 PR ,因为要么就是启用一些 experimental 的功能,要么基本都是些很 dirty 的 hack

说正经的,snippet 工具我一般不用,但是就文档这个功能来说肯定还是嵌入某种实现的 WebView 更方便,但是不一定非要全上 Electron ,因为只有文档显示需要 WebView ,软件的其他部分理论上可以完全 Web-free ( snippet 的高亮应该也可以用 native 方案解决)。
而且在文档方面的话,我觉得文档内容和用来显示文档的壳同等重要。比如我也用 DevDocs ,但是有些东西的文档似乎是由于 license 之类的原因官方不提供,现成的文档有些也不是很方便。所以如果是想做新东西的话也可以在这方面下点功夫。
2022-08-14 02:45:20 +08:00
回复了 Kawnnor 创建的主题 Ubuntu 笔记本厂商预装 Ubuntu 不需要付费吗?
想起来零几年的时候就看过不少笔记本的广告,有很多就是预装 DOS 或者 Linux 的,也不知道那时候预装的 Linux 是啥,到底该怎么用 ...
2022-08-14 02:28:55 +08:00
回复了 coderlxm 创建的主题 分享发现 国内的游戏氛围真的太差了
"国内的游戏氛围真的太差了"
"国内的*日系(?)*游戏氛围真的太差了"
之所以加个问号是因为我也没听说过楼主讲得都是什么东西,因此无法做出准确的总结 ...

形象地来说,这就好比说“中国的玛雅语氛围真的太差了”“新几内亚的汉语氛围真的太差了”,问题是为什么每个中国人都要学玛雅语,为什么每个新几内亚人都要学汉语?我倒是觉得氛围差才是正常
还不如说“中国的吐火罗语氛围太差了”,至少中国真的有过吐火罗语 ...

之所以会有这种想法是因为十几年来我亲眼目睹我所关注的游戏细分领域随着我这一代人成长起来,从关键技术基本被洋人垄断到中国人贡献半壁江山。其实我和楼主的案例,都是更大世界的一个角落而已,人很容易只看到一小部分,不在意其他的东西,只能说还是得多学习一个。

另外自称“高手”的不说 114%,至少得有 57%是傻逼
考虑一下“Native 开发”这个词的意义,当你提到这个词时它一般是相对于“H5 开发”的( despite 你们多不喜欢这个说法,很多团队就是这么用的)

在技术不断演进的背景下,这两个词已经不是严格按照技术定义的了,真要按照工作内容来准确描述的话应该是“C++ Qt 开发”“Python Qt 开发”“QML 开发”“React 开发”“React Native 开发”,当你使用“Native 开发”和“H5 开发”这两个词时已经决定了你使用的是上面那套习惯性的语言,而不是下面这套更精确的语言

然后考虑“Native 开发”和“H5 开发”的区别,主要是开发效率,部署方式,开发语言,跨平台开发,性能和体验等,所以这个逻辑是先把技术方案的特点 map 到这些维度,计算它们与“Native”和“H5”的“理想型”的距离,也就是它不是一个维度的事情
2022-08-13 04:39:33 +08:00
回复了 wangyzj 创建的主题 程序员 微信不可清理数据大小占了 8G
@neoli 我七八年前用某乎的时候我记得还是很小而美的
后来不知道哪天改版了就又大又卡了,再后来老版 App 就没法用了
哦对还有一个技巧,看 git blame ,从一段代码是哪个 commit 引入开始,可以找到 commit message ,对应的 PR 和 issue 之类的,会有更多的上下文
(当然实操中会有一些问题,比如一些格式化代码之类的 commit 会把 blame 搞乱,这个有 --ignore-rev ,不过一个一个搞还是不太方便,有些 GUI 工具可以简化这个流程)
另外我觉得根据具体项目情况,可以看看 tracing 的工具,比如 https://github.com/janestreet/magic-trace (虽然这个事 PT 做的有点重)

不过我暂时还遇到没需要用到这些的时候 ...
工具没见过好用的,开源社区的 dssq 是,我白嫖你的东西,你怎么写的与我无关,我不会用直接一个 issue 骂过去

调试我喜欢打个断点看 call stack
2022-08-05 21:46:36 +08:00
回复了 niceyuri 创建的主题 问与答 2022 年,想玩 PC 游戏的铁子们还是自己装机吗?
楼主这些游戏除了全战要求高点,其他的只要不追求 4K 怕不是 1080 就可以 ...
推荐主机的更是搞笑,Xbox Series 现在能直接用全战骑砍 mod 了?
2022-07-31 03:10:57 +08:00
回复了 Dropless 创建的主题 问与答 书名"梦断代码"到底是什么意思?
我觉得你要尝试去 get 它背后的意思,而不是纠结于字面的细节

所谓“背后的意思”,就是,假设原作者想表达的意思是 A ,但是用某种语言表达出来,同时又考虑到篇幅、习惯等条件,实际写出来的其实是 A1 ,翻译成另一种语言之后可能就变成了 A2 。由于目前碳基生物所有东西都必须用语言表达出来,大家只能看到 A1 和 A2 ,而 A1 和 A2 这些表达本身是有种种限制的,因此其实除了作者本人之外没人能真正理解 A 到底是啥。一般这个过程里真正有用的是 A ,而 A1 和 A2 的存在只是为现实情况所做的一种妥协,是 boilerplate 。
不过这里本来是允许有,甚至是故意会有二义性的。不同的人可以有不同的说法。
尤其是诗歌,也包括标题这种类似于诗歌,篇幅受限要求比较精炼又有点虚头巴脑的东西
比如我发现你引用的这个词里面就有一句“西风残照”,风怎么“照”?这里明显是有没写在字面的东西的
我又找到一首诗,陆游的“梦断香消四十年,沈园柳老不吹绵”(说得还是他跟唐婉那点儿破事儿),这个“梦断”就感觉很虚了 ...

那作为一个标题,它的作用就是一个名字,它可以和人名一样只作为一个 ID ,不表达任何实际意义,“魂断蓝桥”英语原文 Waterloo Bridge ,这就是个地名 ... which 基本上就是跟人名一个性质的。也可以比较的精确,比如“基于大数据区块链深度学习的拉屎系统”,就好像写程序可以写得跟 OI 一样也可以写得跟 Objective-C 一样 ... 翻译起来也比较自由,“魂断蓝桥”不就加了私货 ...

Dreaming in Code 这书貌似是写一个软件项目的故事,大概除了马一龙之外没人能做梦的时候写项目,所以这个标题大概处于上面两个极端的一个中间位置,就是他会描述一定的特点,但是你真的不能像 PL 的 parser 一样计较,不然就会显得很荒唐,比如“苏美尔文明”英语“Sumer”,跟英语里的“Summer”很像,那是不是跟传说中的夏朝有关系呢 ...

那它描述了啥特点呢,第一这书跟代码有关系,这个是和内容相符的。当然你可以说这标题也跟梦有关系,不过稍有常识的人就能看出这话也就只能梦里面说说 ...
剩下的就比较主观了,我觉得就是想表达一种非常 devoted ,非常 hardcore 的感觉,因为你会发现既然这个“梦”不是生理上的做春梦噩梦梦游之类的事情,剩下的无论你怎么理解(主题里面都列出来了)都有一种把写代码当成“为人类的解放而斗争”或者至少是生离死别的意思。这个结合副标题“Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software”,列了一堆数据,就是要侧面表达我们很努力,很擅长做题 blabla ,这个和周同学的朋友圈内容本质上是一样的

那如果原文是这个意思,翻译过来只要大致也能表达这个意思就行了,字面意思一不一样根本不重要。这个我觉得汉语译名其实不差,因为这书貌似是讲失败的故事,而“dreaming in”并没有明确的偏向性,甚至对于一些程序员来说代码梦和春梦可能是一个性质,而上面几个例子说明汉语传统里面“梦断”或者“X 断”这种组合是和消极色彩有一定关联的。当然也可以理解成英语版表达的是“如做梦般不切实际的项目管理所带来的后果”或者“二十号人三年一边做梦一边捉了五千个虫子”,而汉语版换了一个方向。
2022-07-30 12:54:42 +08:00
回复了 u2gign 创建的主题 分享发现 没人讨论稚晖君的键盘吗,好想有一个
我不知道有多少 V 友知道 3dconnexion 这种东西,可以去狗一下,简单的来说就是把一个类似轨迹球的东西用于 DCC 的 viewport navigation
这东西争议貌似也很大,有人觉得有用有人觉得没用,但是确实是正经的商业产品,我觉得总体做得不比 TouchBar 差,起码光 3dconnexion 一家就活了二十多年,我觉得主要原因是人家有明确的应用场景和用户群(也就是所谓“killer app”),并且专注在自己的领域里面,TouchBar 就有点炫技大于实用的味道,试图做得更通用结果啥都没做成

但是我对 TouchBar ,以及类似的尝试总体上依然是持肯定态度的,因为我认为类似 3D mouse 这种针对特定流程优化的工具有很大的潜力(不是指商业潜力,而是用户效率和体验提升的潜力),这类产品做得比 3dconnexion 更成功的有很多,包括以前的 click wheel ,Stream Deck ,stylus ,玩游戏用的手柄,甚至鼠标滚轮都可以算这一类。
不难发现以上这些都满足“明确的应用场景和用户群”这一点,我不认为 TouchBar 和本主题的项目做到了这一点,但是同时我也不认为应该以商业成功的标准去要求每一个实验性的项目,因为这种事情的规律就是十个实验项目可能出不了一个成功的商业项目,但是如果没有实验项目那永远也不可能出现一个成功的商业项目。
就算是已经商业化的 3D mouse 也远没有之前的鼠标和后来的 multitouch 成功,但是只要它对一部分人的工作流有利,那么它就依然有存在的意义,哪怕对于程序员来说基本没用(不过有人拿这玩意绑定浏览器看网页,就如同 B 站有人拿 Stream Deck 玩 DCS ...)。

用本站最大俗的例子来说,这种东西就像是 Mac (尤其是换了 Apple Silicon 之后),通用性差,但是如果你有适用的场景,就超级有用,如果你用违反设计本意的方式使用的话很有可能是个垃圾。
当然,可以认为 Mac 也是有“明确的应用场景和用户群”,这东西没有。这个你可以理解成他只把事情做了一半,他只把自己比较擅长的那部分做了( which 对于这种 nerd 来说并不奇怪)。如果结合开源社区的思想,就是出现了一个比较 novel 的开源库,虽然暂时还没啥牛逼的用户,以后大概也不大可能,但你不能否认它对于整个开源社区的 contribution (只不过现在开源硬件整体还比较 naive ,但正因如此才显得这事情比普通的开源软件库更有价值)。哪怕鼠标和 multitouch 那么牛逼的东西,它的使用场景也是需要整个社区慢慢挖掘的。

这东西和 TouchBar 另一个共同的失败点在于,它们绑定上了完全不相干的东西,TouchBar 和 MBP 绑上了,导致一群程序员觉得没用,这东西和“客制化键盘”绑上了,导致一群人在拿客制化键盘的 perspective 来看这玩意(然而它们根本就是完全不同的方向)。不过这东西还好点,起码看上去左边那块可以拆下来。并且粗看起来 up 主并没有拿这玩意绑架整个客制化键盘圈子,而是提供了新的选择,TouchBar 当年可是实实在在 hijack 了 MBP 的产品线,限制了原有用户群的选择,这里我认为是有本质区别的——因为你不需要这玩意那就完全可以不买,这样它成本多高就与你完全无关,正如 CRUDer 们的工作大概率不需要买 RTX A6000 。
但是对于该 up 主来说,没有 killer app ,不算一个好的“键盘”之类的,是否真的算是“失败点”呢?这个可能只有他自己知道了。我从视频看出来的大概是他试图做到“大而全”,他说了很多可能的应用,但是根本就没有真的尝试挖掘过一个特定“killer app”,它又不可能做到像键盘鼠标 multitouch 一样极其通用。我个人认为他更偏向于做出一个好的视频(翻译翻译:流量高的视频),而不是一个优秀的创新。或者不那么诛心,假设他真的是更多的想做一个自用的“键盘”(之所以加引号是因为这个“键盘”和一般理解的“键盘”真的不同 ... 就好像虚拟“货币”不是一般人理解的“货币”,它只是重载了这个名字),他大概也和买了 3090Ti 回来天天刷网页那群人差不多,没想好做完之后究竟要拿它干啥。不过如果同样没啥意义的话,相比于其他“流量高的视频”和“买了 3090Ti 回来天天刷网页”这种行为,你更愿意看到哪一个呢 ...
2022-07-30 11:10:38 +08:00
回复了 letianqiu 创建的主题 Java 为什么 memory mapped file I/O 可能会导致 Long Time to Safepoint?
这 mailing list 不错,收藏了

> Gil Tene 在另一个 post 里提到 jvm 会把 internal 的 jni call 优化掉
这个有没有原文链接?
2022-07-30 11:04:37 +08:00
回复了 qiaoyurensheng 创建的主题 问与答 开源协议 MIT 与商用疑问
这种基本都可以理解为作者智商不合格不了解开源软件常识,正如楼主所说,MIT 协议和“禁止商用”以及“禁止非法使用”是相矛盾的
倒是很多专有软件的 EULA 里面会写不能用于制造 WMD 之类的奇怪条款 ...

智商不合格的人写的项目也建议不要使用
我的知识范围里,开源项目真正不可替代的比较少,国人开源项目不可替代的更少
我比较偏向 #9 ,沙司 by definition 是加了料的(不一定是严格意义上的“防腐剂”,但是可能起了类似防腐剂的作用)
我个人倒是比较喜欢买圣女果切碎煮烂,比蔬菜番茄味道更浓,个人觉得比番茄酱味道也更正
2022-07-30 10:51:19 +08:00
回复了 chengouzi 创建的主题 问与答 游戏玩不下去怎么办?
一局玩不下去可以试试重开一局 ←_←
1 ... 9  10  11  12  13  14  15  16  17  18 ... 121  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   1954 人在线   最高记录 6543   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 51ms · UTC 00:19 · PVG 08:19 · LAX 17:19 · JFK 20:19
Developed with CodeLauncher
♥ Do have faith in what you're doing.