首页   注册   登录
 FrankHB 最近的时间轴更新
FrankHB's repos on GitHub
162 人关注
pl-docs
Programming Language Documentations
C++ · 13 人关注
CppTemplateTutorial
中文的C++ Template的教学指南。与知名书籍C++ Templates不同,该系列教程将C++ Templates作为一门图灵完备的语言来讲授,以求帮助读者对Meta-Programming融会贯通。(正在施工中)
C++ · 3 人关注
nano-signal-slot
Pure C++11 Signals and Slots
C++ · 3 人关注
NPLC
NPL console (main test repository for NPLA1 implementation of YSLib)
C++ · 0 人关注
Baka-MPlayer
The libmpv based media player
C++ · 0 人关注
Corecat
Corecat: Core of The Cats Project
C++ · 0 人关注
CxxFunctionBenchmark
benchmark for various C++ function implementations
TeX · 0 人关注
draft
C++ standards drafts
Python · 0 人关注
english-please
Offer for repositories whose README are written in Chinese.
C++ · 0 人关注
fancy2d
C++ · 0 人关注
function2
Improved and configurable drop-in replacement to std::function that supports move only types, multiple overloads and more
0 人关注
google-group-docs
Public text for Google groups discussion
HTML · 0 人关注
itoa-benchmark
C++ integer-to-string conversion benchmark
C · 0 人关注
LCUI
A simple graphical interface library
C · 0 人关注
libfat
FAT library for GBA, DS, Gamecube & Wii
C · 0 人关注
libnds
C library for Nintendo DS
C · 0 人关注
llmd
如果将markdown视作一门编程语言可以做哪些有趣的事情?
C++ · 0 人关注
MdCharm
MdCharm Source Code
C++ · 0 人关注
mingw-std-threads
Standard threads implementation currently still missing on MinGW GCC on Windows
C++ · 0 人关注
minicodecvt
C++上的简单编解码实现
C++ · 0 人关注
modern-cpp-tutorial
📚 C++11/14/17 On the Fly
C · 0 人关注
newlib
C++ · 0 人关注
nix
Nix, the purely functional package manager
C · 0 人关注
opensgx
OpenSGX
C++ · 0 人关注
rapidjson
A fast JSON parser/generator for C++ with both SAX/DOM style API
TeX · 0 人关注
resume
:pencil: My resume / 我的简历
Python · 0 人关注
SIF-TeamExport
Export your LLSIF team members via screenshots.
Rust · 0 人关注
swapview
Print swap usage per process. Implemented in various programming languages
C++ · 0 人关注
Textcat
Textcat: Text data formats library
C · 0 人关注
xege
xege

FrankHB

V2EX 第 34994 号会员,加入于 2013-02-28 10:06:28 +08:00
今日活跃度排名 12756
FrankHB 最近回复了
3 小时 37 分钟前
回复了 vcfghtyjc 创建的主题 Python Python 的多线程原来不是真的多线程啊
所以这些 CS 导论就该明确方向的系列问题怎么还那么经……
还是得从基础概念入手。
https://stackoverflow.com/a/51759235/2307646
里面引用的 Robert Harper 的博客文章看来又能点进去了,那就不重复为什么需要这样明确之类的细节问题了。
就说重点,补课,再解释顶楼的问题:
1.并行(parallelism) 和并发(concurrency) 都是计算(或者说,表达计算的程序片段)的性质,但两者本质上是两回事。
更进一步地,两者可以是正交的:程序中并行和并发程度的多少之间也没有必然联系。
注意,计算是抽象的。计算的实现,包括“同时”之类的物理属性,和这些性质没有直接关系。
2.并行是关于管理程序中确定性的(deterministic) 计算之间的依赖(dependency) 使它们整体具有更好的渐进效率(asymptotic efficiency) 的性质;并发是关于处理程序的各种非确定性的组合(non-deterministic composition) 使之能响应各种不保证可准确预知的时机输入的性质。
一定程度上,不考虑依赖之间的动态变化,并行描述的是程序中的计算之间的静态关系,而并发可以描述不确定的动态关系。
3.并行的对立面是串行(seriality) ,指一系列确定的计算明确具有链式的依赖;并发的对立面是序列(sequentiality) ,指不确定的计算的某个子集之间,其顺序被约束了。
约束计算的操作称为调度(scheduling) ,其中可能包含对计算资源的分派(dispatch) 。
4.进程(process) 或者线程(thread) 为了实现是占用特定的计算资源完成的带目的计算(或者说,任务(task) )引入的抽象,是程序的动态映像和为了实现计算分配的其它资源的集合。
两者的区别传统上和资源的具体集合有关,这里不是重点,以下都以可调度的线程代表。
作为组成其它程序的组件,它们可具有并行和并发的性质,分别通过竞争性调度机制的具有非确定性和调度中分派计算资源的目标不同的事实而体现。一般地,决定如何调度的逻辑是在进程或者线程之外的。程序通过这样的抽象的表达,只是表明计算已被拆分成为不同的待调度的组件,并不能保证已经具有并行或者并发的性质。
5.使用进程或者线程这样的抽象只是为了便于实现这种特定的可调度的计算表达。
这不排除其它手段实现并发和并行的手段,因为一般情形下,调度自身的效果被不确定性涵盖而不是计算的作用(effect) ,不被要求对用户可见。最简单地,一个表达式在计算时若不要求子表达式计算之间的相对顺序,也没有影响计算结果的依赖限制它们之间的顺序(以保证不违反计算的因果性语义),那么它们的计算原则上就是并发的——用户没法预知确定的计算如何发生,也没法保证确定这里是不是需要插入一个线程或者其它可调度的实体来实现并发;而若使用确定的最优化规则(例如某个指令集允许的指令级并行规则),它们之间也可以是并行的,用户可以查看目标代码等方式来确认这里的计算被分派到不同的设备上同时实现以取得比串行计算更好的效率。
6.为了解决共享资源的竞争引起破坏计算的目的非预期的非确定性,可能需要引入同步。
同步操作和调度一样约束计算的顺序,因此可能有相互作用,例如增加不必要(程序中不要求表达)的隐含依赖而减小程序的可并行部分,并最终实际减小并行程度。
就 LZ 的例子,GIL 是一种粗粒度的内部调度机制,在极端情况下把并行语义的程序串行化。这个意义上它是不并发的,但这是偶然情况,不是实现系统总是对用户可见的整体的性质,更不是语言要求的性质( PyPy 就不用 GIL )。
7.多线程中的线程在不同的上下文中不严格地是一回事。
一般地,高级语言使用表达式的求值引入计算的作用。对大多数高级语言来讲,默认情形表达的计算遵循同样的顺序规则,最常见的如指令式语言按程序的字面顺序(literal order) 。这个顺序整体上约束了确定性计算(尽管按上面的讨论,像子表达式这样的计算仍然可以是非确定性的)。
为了更明确地表达可被程序操作的非确定性计算,同时不修改默认情形的计算顺序的语义,按原有规则的计算任务整体被抽象为一个执行线程(thread of execution) 。多线程环境即指语言允许程序蕴含多个执行线程,每个线程内都适用默认计算规则;而线程间是没有类似的计算顺序规则限制,需要再另行约定共享计算资源和同步操作以明确线程之间计算的互操作。
这个意义下,“同时”或者竞争调度不是多线程的关键。尽管语言中的执行线程允许并发,但不可见的调度实现不需要提供计算资源是否在物理上(同时)被重叠利用的保证。极端地,调度可以完全放弃对线程的资源分派,无限等待线程自发完成计算,此时线程不再抢占(preemptive) ,调度退化为协作式多任务(cooperative multitasking) 的实现。
但大多数情形在语言引入执行线程的目的不止是为了允许在程序中表达非确定性,还同时作为提供显式复用计算资源的特性(乃至显式地并行),所以不太会有这种调度内部直接放弃非确定性退化成平凡情况,执行线程在这里也就和一般意义上被实现调度的线程不加区分,统称为线程。
存在 GIL 虽然更接近退化的情况,只要不改变被实现的语言具有多个执行线程,且语言不能绕过执行线程可见地调度线程,那么整个实现就是一个多线程环境。
8.在硬件实现中,因为在外部看来计算资源整体的占用是很大程度上能预期上限,习惯上把这部分实现可用的资源(特别地,一个 CPU 核)作为一个物理线程。相对地,一个能被软件分辨并调度的线程是逻辑线程。
同时多线程(SMT) 专指这里的复用物理处理器核的硬件资源,以使一个物理处理器支持超过一个逻辑线程的手段。在软件看来,一个线程逻辑上对应一个处理器,因此一个物理核心对应多个逻辑处理器。
不支持 SMT 且只有一个物理核心的实现仍然可以通过分时复用实现多线程。这和软件的语言实现的情况类似,因为物理核心原则上对软件不可见,所以软件的意义上这就是“真正的”多线程。
9.硬件相比软件的特殊性是可提供物理同时的多任务支持:一个处理器 package 可以有多个物理核,如同一个抽象机进程中支持多个执行线程,这似乎符合最朴素的抽象。
但这和并行或者多任务根本上都没有实现以上的关系,因为如最开始提到的,“物理同时”从来就不是考虑这些抽象时必备的要素,仅仅是方便理解而提到罢了。
而且,实际的处理器内部也不可能完全重叠地利用计算时间,最显然地,要求时钟同步来避免非预期的不确定性。
此外,单一核仍然能通过异步中断能实现物理上同时的多任务,这和多线程也没有直接的关系。
6 小时 34 分钟前
回复了 FakeLeung 创建的主题 程序员 大家对于中文变量名是如何看待的?
@myfei 生理上“写代码”就不可能是完全同步的操作。你所谓的同步,是逻辑步骤之间的顺序性,这不影响身体的不同部位能够并行,自然有条件并发。
如果你非得把注意力来回集中在手上,那手动一下每次同步都有几个毫秒的神经传递延迟,加起来是不是至少有一半时间你脑子都不用干活了?况且正常人不刻意做根本做不到这种严格的同步。
退一步讲,不严格的“全神贯注”单工操作也是一种低效的方式,因为至少在注意力集中在理解代码的时候,手在物理上也是不必要停下来的。明明能做到(有限地)并发,为什么强行要(假装)顺序操作?
看到你笑了我就知道你不擅长用键盘输入,至少是不擅长大多数人原则上都能学会并的输入方式。像 QWERTY 这样的键盘布局,本来就刻意避免什么固定的含义,因此正常人高速熟练输入之后是没理由时常去盯着刚刚摁过的键位发愣的;结果是对按键词频的感知是无意识的,但又不会立刻全部遗忘。特别地,像 pre-/re-/init-/-tion 之类常见双手左右开弓几乎并行输入的按键组合,输入几乎不过大脑基本上也不会出错。这就是一种肌肉记忆。
写代码当然不需要首先强调输入有多快,但这个快就是指吞吐量;如果影响响应中断思路,那么实际上吞吐量再大也是慢的,这种影响应该越小越好。就算这种情况平时不怎么遇到,在一瞬间成为瓶颈也是不爽的。如果你从来没有这样的体验,恐怕是你没有尝试处理过极限情形,或者你的脑子一向转得太慢而从来不考虑这样做了。
你所谓的不输错,那首先要求是盯着屏幕取词,跟用来输入的动作没有直接关系;真要有关系,那也是输入不需要经常性劳烦大脑,减少打断思路的机会能让注意力集中在这种输入以外的地方,那也能更高效。
15 天前
回复了 weiruanniubi 创建的主题 奇思妙想 我国高等教育为什么不是宽进严出?
@lagoon 医药费出了,人没救活,不行?
天王老子就是想要告诉你天经地义的解释权不归你等通行俗钱的下人所有。
15 天前
回复了 weiruanniubi 创建的主题 奇思妙想 我国高等教育为什么不是宽进严出?
@openbsd 扫地机器人、、、可能上面还能跑 BSD,,,
15 天前
回复了 efonfighting 创建的主题 程序员 做技术管理了,还要不要写代码
能自己写几行代码解决的事情,你还好意思抓几个人来替你搞来给老板添堵?
@hoyixi 35+的人好哄,还是刚出学校的小年轻好哄?
到时候吃了一堆房子的银行的窟窿便宜,还是让某些人仅仅吃饱饭便宜?
……上面有人所谓的奶头乐,实际上根本没起来,“前景”还大得很呢。
@hantsy 系统性金融风险那是明摆着的。
996 最主要到底薅得是谁的羊毛,很多人到现在都没搞清楚。
15 天前
回复了 maxxfire 创建的主题 程序员 为何有人总觉得程序员 工资高了?
@optional 议价和催收能力当然也是赚外快的一环。另外也不是说非得做和本职工作一样的活,不一定有那么大的压力。
对选择 996 的理性人来讲,说白了其实就是超出日常工作部分的本事不够,不如 996 中的违法黑工多出来的部分可行嘛。
不过 996 还是会影响不 996 的本职工作的成本问题。某些行业工贼抖 M 习惯了,普遍压缩行业的工作机会缩减选择余地,搞得找到不 996 的工作现在都变成一种本事了,这也是哄抬取得合法收入需要花费的成本。
15 天前
回复了 maxxfire 创建的主题 程序员 为何有人总觉得程序员 工资高了?
工资?默认讨论时薪累积最大合法工作时间实际上本应该是常识。就是有人侥幸法不责众呢……
@Raymon111111 “短时间搞到大量的钱”是个真实需求,但是如果其实现不排除避免违法,那么门路实在多了去了。996 除了暂时不容易碰上刑法以外不配被特殊化。然而讨论这个需求应该对应的是“收入”而不是“工资”——没人阻止你非工作时间另外接私活或者兼职,非得 996 搞得没时间赚外快或者没能力接活,怪谁呢。
15 天前
回复了 FakeLeung 创建的主题 程序员 大家对于中文变量名是如何看待的?
@myfei 那首先说明你输入效率太低。
输入不会成为瓶颈的情况下拿轮得到补全的 UI 反应?而且要是刚好 le 和 leader 之间还有其它变量名你不能马上回车怎么办?就算恰巧能回车,非连续输入的情况下不确信是不是马上能回车还得愣一下不需要时间?信不信你输入 le 去选词的时间都够我敲两个 leader 或者“领导者”了?
而更大的槽点是你没搞清主要问题在哪。正常输入代码实际上多花几倍时间输入 leader 或者领导者都不会成为瓶颈,因为这种低级操作很容易形成“肌肉记忆”,在瞬时是可并发的,原则上不需要阻碍思路。而停下来思考要不要回车甚至看 UI 反馈选字是复杂的分支操作,基本没法并发,明显更打断思路影响效率。
另外,真的不得不打断思路去对付一个比较长的名称的话,我倾向选择选中复制粘贴,因为可以减少让具体拼写(尤其是意义不明的前缀)过大脑污染 cache 的机会,避免之后稀里糊涂念歪变量名而被迫停下来修正这样再次增加打断思路的风险。
关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   157 人在线   最高记录 5043   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.3 · 12ms · UTC 20:21 · PVG 04:21 · LAX 12:21 · JFK 15:21
♥ Do have faith in what you're doing.