|
锁定老帖子 主题：对不起.我也喜欢跳大神...
精华帖 (8) :: 良好帖 (0) :: 灌水帖 (0) :: 隐藏帖 (1)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-09-19
1981年。。。
引用 鼠标的 Alto 和 Dorado 工作站、大型立式点阵显示屏、所见即所得（WYSIWYG）的文本编辑器、图形编辑器、面向对象的互动式编程环境与综合类库（class library）、局域网、激光打印机、电子邮件 真幸福啊。。。81年都还在看小人书呢。 |
| 返回顶楼 | |
|
发表时间：2009-09-20
中国这个行当的奇怪之处在于，卖的明明是山寨品，却不得不跟着国外的新技术走。是先天残缺的。要不就干脆像印度coder那样看得开。CPU, 编译器, ……不说了，通通都是国外的。如果是别的行当，用着D版的Matlab或者D版而又不明原理的VHDL compiler， 机械、建筑CAD，国外淘汰的流水线，包括科研，淘汰下来的实验设备，那会自然而然地怀有正常的山寨心态，不会觉得太分裂。开源的共.产主义在软件领域实现，这怎么看都是奇迹，难道是因为人天性喜欢编程所以不一定索要报酬？
中国的计科科研，（一锅烩吧：是些工程院院士，清华两院院长级别，剩下的也差不到哪儿去了），怎么搞什么都用java呀？太不神秘了吧，这经费还怎么好批呀？Ada不行怎么着也得cpp吧。你不买mac那算符合国情用度合理，你用xp怎么也得用正版吧？用D版也就算了，用原版呀，别是“臭名昭著”的番茄呀，用番茄也别在论文截图里露出来嘛。(这个没证据，像我这样的UI控会DIY掉XP第三方主题限制) 一颗平常心。 |
| 返回顶楼 | |
|
发表时间：2009-09-22
想得太简单了。 语言的需求绝对不是引领行业的标准。更别提什么函数式了(80年带就有的概念了)。语言的细节标准是左右不了的。
还是多关心关心大厂家的战略指导吧。JAVA带来的绝对是个主流的思想(但可能被斩杀)，平台化的编程微软千年之初就开始提倡，而且到目前铺垫得非常好。但这个还不是我讲的重点，cloud 的出现，让微软付之东流，虚拟存储，虚拟信息一步也没跟上。 多关心关心巨头的战略思想吧，关注语言细节是科研，想做战略的指导绝不是这些。 |
| 返回顶楼 | |
|
发表时间：2009-09-22
最后修改：2009-09-22
其实巨头都养着些两群人：科学家和大骗子，战略指导也是他们制定的。
听科学家的没错，而且忽悠人的东西也少。 |
| 返回顶楼 | |
|
发表时间：2009-09-22
最后修改：2009-09-22
其实这也是大牛们为啥都紧盯着paper不放的原因. Google不就是从paper中来的么..
另推荐一下O'Reilly Open Source Convention(OSCON)的讨论精华. 引用 并发构造纵览
。
Ted Leung 一直是一位有趣的演讲者 — 他为动态编程语言社区做了许多工作，尤其是在 Python 方面。他的演讲详细讨论了多种并发方法；其中一些是大多数读者熟悉的，但是一些方法对于主流计算机科学课程和实践程序员来说相当深奥。Leung 列举了六七种并发模型 或范型。 大多数程序员最熟悉的并发模型是线程化。大家同样熟悉线程化的问题：锁冲突和死锁。在一般情况下，用锁实现的并行总是需要开发人员做大量显式的计划工作。其他方法虽然都有缺陷，但是大都支持更高层的抽象，避免显式地锁住资源。 一种并发方法是软件事务性内存，这在 Haskell 中已经比较普遍了。 这种方法按照与事务性数据库系统相似的方式对待内存，也就是操作保持原子性，在发生请求冲突时执行回滚和重试。 事务性内存可能导致重复计算，但是在操作冲突不多的情况下，开销仍然比锁机制低。 另一个模型是 Actor 模型，这在 Erlang 中尤其知名（但是 Leung 谨慎地指出 Actor 模型和 Erlang 的发展是相互独立的）。Actor 模型基本上是 “不共享任何东西” 体系结构，在向其他 Actor 发出请求时 Actor 总是传递自含的消息。在去年的 OSCON 上，我写过一份关于 Actor 的讲稿。 Leung 提到了 Linda 和 ParallelR 底层的元组空间模型，但是由于时间的限制，并未详细讨论。在这种模型中，任务按空间和时间分隔开，读和写也是分开的。 Leung 还提到了 Bill Ackerman 的 “数据流” 概念，这个概念支持声明式并发。这种方法的问题是，尽管它对问题进行划分，但是无法处理非确定性因素（也就是说，它只适合纯功能性语言）；如果需要处理真实的非确定性因素（比如输入和输出），就需要 Actor。 Leung 讨论的最后一种模型是持久化数据结构。这是一个不完整的模型；它不能解决所有并发问题。但是，它是一种良好的措施。这种模型很早就出现了，但是在最近一两年，由于在 Clojure 语言中的应用开始流行了。基本思想是所有数据结构都被保存（即不可变），通过建立副本表示各种修改。实现不可变性之后，与锁相关的所有问题就不存在了。并非每个数据结构都是稳定的，但是大多数广泛使用的数据结构都有变体，它们会保持对应的可变版本的 big-O 效率（关于 big-O 表示法的更多信息请参见 参考资料 中的链接） 其实纵览下来. 最重要的有两种模型. 一种是Actor . 还有一种是没有详细介绍的底层的元组空间模型 .这种模型暂时不是很了解. 其他的模型应该还是有待进一步改善 或者 完善的.. |
| 返回顶楼 | |
|
发表时间：2009-09-22
最后修改：2009-09-22
Saito 写道 其实这也是大牛们为啥都紧盯着paper不放的原因. Google不就是从paper中来的么..
另推荐一下O'Reilly Open Source Convention(OSCON)的讨论精华. 引用 并发构造纵览
。
Ted Leung 一直是一位有趣的演讲者 — 他为动态编程语言社区做了许多工作，尤其是在 Python 方面。他的演讲详细讨论了多种并发方法；其中一些是大多数读者熟悉的，但是一些方法对于主流计算机科学课程和实践程序员来说相当深奥。Leung 列举了六七种并发模型 或范型。 大多数程序员最熟悉的并发模型是线程化。大家同样熟悉线程化的问题：锁冲突和死锁。在一般情况下，用锁实现的并行总是需要开发人员做大量显式的计划工作。其他方法虽然都有缺陷，但是大都支持更高层的抽象，避免显式地锁住资源。 一种并发方法是软件事务性内存，这在 Haskell 中已经比较普遍了。 这种方法按照与事务性数据库系统相似的方式对待内存，也就是操作保持原子性，在发生请求冲突时执行回滚和重试。 事务性内存可能导致重复计算，但是在操作冲突不多的情况下，开销仍然比锁机制低。 另一个模型是 Actor 模型，这在 Erlang 中尤其知名（但是 Leung 谨慎地指出 Actor 模型和 Erlang 的发展是相互独立的）。Actor 模型基本上是 “不共享任何东西” 体系结构，在向其他 Actor 发出请求时 Actor 总是传递自含的消息。在去年的 OSCON 上，我写过一份关于 Actor 的讲稿。 Leung 提到了 Linda 和 ParallelR 底层的元组空间模型，但是由于时间的限制，并未详细讨论。在这种模型中，任务按空间和时间分隔开，读和写也是分开的。 Leung 还提到了 Bill Ackerman 的 “数据流” 概念，这个概念支持声明式并发。这种方法的问题是，尽管它对问题进行划分，但是无法处理非确定性因素（也就是说，它只适合纯功能性语言）；如果需要处理真实的非确定性因素（比如输入和输出），就需要 Actor。 Leung 讨论的最后一种模型是持久化数据结构。这是一个不完整的模型；它不能解决所有并发问题。但是，它是一种良好的措施。这种模型很早就出现了，但是在最近一两年，由于在 Clojure 语言中的应用开始流行了。基本思想是所有数据结构都被保存（即不可变），通过建立副本表示各种修改。实现不可变性之后，与锁相关的所有问题就不存在了。并非每个数据结构都是稳定的，但是大多数广泛使用的数据结构都有变体，它们会保持对应的可变版本的 big-O 效率（关于 big-O 表示法的更多信息请参见 参考资料 中的链接） 其实纵览下来. 最重要的有两种模型. 一种是Actor . 还有一种是没有详细介绍的底层的元组空间模型 .这种模型暂时不是很了解. 其他的模型应该还是有待进一步改善 或者 完善的.. 除了数据流之外,绝大部分的模型其实还是currency的问题.并行这个东西跟编程设施没有什么具体的关系了,关键是算法和硬件设施.很多问题不是说你只要把串行程序原封不动地搬到thread里面去就能并行了,而是要对原来的问题从新设计算法。做惯上层应用开发的人都喜欢从直观的角度去设计算法。除了很简单的情况,这样做出来的算法,看上去是可以并行计算的。但是复杂度可能与串行相当甚至还要高。在并行这个行当里就这个就叫做naive algorithm. 还有很多问题有并行的解决方法,但是在现在的cpu和os架构上就没法做.比如一个问题单线程处理2毫秒,理论上可以分成1000份来做,但是你在cpu和os级别上就没法干,thread的线程切换和锁的消耗可能都比2毫秒要高.都需要通过一些特殊的硬件去完成,现在的GPU可以分担一些但是也很有限。所以有人说，真正关心性能的人都是自己设计硬件的。 至于tuplespace那个东西，基本上就是分布式计算的问题.在大尺度的并行上还是可以用的，但是我们有什么计算需要大尺度并行呢？寻找外星人，计算蛋白质?貌似都不是我们能干的东西。 一般来讲,留给应用程序开发层面解决的问题都是IO密集型的问题,计算密集型的问题都不太可能留给应用型的程序员去开发，他们不会干也干不好,他们最后应该看到的只是一个个library而已. |
| 返回顶楼 | |
|
发表时间：2009-09-22
最后修改：2009-09-22
昨夜山风空灵，我顿悟了。所谓函数式语言就是"映射语言"。跟printf()那种函数八杆子打不着。我被骗了。人家function的意思是“作用”的意思。都说软件业要卖service，意思确实还是软件行业是服务行业的意思。软件不可能是瞬生瞬灭的service。软件是server。想要服务就要有命令，哪需要那劳什子的映射。想fp都干些什么，负载均衡是映射，lisp曾用来干的所谓的AI——定理证明是映射（就是希尔伯特那帮人集合论里闭集合里的定理自推），还有数据库，想当年我就是被fp与SQL同构等那些小魔术骗得一愣一愣的。数据库又不是操作库，明显是映射，与sql同构了有什么了不起的。
我倒是给fp出个主意吧，不嫌麻烦，就写编译器吧，那才是你该干的事。 软件行业呢，既然咱卖的是服务，就老老实实的一条命令一条命令地垒server吧。 话说这潭水是多核搞浑的。本来命令式写得好好的，为了并行，不得不抬起头来左顾右盼邻居家fp是不是有啥招。确实，映射可以并行。但那顶个啥用，我们需要的是命令——祈使句。CPU厂商把电子逼到死路，光子还弄不出来，就把多核交付出来对付，根本就是胶着在一起的多台机器嘛。自从这个星球上有了第二个微生物，“人”与“人”之间便再也不可能没有交流障碍了。 在强人工智能出现之前，我怀疑通用计算机根本不可能自动并行化。因为我们还处于一条一条地教计算机怎么干活的阶段。是我们YY了，多核这趟车很难指望搭上便车。 多核与并行是不同的，GPU浮点渲染管线本就是并行的。以后的计算机能力提高要靠异构(GPU不是通用处理器，游戏编程就是异构的)以及重构(指的是硬件动态重构)了，本游戏coder专用的GPU也开被始其它专业程序描上了，但是通用程序想搭上这车，这个也够呛吧。。。。 说着说着都快把自己绕进去了。STM，学习了，现在似乎懂了，又似乎不懂。同意偶像观点，既然自动并行化不可行，普通程序员可能也没必要操并行这份心了吧。 update: 数字电路分组合逻辑电路和时序电路。组合逻辑电路是并行，但是时序电路是串行。于是VHDL（Ada的同门师弟，一种硬件描述语言）里面也有所谓的pure function和副作用函数。组合逻辑，包括累加器，都是靠映射去暴力实现的，并不是像机械计算机一样地在那里真正地累加。于是，发生了并行->串行->还想再并行的尴尬局面。再于是，开始掀开冯诺依曼机，绕过时序。 |
| 返回顶楼 | |
|
发表时间：2009-09-23
我坦白 计算密集型轮不到我做 只能做IO密集
|
| 返回顶楼 | |
