首页   注册   登录
 FrankHB 最近的时间轴更新

FrankHB

V2EX 第 34994 号会员,加入于 2013-02-28 10:06:28 +08:00
今日活跃度排名 2723
FrankHB 最近回复了
@xmdbb 谁主张谁举证。你 ps 也可以拿 psd 出来啊……
@icyalala 代码反而不都有所谓。一些关键代码是谁写的就算理论上无法溯源,实用上装 13 自认原作者是要火葬场的。喜欢囗观这种打脸现场的可不是一个两个。
版权包含著作人身权。免版权是说随便署名当作自做的咯?
4 小时 24 分钟前
回复了 Falco 创建的主题 问与答 学生,余额 1w,做点什么好?
@phpc 答案可以是一样的。
8 天前
回复了 onice 创建的主题 程序员 请教大家如何比较两块 CPU 的性能?
@feather12315
1.是不同的概念,但是这里都适用,参考 https://stackoverflow.com/a/51759235。因为指令在 SMT 的实现中不同的流水级中的具体实现行为非决定性地依赖内部状态(例如功率控制可能非决定性地关闭部分并行实现的单元),这仍然是并发的。另外不管是并行还是并发和物理上的时刻或者时间段都没有直接关系,即便 SMT 的例子中字面上强调了同时,处理器中的计算遵循的实际上是同步时钟信号,跨时钟域未必和物理时间对应。
2.上层(操作系统内核)是相对处理器而言,更上层( userspace API )还是区分的。Linux 内核的 task_struct 提供 userspace 的进程实现,并通过 NPTL 以 1:1 的方式提供 pthread 实现。
另外,原本(如进程代数)所谓的进程的概念就是 task 的抽象,并没有进程和线程的区分,实际上相当于现在所谓的 userspace 的线程。而现在区别线程的所谓的进程是利用处理器提供的保护机制划分的运行时资源集合。
3.好坏是相对而言,也不是一概而论(“未必”)。这里相对的首先是两个独立核心各自独占 L1 的情况,所以看起来就是减半了;不过实际上,就是不考虑核心资源可能利用不足的劣势,光是 cache 多了占面积功耗也大,要是没用上就是坏处了。如果一个核心 2 个逻辑线程实际上需要共享大多数 L1 的内容,就算 cache 有多也难以发挥优势。
9 天前
回复了 DDStrange 创建的主题 程序员 个性化广告推荐的使用有些泛滥了吧
@seven777 这锅动画片不背。
9 天前
回复了 onice 创建的主题 程序员 请教大家如何比较两块 CPU 的性能?
@feather12315 1.并行和并发不矛盾。2.处理器原则上不知道所谓的进程资源边界(至少 IA-32 用来实现多任务的机制很大程度被现实的上层实现无视了),而上层也未必区分线程和进程(例如 Linux 内核只管 task_struct )。3.共享 L1 另一方面看就是每线程独占的 cache 减半,未必更占便宜。
hash 一样。。。一看还以为用了啥高端的碰撞构造技术……结果全一样?
9 天前
回复了 largecat 创建的主题 程序员 关于 Python 强制缩进的梗
本着“请尽量让自己的回复能够对别人有帮助”,还有另外几点没预热过的先给过一遍,预防以后跑题:

1.在实现语言时,indentation 的 error condition 不管算成 syntax error 还是 semantic error 都很别扭。这种逼迫实现无法区分 syntactic grammar 的语言设计姿势当然远不止是引入 semantic-sensitive indentation 一种,更著名拉仇恨的比如 C++的 vexing parse。据我所知,职业搞 PL 的基本不会在这上面跟自己和用户一起过不去,非要搞就是一个 preprocessing phase ( C processor、Lisp reader、……),和余下的语言规则的耦合通常是较为松散的;而这里 indentation 甚至能影响控制结构的特典就显得非常突兀了。某些语言的设计者如何忍受这些问题并坚持在一个实用且不拒绝未来扩展的语言中保留这类奇怪的 feature,就是一个耐人寻味的话题了。

2.有人提到,缩进多或少也跟代码质量普遍地有关。然而从操作上来看,这原则上只能在已知整个翻译单元的自顶向下的视点下才看起来有那么点意义。讨论重构之类的“工程级别”的变换(区分于语言实现的 code transformation ),通常默认更强调代码的局域性和松耦合:如果不影响外部的代码,能局部定位修改满足目的才是好的。这里和缩进层次多少并没有直接关系,差别只是编辑嵌套比较深的代码时需要对付的前缀缩进的数量确实比较多而已,然而调整这种缩进在大部分( py 以外的)用户的严重,本来就该是编辑器的机械劳动。缩进多影响代码质量的观点这个看法看起来也不是 py 用户的发明,那么它到底是哪来的?我能记得的好像就是某些 C 用户对嵌套控制语句的“滥用”非常不满而鼓吹嵌套超过若干层是不好的代码,逐渐演化成了缩进过多是不对的。但是这很大程度本来就是 C 的无能,不知道为何推广到不少其它语言上好像也被莫名其妙地接受了。

技术细节:C 没有函数嵌套(倒是省了 funarg problems ),因此除了控制语句外很多重复构造的变换其实经常没有能耐嵌套(严格来说,struct+模仿 C++的 lambda operator()的 free function 可以做到,但实在太麻烦了,没见到有人日常这样写),所以很多东西干脆直接重复用代码(或者宏)实现了。Python 哲学里所谓 flat 优于 nested 这样的说法似乎也是这样来的?
反观 Lisp-like 的,大部分有意无意随便嵌套(倒也间接增加了)))))))))))的概率),用户就完全没这样的意识。
关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2174 人在线   最高记录 4346   ·  
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.3 · 8ms · UTC 11:58 · PVG 19:58 · LAX 03:58 · JFK 06:58
♥ Do have faith in what you're doing.
沪ICP备16043287号-1