Bjarne说：以降低抽象惩罚来获得性能的语言设计思路仍然不会消失

[pongba]

以下是Bjarne的回复部分文字：

I think we need quite general and generic interfaces between concurrent
tasks, but the individual processors are not getting any faster - in
fact they are getting slower, being optimized for chip space and power
consumption - so that low abstraction penalty could become *more*
important for tasks that are not easily parallelized (and that is a lot
of tasks).

注意，Bjarne的想法很有趣，他的意思是虽然并行CPU的性能变高了，然而单个CPU的性能却实际上在降低（芯片空间的优化和功耗的降低），再加上另一个因素——即存在大量的无法容易地并行的程序（pongba按：这个观察我不能确定，有谁能够说说的？我怎么感觉真正需要高——我是说非常高——性能的地方肯定都是大数据量处理的地方呢，而数据处理正是并发的拿手好戏吧——但我还是不确定），那么结论就是，对于那些无法容易地通过并行来提速的程序，实际上"零惩罚"的抽象模型却反而会变得更重要了。

当然，我觉得这个结论并不代表从传统的侵入式接口到非侵入的dynamic GP的major shift不会在主流应用开发或更上层开发发生，实际上，已经在发生了。我认为这最多能说明，零惩罚的语言抽象模型仍会长期有用武之地（？）。

以下是我的邮件部分文字（其中的观点老莫已经在一篇post里面详细总结了，见 http://blog.csdn.net/longshanks/archive/2007/12/06/1921273.aspx，所以你可以忽略下面的文字）另：Bjarne的论文页面上出现了一篇新的论文，是关于运行期（动态）concept的，论文还没有放出来，但老大发给我了，要看的可以发邮件给我，不看不要问我要，看了要提提意见（因为论文要到明年3月才发表，所以现在还在DRAFT阶段），我会转告Bjarne你的意见。

> I think the old-fashioned intrusive interface is no more than a
> compromise to efficiency, sooner or later all that will be left is
> Runtime Generic Programming.

看来Bjarne也是认同这一点的。我们学习OO的时候一开始就适应了侵入式接口，乃至于觉得是天经地义了，而实际上侵入式接口正导致了许多对OO的抨击，如Eric Raymond的"粘合层过重"的说法、"紧耦合"的说法。

> I think the prevalence of parallel programming will have a big impact
> on the way programming languages drain efficiency (i.e. instruction
> cycles) from machines. That is, in old times, we design languages that
> have low abstraction penalties ( e.g. intrusive interfaces, value-type
> build-ins, build-in arrays) to make the cost of abstraction as low as
> possible thus making the language as efficient as possible, but I
> guess when the time comes where the efficiency-gain the "low (or zero)
> abstraction penalties" brings doesn't matter that much anymore because
> of the even bigger gain parallel programming brings, the design of the
> languages will face a major shift where intrusive interfaces will be
> thrown away, and mechanisms like Runtime Concepts (non-intrusive
> interfaces) will take over.
>
> As long as low abstraction penalty doesn't make that much sense in the
> world of parallel programming, the compromises (e.g. intrusive
> interface) the languages have made in order to lowering the
> abstraction level will become pure obstacles that have no significant
> benefits.
>
> Do you think that's true? Do you think the prevalence of parallel
> programming will have such an impact on language design? If so, how
> long will it take to reach that major point? If not, why not?

--
刘未鹏(pongba)|C++的罗浮宫
http://blog.csdn.net/pongba
TopLanguage
http://groups.google.com/group/pongba

[莫华枫]

我觉得他似乎再说：无论我们怎么努力，不可能完全达到最完美的抽象形式。对于性能的考虑依然会存在。比如，我们依然还是需要static unbound，用来在不需要runtime多态场合获得最好的性能。关键是，static和runtime unbound组合把抽象惩罚限制在我们可以接受的范围内。但抽象惩罚依然还会存在。比如，static concept和runtime concept之间的互动可能会是件比较麻烦的事情。如果我们只用runtime unbound，事情会简单得多。但是，由于两种concept足够接近抽象的本质，所产生的抽象惩罚我们还是可以承受的。或许将来也会有某种语言，不再考虑性能的问题，单纯使用runtime unbound，就像现在的java把对象彻底虚化那样，以获得更简单的抽象体系。对抽象惩罚的容忍程度，可能也会根据不同的应用和用户不断变化的吧。
不管怎么样，我的感觉是：现在的gp领域就像黄石公园地下的大熔岩池，酝酿着威力巨大的爆发。

btw1：老大的那份论文能给我一份吗？拜读一下。
btw2：看到又有人管我叫"老莫"，就好象又回到了小学时代。:P

--
反者道之动，弱者道之用
m...@seaskysh.com
longsh...@gmail.com
http://blog.csdn.net/longshanks/

[pongba]

以下是Bjarne的进一步回复：

Remember: It costs thousands of instructions to start up a task
on a processor and to get the result back, so there is a huge win in
being able to execute in less instructions so that no spawning is
needed. It's just like inlining vs function call (the function call
pre-and postamble costs). Also, more and more, we are going to measure
speed in memory accesses rather than instructions - instructions are
getting really cheap. Currently *every* multiprocessor/multicode is
memory bandwidth limited - and also most single processors.

On Dec 7, 2007 11:43 AM, pongba < pon...@gmail.com> wrote:

[pongba]

On Dec 7, 2007 12:53 PM, 莫华枫 <longsh...@gmail.com> wrote:

我觉得他似乎再说：无论我们怎么努力，不可能完全达到最完美的抽象形式。对于性能的考虑依然会存在。比如，我们依然还是需要static unbound，用来在不需要runtime多态场合获得最好的性能。关键是，static和runtime unbound组合把抽象惩罚限制在我们可以接受的范围内。但抽象惩罚依然还会存在。比如，static concept和runtime concept之间的互动可能会是件比较麻烦的事情。如果我们只用runtime unbound，事情会简单得多。但是，由于两种concept足够接近抽象的本质，所产生的抽象惩罚我们还是可以承受的。或许将来也会有某种语言，不再考虑性能的问题，单纯使用runtime unbound，就像现在的java把对象彻底虚化那样，以获得更简单的抽象体系。对抽象惩罚的容忍程度，可能也会根据不同的应用和用户不断变化的吧。
不管怎么样，我的感觉是：现在的gp领域就像黄石公园地下的大熔岩池，酝酿着威力巨大的爆发。

我觉得他不是这个意思。首先，他认同侵入式的接口（以及比如内建类型、值类型、有限精度整数）的确是面向性能的折衷，最直观的形式应该是像现在的concept这样的非侵入式接口（而且还要是动态的——不然他写这篇论文干嘛？）。然后，他指出一个事实，就是由于串行编程还有很大空间，所以通过折衷抽象机制来减小抽象惩罚从而获得性能的做法仍有用武之地，因此，C++里面的一动一静、一侵入一非侵入、一OO一GP的分野依然不会消除。

（不过像Java/C#这类处于应用层面的语言迟早会把老旧的interface踢进垃圾箱，走向ruby那样的duck typing。）
 

btw1：老大的那份论文能给我一份吗？拜读一下。

已发:-)

btw2：看到又有人管我叫"老莫"，就好象又回到了小学时代。:P

What's the story like? :)

[莫华枫]

On Dec 7, 2007 1:06 PM, pongba <pon...@gmail.com> wrote:

On Dec 7, 2007 12:53 PM, 莫华枫 <longsh...@gmail.com> wrote:

我觉得他似乎再说：无论我们怎么努力，不可能完全达到最完美的抽象形式。对于性能的考虑依然会存在。比如，我们依然还是需要static unbound，用来在不需要runtime多态场合获得最好的性能。关键是，static和runtime unbound组合把抽象惩罚限制在我们可以接受的范围内。但抽象惩罚依然还会存在。比如，static concept和runtime concept之间的互动可能会是件比较麻烦的事情。如果我们只用runtime unbound，事情会简单得多。但是，由于两种concept足够接近抽象的本质，所产生的抽象惩罚我们还是可以承受的。或许将来也会有某种语言，不再考虑性能的问题，单纯使用runtime unbound，就像现在的java把对象彻底虚化那样，以获得更简单的抽象体系。对抽象惩罚的容忍程度，可能也会根据不同的应用和用户不断变化的吧。
不管怎么样，我的感觉是：现在的gp领域就像黄石公园地下的大熔岩池，酝酿着威力巨大的爆发。

我觉得他不是这个意思。首先，他认同侵入式的接口（以及比如内建类型、值类型、有限精度整数）的确是面向性能的折衷，最直观的形式应该是像现在的concept这样的非侵入式接口（而且还要是动态的——不然他写这篇论文干嘛？）。然后，他指出一个事实，就是由于串行编程还有很大空间，所以通过折衷抽象机制来减小抽象惩罚从而获得性能的做法仍有用武之地，因此，C++里面的一动一静、一侵入一非侵入、一OO一GP的分野依然不会消除。

（不过像Java/C#这类处于应用层面的语言迟早会把老旧的interface踢进垃圾箱，走向ruby那样的duck typing。）

虽说踢是早晚的事，不过还是需要过程的。这不，csdn论坛上有人文章都没仔细，就开始踹门了。

 

btw1：老大的那份论文能给我一份吗？拜读一下。

已发:-)

收到，谢了。

btw2：看到又有人管我叫"老莫"，就好象又回到了小学时代。:P

What's the story like? :)

呵呵，那时候几个玩得好的叫我"老莫" 。而我老爸在单位里，人家叫他"小莫"。:-D

--
刘未鹏(pongba)|C++的罗浮宫
http://blog.csdn.net/pongba
TopLanguage
http://groups.google.com/group/pongba

[pongba]

On Dec 7, 2007 1:18 PM, 莫华枫 <longsh...@gmail.com> wrote:

On Dec 7, 2007 1:06 PM, pongba <pon...@gmail.com> wrote:

On Dec 7, 2007 12:53 PM, 莫华枫 <longsh...@gmail.com> wrote:

我觉得他似乎再说：无论我们怎么努力，不可能完全达到最完美的抽象形式。对于性能的考虑依然会存在。比如，我们依然还是需要static unbound，用来在不需要runtime多态场合获得最好的性能。关键是，static和runtime unbound组合把抽象惩罚限制在我们可以接受的范围内。但抽象惩罚依然还会存在。比如，static concept和runtime concept之间的互动可能会是件比较麻烦的事情。如果我们只用runtime unbound，事情会简单得多。但是，由于两种concept足够接近抽象的本质，所产生的抽象惩罚我们还是可以承受的。或许将来也会有某种语言，不再考虑性能的问题，单纯使用runtime unbound，就像现在的java把对象彻底虚化那样，以获得更简单的抽象体系。对抽象惩罚的容忍程度，可能也会根据不同的应用和用户不断变化的吧。
不管怎么样，我的感觉是：现在的gp领域就像黄石公园地下的大熔岩池，酝酿着威力巨大的爆发。

我觉得他不是这个意思。首先，他认同侵入式的接口（以及比如内建类型、值类型、有限精度整数）的确是面向性能的折衷，最直观的形式应该是像现在的concept这样的非侵入式接口（而且还要是动态的——不然他写这篇论文干嘛？）。然后，他指出一个事实，就是由于串行编程还有很大空间，所以通过折衷抽象机制来减小抽象惩罚从而获得性能的做法仍有用武之地，因此，C++里面的一动一静、一侵入一非侵入、一OO一GP的分野依然不会消除。

（不过像Java/C#这类处于应用层面的语言迟早会把老旧的interface踢进垃圾箱，走向ruby那样的duck typing。）

虽说踢是早晚的事，不过还是需要过程的。这不，csdn论坛上有人文章都没仔细，就开始踹门了。

 

btw1：老大的那份论文能给我一份吗？拜读一下。

已发:-)

收到，谢了。

btw2：看到又有人管我叫"老莫"，就好象又回到了小学时代。:P

What's the story like? :)

呵呵，那时候几个玩得好的叫我"老莫" 。而我老爸在单位里，人家叫他"小莫"。:-D

呵呵，有趣有趣:-)

[莫华枫]

我刚才想到。实际上程序员选择语言，就是在评估对抽象和性能之间的关系。应用层面的程序员忍受不了c/c++的抽象惩罚，转而使用python、ruby。而性能对他们没什么关系。最底层开发的程序员无所谓抽象如何，关键是性能好。因而侧重于C。两者都需要的，那么C++相对更合适。两者都无所谓的，就...
现在的程序员对抽象惩罚越来越敏感，而对性能越来越麻木。所以就导致了越来越多的程序员选择Java之类的语言。
现在在runtime concept方面的努力，则是力图再不损失什么性能的情况下，消除一些抽象惩罚，以迎合程序员的这种心理。

[Atry]

我不同意。我是 C++ 的死忠。虽然我反对 C++ 的现状，但是我忠于 C++ 的精神。
C++ 的精神是什么？就是完美主义。我们坚信"零开销"原则。我们决不妥协！
对我们来说，问题不在于有没有必要"零开销"，而在于能不能做到"零开销"。Bjarne
老大不用遮遮掩掩说什么"降低抽象惩罚"，把话挑明吧，一切抽象惩罚都可以绝对的、完全的避免！

在 07-12-7，莫华枫<longsh...@gmail.com> 写道：

[pongba]

On Dec 7, 2007 2:09 PM, 莫华枫 <longsh...@gmail.com> wrote:

我刚才想到。实际上程序员选择语言，就是在评估对抽象和性能之间的关系。应用层面的程序员忍受不了c/c++的抽象惩罚，转而使用python、ruby。而性能对他们没什么关系。最底层开发的程序员无所谓抽象如何，关键是性能好。因而侧重于C。两者都需要的，那么C++相对更合适。两者都无所谓的，就...
现在的程序员对抽象惩罚越来越敏感，而对性能越来越麻木。所以就导致了越来越多的程序员选择Java之类的语言。
现在在runtime concept方面的努力，则是力图再不损失什么性能的情况下，消除一些抽象惩罚，以迎合程序员的这种心理。

抽象惩罚：抽象机制带来的效率降低。例如，虚函数是一种抽象机制，带来的效率降低是至少一个间接调用的开销。

老莫，怎么觉得你所说的抽象惩罚不是这个意思呢？

[pongba]

On Dec 7, 2007 3:10 PM, Atry <pop....@gmail.com> wrote:

我不同意。我是 C++ 的死忠。虽然我反对 C++ 的现状，但是我忠于 C++ 的精神。
C++ 的精神是什么？就是完美主义。我们坚信"零开销"原则。我们决不妥协！
对我们来说，问题不在于有没有必要"零开销"，而在于能不能做到"零开销"。Bjarne
老大不用遮遮掩掩说什么"降低抽象惩罚"，把话挑明吧，一切抽象惩罚都可以绝对的、完全的避免！

生活是残酷的，今天博者神龟的话题是：鱼和熊掌不可兼得。

既要完美的抽象，又要完美的效率；我觉得不可得。比如吧，template是一个抽象机制，它没有任何效率惩罚，因为在代码生成上相当于宏。然而，template是静态的，那么到了需要用到动态场合的时候，就挂了。那么你会说，那动态的时候就用接口便是了。问题是concept和interface实际上是完全一样的抽象机制，只不过一个在静态世界下工作，一个在动态世界下工作，这种精神分裂很是不爽。比如在C++里面我想让一个模板函数能够运用到运行期，不修改实现代码是不行的，就算修改源代码，也还要费上牛劲。而如果实现两套版本呢还是不优雅。反过来，一个依赖于接口实现的动态版本，由于接口的侵入式，导致composability（可组合性）又不好。一个实践中的例子见Jaakko Jarvi的paper（ Runtime Polymorphic Generic Programming.pdf）。

[Atry]

疯狗现在继续咬人！
我们用虚函数，我们用模板，但我们无视 OO 和 GP ！
什么 concept！什么 interface！全是纸老虎！
抽象等于零！
唯有透明是真谛！

在 07-12-7，Atry<pop....@gmail.com> 写道：

[Atry]

侵入性的问题只需要一个极小的语言改动就可以解决：

struct A {
void xxxx();
};
struct IA {
virtual void xxxx() = 0;
};
struct AImplementIA : A, IA {};

就目前的 C++ 而言，AImplementIA并没有实现 IA::xxxx 方法，但假若 C++ 允许这样实现的话，那么问题就解决了。

在 07-12-7，pongba<pon...@gmail.com> 写道：

[pongba]

是的，你说的AImplementIA其实就是concept_map，目前concept_map没有用vtable类似的机制来实现。如果实现了，那么C++09的concept就dynamic了（开销是virtual call的开销）。

http://groups.google.com/group/pongba

[莫华枫]

啊！我理解反了。我理解成：抽象能力降低，因而给程序员的惩罚。
闹笑话了。不好意思。这两天晚上儿子闹，没睡好...
&*%#~^^#&*$

[莫华枫]

嗨，一回事。就是concept_map，只是换个形式而已。
反正有了这种东西，A就不需要再从IA上继承了。IA变成独立于A的vtable，那么也就不需要virtual了。为了区分IA和A的差别，给它冠以concept，这就是runtime concept

On Dec 7, 2007 3:30 PM, Atry < pop....@gmail.com> wrote:

[pongba]

我提到的那篇Bjarne的新文章，正式把这个命名为runtime concept惯用法...

[oldrev]

CPU就算有1G个内核，大部分时间还是在等内存和IO，并行的好处不是太明显。

在07-12-7，pongba <pon...@gmail.com> 写道：

[liang]

这个思路是正确的。
对于Windows程序员而言，为什么不迁移到.NET平台？驻留的主要原因是性能。如果C++的抽象机制损害了性能，那么程序员将被迫使用C，或者直
接利用C#。

CSDN上有Anderi的访谈视频，他认为C++的应用场景在：一方面需要性能，一方面需要抽象。这种需求，就要求C++按照现在的思路发展下去。他
还认为，C++适用于较大型的团体，适用于参差不齐的开发者。这一点从ATL上可以看出来。ATL显然是追求性能的，否则在.NET时代也不会持续发
展。同时ATL也提高了抽象层次，屏蔽了许多COM的复杂性，使得更多的程序员可以较快速地开发native程序。

许多时候，看语言不能用纯技术的观点啊。

On 12月7日, 上午11时43分, pongba <pon...@gmail.com> wrote:
> 以下是Bjarne的回复部分文字：
>
> I think we need quite general and generic interfaces between concurrent

> tasks, *but the individual processors are not getting any faster - in

> fact they are getting slower, being optimized for chip space and power
> consumption - so that low abstraction penalty could become *more*
> important for tasks that are not easily parallelized (and that is a lot

> of tasks).*
>
> 注意，Bjarne的想法很有趣，他的意思是虽然并行CPU的性能变高了，然而单个CPU的性能却实际上在降低（芯片空间的优化和功耗的降低），再加上另一个因-素----即存在大量的无法容易地并行的程序（pongba按：这个观察我不能确定，有谁能够说说的？我怎么感觉真正需要高----我是说非常高----性能的地方肯定都是-大数据量处理的地方呢，而数据处理正是并发的拿手好戏吧----但我还是不确定），那么结论就是，对于那些无法容易地通过并行来提速的程序，实际上"零惩罚"的抽象-模型却反而会变得更重要了。

>
> 当然，我觉得这个结论并不代表从传统的侵入式接口到非侵入的dynamic GP的major
> shift不会在主流应用开发或更上层开发发生，实际上，已经在发生了。我认为这最多能说明，零惩罚的语言抽象模型仍会长期有用武之地（？）。
>

> 以下是我的邮件部分文字（其中的观点老莫已经在一篇post里面详细总结了，见http://blog.csdn.net/longshanks/archive/2007/12/06/1921273.aspx
> ，所以你可以忽略下面的文字）另：Bjarne的论文页面上出现了一篇新的论文，是关于运行期（动态）concept的，论文还没有放出来，但老大发给我了，要-看的可以发邮件给我，不看不要问我要，看了要提提意见（因为论文要到明年3月才发表，所以现在还在DRAFT阶段），我会转告Bjarne你的意见。

>
> > I think the old-fashioned intrusive interface is no more than a
> > compromise to efficiency, sooner or later all that will be left is
> > Runtime Generic Programming.
>

> 看来Bjarne也是认同这一点的。我们学习OO的时候一开始就适应了侵入式接口，乃至于觉得是天经地义了，而实际上侵入式接口正导致了许多对OO的抨击，如E-ric

> Raymond的"粘合层过重"的说法、"紧耦合"的说法。
>
>
>
>
>
> > I think the prevalence of parallel programming will have a big impact
> > on the way programming languages drain efficiency (i.e. instruction
> > cycles) from machines. That is, in old times, we design languages that
> > have low abstraction penalties ( e.g. intrusive interfaces, value-type
> > build-ins, build-in arrays) to make the cost of abstraction as low as
> > possible thus making the language as efficient as possible, but I
> > guess when the time comes where the efficiency-gain the "low (or zero)
> > abstraction penalties" brings doesn't matter that much anymore because
> > of the even bigger gain parallel programming brings, the design of the
> > languages will face a major shift where intrusive interfaces will be
> > thrown away, and mechanisms like Runtime Concepts (non-intrusive
> > interfaces) will take over.
>
> > As long as low abstraction penalty doesn't make that much sense in the
> > world of parallel programming, the compromises (e.g. intrusive
> > interface) the languages have made in order to lowering the
> > abstraction level will become pure obstacles that have no significant
> > benefits.
>
> > Do you think that's true? Do you think the prevalence of parallel
> > programming will have such an impact on language design? If so, how
> > long will it take to reach that major point? If not, why not?
>
> --
> 刘未鹏(pongba)|C++的罗浮宫http://blog.csdn.net/pongba

> TopLanguagehttp://groups.google.com/group/pongba- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[up duan]

抽象未必带来惩罚。而且，实际上，只要我们做的好，抽象其实能够带来比不抽象更大的好处。Eiffel就是显著的例子。

不过，C++确实为了抽象付出了代价，而且，在可以预见的将来，这些代价还会继续付出。最明显的例子就是所谓的虚表机制。本来希望能够通过一次间接常数时间解决问题，结果在时间和空间上都付出了代价。看看Java的Escape优化，或者更早的Eiffel的全局分析。其实，C++很多代价的付出在于对环境作出的妥协，而现在环境已经改变，完全可以不再付出了。