并行计算与逻辑无关性的讨论,喷点干活

中山野鬼 发布于 2013/08/14 02:44
阅读 390
收藏 0

并行计算,有广义的说法,也有狭义的说法,我不是理论出生,写代码这么多年,几种说法自己亲自写过,在设计过程中也一直学习理论,要tmd的喷并行计算,希望至少你理论和工程,两样沾一样,别听风就是雨的乱扯。

一段逻辑语言,要想并行,必须做到逻辑无关性。从向量指令,算了专业点名词simd指令,要喷我的也好去查一下后,了解清楚概念再阐述观点,到dimd指令。都需要逻辑无关性。逻辑无关性包括状态迁移无关和处理数据无关。如果两个指令流或者说状态迁移流是完全独立,但是它们的处理数据相关(实际逻辑是相关),则仍然无法做到并发,这是同步系统的核心问题(同步系统一定是至少两套逻辑无关的流,它们靠的是数据来同步的,不是靠调用,包括各种信号,所以进程创建进程这不是同步系统,它们运行后才可能是同步系统)。两个进程同步,就不是并行计算。

但,不是并行计算的系统不代表不能相对并行。计算机要想做到跟快的程序处理,两个思路

,一个增加代码的处理吞吐量,代码读取,解析,数据载入,执行,写出(寄存器)在编译阶段,尽可能实现局部无关的计算提前描述,使得能够提前进行,并且对相关性操作所针对的数据尽可能的延缓写出外存(就是电脑主板上内存条的数据,tmd,我看国外的一些论坛在讨论多线程在1 级cache和2级cache中读写机理,这才是搞性能程序的帖子,如果要讨论性能,我非常欢迎讨论这些东西,不是说我一定要讨论性能,但这里,连“内”存长哪都不知道的人,还整天喷性能,我说扯淡还说我乱喷,整天就乱扯什么连存储器都看不见的语言又快了)。包括多分支的无条件计算,并缓存结果,等判断逻辑到位后做选择。

另一种思路是对单一或不单一的计算,但面对不相关数据,并发处理。图像处理中,这个使用最为频繁,各种设计技巧也很成熟。无论是2d,3d处理,还是图像分析识别。硬件上也形成比较完善的解决方案。gpu的架构和cpu有很大区别。对应程序设计思想也有很大区别。map reduce这种老思想,早被专业的应用了。换了个名词而已,结果给一帮没用过的喷子认为可以解决一切。这个思想没有任何问题,问题在于我写过这种方式的代码,我知道它的特性,所以它不是万能的,你没写过,还反过来喷我不学习。这和大数据有毛线关系?最多叫做并发处理不相关数据。大数据,一个核心要解决的问题是,开放的数据源下,怎么计算使得计算结果逼近局部最优解,而停止计算。互联网上玩大数据,这个解决不了,要么你的结论是sb,要么你的系统就sb的跑。大数据强调的计算面向开放,没有上限的数据。tmd的不好好学习,大量数据计算下并发计算的提升方法,和大数据中多数据源的关联和置信度,就知道乱喷。别说这两个概念搞不清楚。就算你的大数据是大量数据计算下并发计算的提升设计,你倒是先喷喷逻辑无关性于代码片切割的原则和方法啊。喷来喷去就知道拿点所谓的商业应用。你把它的数据形式,和计算方式说出一二,我也算你论据存在,论点成立了。毛都没见过,就瞎扯。

同时更广一级的,两个同步进程,如果数据流是单向的,也可以通过增加缓存的方式,实现伪异步。但这个已经不是什么乱七八糟的“并行语言”所讨论的范畴。

从哲学上说,很多东西都是来来回回的。,说局部逻辑无关性的代码片的提取或组织,反倒在语言的文法中,上下文无关的形式文法无法直接实现,这需要后期的优化。因为你上下文无关,在要表达的逻辑存在时序上的相关性时,无法根据当前代码的上下文来进行选择性的处理。优化编译算法,和前面的语法分析正好反过来,要考虑到数据的生命周期,实际包括指令执行的延迟,和存储区域的作用范围。如果能用形式文法描述,这恰恰是需要上下文相关的文法。说来说去,编译器的性能优化就是在对现场资源的有效组织上,你上下文无关的语言怎么描述?另外很不幸的告诉这些不爱学习的小懒虫喷子,目前绝大多数或者可以说可实用的编程语言,都是上下文无关的。

而且优化编译,有一个是做不到的,就是当函数调用的流程是通过数据来决定的,而不是静态的,在这种情况下,编译器无法(先知)知道你处理数据大概率下程序流的主线分布。此时代码片组织优化无法完全处理。而程序编译执行后,代码的逻辑地址是固定的。无论你是动态调用还是静态调用,代码在那里就在那里了,就是重新加载程序,函数与函数的相对地址差也是固定的,你当你的电脑是孙悟空,说变就变。

而这个对于code cache非常重要。如果你不能改变代码的分布,那你就要尽量改变代码调用的规则,尽可能的少发生代码在code cache里相互擦写的概率。包括你写sql语言,去让mysql查询。如果中间有两个函数反复被调用,恰巧它们在cache里的存储位置又一样,则会出现反复擦写反复从下一级 cache,或外存读取的延迟。同样一套sql语言,因为你的表的组织关系变化,可能产生不同的执行实现。(整天不好好学习计算机实现原理,就知道拿新名词扯淡谁更快,有毛用,同样的数据库,为什么别人能玩的转,为什么跑你这就不行,包括java。动不动就靠升级的。做java好的团队,我还真不信它们有问题,就升级,它们的水平是靠架构体现的,不是靠什么语言体现的。而这个架构无论自己写还是用别人的,是靠系统设计水平体现,而不是靠知道多少包,类体现的。动不动有问题就说开内存,不考虑内在运行机理而调整自己的高级语言的逻辑组织方式,就是给你开内存,系统还是那个鸟样。内存扩大,是给定逻辑实现,在单位资源已知负载时,提升系统整体负载用的,这中间还有计算负载增加导致系统资源瓶劲的分析,且不谈还有计算节点增加导致计算同步(广义上的)调度复杂度提升的分析。这里有几个整天瞎胡闹的,回去先了解什么叫压力测试再喷我,是不是出了问题你还是要开内存,我特指没有技术水平的java程序员,我真不相信有水平的java程序员,动不动就说虚拟机空间不够,你动不动就丢垃圾,再多空间也不够,无非开完后,短期的没问题是因为你的程序没遇到需要丢更多垃圾的时候)

简单说,要想做到一个逻辑的完全无关是不可能的。多进程多任务且任务不相关,这个不谈。因为逻辑本身就包含了相关性。只有将一个逻辑描述语言中相关性的部分提取出,才能得到无关性部分,并充分利用硬件特性进行并行计算。而实际逻辑的描述,更多依赖程序设计者而不是编译器,因为最终设计目标是响应设计需求,这不是编译器做的事情,是程序员要做的事情。

最后总结一下,别和我扯淡“并行”计算语言。你如果没有“并行”计算的开发经验(至少我有),给你再好的语言也白搭。同时,任何所谓的“并行”计算语言的编译器,都需要可”并行“计算的逻辑描述才能实现可”并行“计算的任务。

妈的,今天真的怒了,好好的在这边想讨论点理论或者工程设计方法,给一帮什么都不懂,就知道乱扯名词的人乱喷。如果我说的观点中有错误,我提的概念有不准确的地方,说出来,我自然会承认错误。并改正。不讨论,不说出来怎么知道自己还有哪些不足? 但tmd明明是个锤子,非要说是个锯子,而且锯子长什么样还没见过,还非要在我这个用过锯子的木匠(且不谈我水平高低,至少知道差别)面前乱扯。都tmd的什么浮躁的心态啊。不肯沉下心来好好学习讨论编程设计思想和方法,就知道比工具,还乱扯。你tmd乱扯无所谓。我谈编程设计思想和方法,你要么就好好指出我的错误,我自然会改正,要么就别乱喷。

以下是话题补充:

@中山野鬼:另外补充,随便一帮小懒虫说我学不学。hadoop我是专门研究过的。就是个玩具,如果想技术上讨论我欢迎。至于hadoop是个傻x不是我一个人在说。看看哪些反对hadoop的论点,它们中的大部分是正确的。 (2013/08/14 03:29)
加载中
1
mallon
mallon
看卤煮的发帖时间,只能讲四个字了:注意身体
0
ueharaai
ueharaai

对产品来说,有成熟的方案就用成熟的方案,没有成熟的方案才考虑自己做方案。

而方案这东西,没有最好的,只有最合适的。

最合适的不止是业务,还和参与的人有关,一头狮子带领一群羊的作战方式和一头狮子带领一群狮子的作战方式肯定是不一样的。此外,时间,地点,投资方,市场前景等等因素都会左右方案的选择。

没有共同的前提说一个东西是好是坏就等于鸡同鸭讲,历史上确实出现过一些很糟糕的选择,现在的时期,虽不说最好,也不算最差吧。

没接触过hadoop,不知道是真好还是炒作出来的,只希望别像java那样忽悠人了。

0
乌龟壳
乌龟壳
函数式的程序语言貌似比较容易自动转并行运算的样子。虽然整篇文章貌似都没看懂。
0
DISSECTOR
DISSECTOR

最近与一个近10年经验的web程序员面试,业务逻辑设计与基本编码技巧基本过关,但如缓存,DB,数据分析等自称有研究的技术点都无法深入探讨下去,完全是跟风,没有一点干货,还言必称Hadoop。

其特点是:每2-3年就换一次工作,行业选择上随波逐流,还完全归因于外部因素。

只能客客气气好走不送。

无论自欺还是欺人,出来混,总要还,现实会给这类人教训,我不会浪费时间去教化众生,除非对方真有好学之心。

0
中山野鬼
中山野鬼

引用来自“郭煜”的答案

函数式的程序语言貌似比较容易自动转并行运算的样子。虽然整篇文章貌似都没看懂。
这需要对可并行的计算进行并行计算的拆分。
0
中山野鬼
中山野鬼

引用来自“ueharaai”的答案

对产品来说,有成熟的方案就用成熟的方案,没有成熟的方案才考虑自己做方案。

而方案这东西,没有最好的,只有最合适的。

最合适的不止是业务,还和参与的人有关,一头狮子带领一群羊的作战方式和一头狮子带领一群狮子的作战方式肯定是不一样的。此外,时间,地点,投资方,市场前景等等因素都会左右方案的选择。

没有共同的前提说一个东西是好是坏就等于鸡同鸭讲,历史上确实出现过一些很糟糕的选择,现在的时期,虽不说最好,也不算最差吧。

没接触过hadoop,不知道是真好还是炒作出来的,只希望别像java那样忽悠人了。

这话不假,业务决定产品,产品决定技术,从团队的角度,技术服从业务,技术不对口的是通过咔嚓人调整人力组织来实现。客户的需求能实现是基础,而不是靠某种新型技术方案的实现为基础。
0
中山野鬼
中山野鬼

引用来自“DISSECTOR”的答案

最近与一个近10年经验的web程序员面试,业务逻辑设计与基本编码技巧基本过关,但如缓存,DB,数据分析等自称有研究的技术点都无法深入探讨下去,完全是跟风,没有一点干货,还言必称Hadoop。

其特点是:每2-3年就换一次工作,行业选择上随波逐流,还完全归因于外部因素。

只能客客气气好走不送。

无论自欺还是欺人,出来混,总要还,现实会给这类人教训,我不会浪费时间去教化众生,除非对方真有好学之心。

哈, 我现在越来越“迷信”学历了,有点那种新闻上“挖三代”的概念。学历好不好,与做事情是否踏实没有直接联系,不过大概率,他们有一定的比例关系。有些人天生脑袋反应慢的,其实也不错,会了一样,丢给他,也很放心,最怕就是你说这种,什么都碰一碰,碰到困难就换方向的。
0
IdleMan
IdleMan
并行了可能性能返回会降低。Hadoop感觉很火的样子
返回顶部
顶部