硬件处理和软件处理之间的异同与边界

简介:
今天给一朋友回复邮件,主要内容是我最近两天的一个DxR Pro++的固化问题,他好像不明白我为什么一直避开查找树,其实我自己的也不明白,只是知道该避开,也就避开了,并且这还不够,同时避开的还有各种其它 的查找,排序,hash算法,几乎是一切算法都尽量让我避开了。所以,最终,我的DxR Pro固化设计虽然初步完成( 这个设计没有公开,也不准备公开,但是我觉得思想比方法更重要,而这种思想正是我在本文想阐述的 ),但是和我之前博客上所述的有所不同,在那篇文章中,我在某些情况下退回到了二分区间查找。
       我们来看看各种计算机算法,它们在做什么,以及是怎样做的。很显然,总结一句话就是:合理安排先做什么,再做什么的一个动作序列。这些序列是发生在一维时 间的流逝里面的,虽然目前有很多的并行算法,让人看起来好像时间变成了一个平面,但是只要这些算法是CPU实施的,当它们不能在分解的时候,算法还是在先 做什么,再做什么之间不断做决策。二分查找,快速排序,这些不都是典范吗?仔细分析一下冒泡排序,先做什么,再做什么,然后做什么...最后得到了结果。 一个动作直接就是问题的一部分。这完全符合我们人类的思维,因为我们在做任何事的时候,都是在不断决策先做什么,后做什么。这就是数学上的统筹学。
       硬件实现的高效等价方案以另一种完全不同的方式工作,它更加类似我们人类的大脑内部的神经网络的工作原理。由于对这个大脑工作原理的解释超出了我的能力范围,即便我真的懂,也不能指望在一篇周末将要结束的短文中阐释清楚,所以我还是直接说硬件吧。
       硬件工作时更像是势能的自发释放,这种释放的效果是事先确定的,完全自动进行。举一个例子,洪水泛滥的时候,水流沿着沟壑冲刷大地,造成的效果取决于哪里 高,哪里低,并且由于这种高高低低的不同,还会出现一些组合效果,比如一流分成两流,在一个低洼处再次合并,这就会加倍水流的冲击力,从而越过更高的地 方。你可以将这看成万众一心的万马奔腾。在一个大型的灌溉系统中,事先接好管道,挖好沟渠,然后在水源处放水,一切都是自动完成的,完全无人值守。如果按 照CPU的方式,必须事先准备好一些序列-注意不是挖好沟渠,然后依次执行这些序列,比如先浇灌A区,然后再浇灌B区,由于D区离B区更近,因此接下来浇 灌D区而不是C区...当然在更低的层次,比如具体的浇灌过程,事情是按照硬件的方式执行的。
       虽然CPU总是顺序地执行一个序列的每一条指令,但是在CPU内部,执行每一条具体指令的方式却是一个势能释放的过程,CPU设计者早就设计好了几个通用 的指令电路,所谓的RISC就是指CPU内部的电路仅仅实现了非常简单非常基本的几个指令,然后靠外部的不同组合形成不同的程序,完成不同的事情。这就是 程序设计的本质。对于诸如DxR Pro++固化这样的事情,事实上并不能按照程序设计的一般思路来进行,因为它是完全相反的一个过程,我要设计的是一个万马奔腾的势能释放的方案,我要做 的是挖沟填壑,开山辟土,而不是思考一个如何在既有的康庄大道上到达目的地的方案。
       硬件是死的,程序是活的。一旦沟壑确定,势能释放的效果就完全确定了,因此这块电路就不能再做它用,但是程序却是可以随意更改的,因为CPU内部虽然也是 遍布沟壑,也是死的,但是它们数量比较多,而且每一种达到的效果非常有限,可以通过不同的将它们组合的方式形成不同的效果。这种局面涉及到了一个很重要的 话题,那就是成本!
       挖沟填壑的成本非常之高,必须确定这种沟壑的势能释放效果是长期可用且有效的,否则就浪费了。而软件却是可以用非常低的成本重组序列的,如今程序员不是已 经快成为廉价劳动力了么?然而软件的性能和硬件直接布线的性能是没法比的,这也是一种代偿博弈,牺牲了性能,带来了灵活性。如今的程序员几乎都是在CPU 所框住的框架内寻求最佳的算法,因为直接用硬件布线来实现功能并不是他们可以决策的,因为这涉及到成本问题,也就是钱的问题,必须在程序员雇佣成本和投资 成本之间做一个完美的权衡。
       其实早就形成了一种所谓的“可编程硬件”,即内部的沟壑可以填平,然后重新挖沟,也就是硬件可以重新布线。这种东西的成本介于纯布线硬件和软件之间。但是 更加有意义的一件事是CISC和RISC之间的战争,它们几乎在划定软件和硬件边界的争夺中持续着遍布阴谋阳谋的惨烈对决,如今已经分不出它们的边界了, 也无法说出一款具体的CPU到底是哪个阵营的,就好像罗马帝国奔溃后的民族融合一样,也如五胡乱华过后的中华民族一般。柏拉图式的分类过时了,我只想说。

       在CPU上编程的程序员们也许会认为我是个小丑,说实话我就是,因为我懂的语言不多,不管是自然语言还是计算机语言,计算机语言而言,我只懂C,JAVA 以及一点脚本语言,C++是我不懂的,PHP也是我从来都没有学会过的,更别提什么LISP,perl,GO,易,D,。。。。了,自然语言而言,普通话 一般,家乡的方言由于离开太久也几乎只剩理论的东西了,交流有点磕巴,更别提什么多国外语了。但是如果要按照语言,架构,系统分类,我属于偏系统的那种 (有些人喜欢各种编程语言且精通很多,可以形而上地揭示这些语言之间的异同,设计思想等,这属于语言型的,有些人喜欢组合不同的组件,他们可以通过组合, 构建出精美的东西,虽然他们对每一个组件都不是深入理解的,这属于架构型的,还有一类人,比如我,喜欢深度研究某一特定领域,和广度型的架构相反,这属于 系统型的)。我觉得,一个团队要是在这三个类型的人当中各有一个,那几乎就无敌了,再加上一个干活打酱油的,够了,滴蜡人月神话....有点跑题了,写到 这里,感觉有点像在招聘,也有点像在自荐,更多的或许有点在装逼,不管怎样,这篇文章就此结束,家人在客厅看无聊的电视,我在卧室写无聊的文章。



 本文转自 dog250 51CTO博客,原文链接:http://blog.51cto.com/dog250/1676173


相关文章
|
安全 网络协议 架构师
带你读《思科软件定义访问 : 实现基于业务意图的园区网络》第二章软件定义访问体系结构2.5(一)
带你读《思科软件定义访问 : 实现基于业务意图的园区网络》第二章软件定义访问体系结构2.5
带你读《思科软件定义访问 : 实现基于业务意图的园区网络》第二章软件定义访问体系结构2.5(一)
|
机器学习/深度学习 存储 运维
带你读《思科软件定义访问 : 实现基于业务意图的园区网络》第二章软件定义访问体系结构2.3(七)
带你读《思科软件定义访问 : 实现基于业务意图的园区网络》第二章软件定义访问体系结构2.3
|
边缘计算
带你读《思科软件定义访问 : 实现基于业务意图的园区网络》第二章软件定义访问体系结构2.1
《思科软件定义访问 : 实现基于业务意图的园区网络》第二章软件定义访问体系结构2.1
带你读《思科软件定义访问 : 实现基于业务意图的园区网络》第二章软件定义访问体系结构2.1
|
安全 物联网 测试技术
带你读《思科软件定义访问 : 实现基于业务意图的园区网络》第二章软件定义访问体系结构2.6(一)
带你读《思科软件定义访问 : 实现基于业务意图的园区网络》第二章软件定义访问体系结构2.6
带你读《思科软件定义访问 : 实现基于业务意图的园区网络》第二章软件定义访问体系结构2.6(一)
|
安全 测试技术 数据安全/隐私保护
带你读《思科软件定义访问 : 实现基于业务意图的园区网络》第二章软件定义访问体系结构2.6(二)
《思科软件定义访问 : 实现基于业务意图的园区网络》第二章软件定义访问体系结构2.6
带你读《思科软件定义访问 : 实现基于业务意图的园区网络》第二章软件定义访问体系结构2.6(二)
|
机器学习/深度学习 安全 测试技术
带你读《思科软件定义访问 : 实现基于业务意图的园区网络》第二章软件定义访问体系结构2.5(二)
带你读《思科软件定义访问 : 实现基于业务意图的园区网络》第二章软件定义访问体系结构2.5
带你读《思科软件定义访问 : 实现基于业务意图的园区网络》第二章软件定义访问体系结构2.5(二)
|
安全 网络虚拟化 虚拟化
带你读《思科软件定义访问 : 实现基于业务意图的园区网络》第二章软件定义访问体系结构2.2
带你读《思科软件定义访问 : 实现基于业务意图的园区网络》第二章软件定义访问体系结构2.2
带你读《思科软件定义访问 : 实现基于业务意图的园区网络》第二章软件定义访问体系结构2.2
|
边缘计算 运维 安全
带你读《思科软件定义访问 : 实现基于业务意图的园区网络》第二章软件定义访问体系结构2.3(六)
带你读《思科软件定义访问 : 实现基于业务意图的园区网络》第二章软件定义访问体系结构2.3
带你读《思科软件定义访问 : 实现基于业务意图的园区网络》第二章软件定义访问体系结构2.3(六)
|
安全 网络安全 API
带你读《思科软件定义访问 : 实现基于业务意图的园区网络》第二章软件定义访问体系结构2.5(八)
带你读《思科软件定义访问 : 实现基于业务意图的园区网络》第二章软件定义访问体系结构2.5
|
存储 边缘计算 缓存
带你读《思科软件定义访问 : 实现基于业务意图的园区网络》第二章软件定义访问体系结构2.3(二)
《思科软件定义访问 : 实现基于业务意图的园区网络》第二章软件定义访问体系结构2.3(二)
带你读《思科软件定义访问 : 实现基于业务意图的园区网络》第二章软件定义访问体系结构2.3(二)