巴解组织的辉煌与贫穷 - 页 3 1234567 新评论 TheXpert 2014.07.05 15:07 #21 Integer:实际上,测试的并不是编译器,而是解决同一问题的两种方法。冰箱如何嗡嗡作响并不重要,重要的是它如何结冰。这是一个被扔掉的问题,而且很吵...虚拟函数 从来都是内联的,所以在启用优化的情况下,如果切换做得好,用简单的例子来比较是没有意义的。那是一个。谁说OOP更快?更方便,更符合逻辑,但几乎没有更快。那是两个。如果你不喜欢它,就不要使用它。 Renat Fatkhullin 2014.07.05 15:07 #22 Integer: 之后又有两个测试变体,2--使用非空函数,3--使用唯一函数,结果相似。变体1仍在C#中进行,但结果却相反。我已经看到了这些选项。而且,它们也适合内联方案,并得到了很好的优化。与C#的变体显示了另一个由于对代码优化器工作的误解而产生的误导性错误。代码没有显示,dotnet编译器也有几倍的优化方法,可以像坚果一样破解测试样本的退化情况。我刚才给你举了一个简单的例子,就是在简单的情况下把虚拟函数转换成普通函数。我们也将启用这种优化(在像这个测试这样的简单情况下),你也会看到一个 "虚拟 "方法是如何突然超越一个直接方法的。 Dmitry Fedoseev 2014.07.05 16:10 #23 TheXpert:一个被抛出的问题和噪音...虚拟函数 从来都是内联的,所以在启用优化的情况下,如果切换做得好,用简单的例子来比较是没有意义的。那是一个。谁说OOP更快?更容易,更符合逻辑,但几乎没有更快。那是两个。如果你不喜欢它,就不要使用它。嗯,这根本不是一个问题。这只是一个有结果和结论的实验。我喜欢它,我不喜欢它。使用慢速而不是快速是不符合逻辑的。 Dmitry Fedoseev 2014.07.05 16:12 #24 Renat:我已经看到了这些选项。而且,它们也符合内联计划,并得到了很好的优化。与C#的变体显示了另一个由对代码优化器工作的误解而引起的误导性错误。代码没有显示,dotnet编译器有几倍的优化方法,可以破解像坚果这样的测试实例的退化情况。我刚才给你举了一个简单的例子,在简单的情况下,把虚拟函数转换成普通函数。我们也将启用这种优化(在像这个测试这样的简单情况下),你也会看到一个 "虚拟 "方法是如何突然超过一个直接方法的。似乎无论我得到什么结果都是错误的,都是误导性的。- 为了什么?- 印度人,先生。(xf 独行侠)尽管我尝试了很多,但没有办法让它比通过开关的虚拟方法工作得慢。试图这样做,但对不起,没有成功。 Dmitry Fedoseev 2014.07.05 16:20 #25 这里的附录是第一个C#测试。结果 是这样的 附加的文件: test.zip 66 kb Victor Nikolaev 2014.07.05 16:25 #26 证据将来自于另一方。或者再一次只是说说而已。总的来说,我只对事实感兴趣。 虽然我已经知道OOP比较慢,但它提供了相当具体的便利条件 TheXpert 2014.07.05 16:41 #27 Vinin:证据将来自于另一方。 证明什么? Victor Nikolaev 2014.07.05 17:06 #28 TheXpert: 证明什么? 安德烈,你有一种想要证明迪马是错误的愿望。然后把它们交给我。 Sergey Chalyshev 2014.07.05 17:12 #29 为什么要用OOP来编写玩具?) Renat Fatkhullin 2014.07.05 20:28 #30 无论如何,这个问题被提出来是件好事。我们一直在努力改进编译器及其优化器。现在我们将专注于优化虚拟方法的调用(许多虚拟方法可以变成直接方法)。 1234567 新评论 您错过了交易机会: 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符(不带空格) 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号,请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置,否则您将无法登录。 忘记您的登录名/密码? 使用 Google 登录
实际上,测试的并不是编译器,而是解决同一问题的两种方法。冰箱如何嗡嗡作响并不重要,重要的是它如何结冰。
这是一个被扔掉的问题,而且很吵...
虚拟函数 从来都是内联的,所以在启用优化的情况下,如果切换做得好,用简单的例子来比较是没有意义的。那是一个。
谁说OOP更快?更方便,更符合逻辑,但几乎没有更快。那是两个。
如果你不喜欢它,就不要使用它。
之后又有两个测试变体,2--使用非空函数,3--使用唯一函数,结果相似。变体1仍在C#中进行,但结果却相反。
我已经看到了这些选项。而且,它们也适合内联方案,并得到了很好的优化。
与C#的变体显示了另一个由于对代码优化器工作的误解而产生的误导性错误。代码没有显示,dotnet编译器也有几倍的优化方法,可以像坚果一样破解测试样本的退化情况。我刚才给你举了一个简单的例子,就是在简单的情况下把虚拟函数转换成普通函数。我们也将启用这种优化(在像这个测试这样的简单情况下),你也会看到一个 "虚拟 "方法是如何突然超越一个直接方法的。
一个被抛出的问题和噪音...
虚拟函数 从来都是内联的,所以在启用优化的情况下,如果切换做得好,用简单的例子来比较是没有意义的。那是一个。
谁说OOP更快?更容易,更符合逻辑,但几乎没有更快。那是两个。
如果你不喜欢它,就不要使用它。
嗯,这根本不是一个问题。这只是一个有结果和结论的实验。
我喜欢它,我不喜欢它。使用慢速而不是快速是不符合逻辑的。
我已经看到了这些选项。而且,它们也符合内联计划,并得到了很好的优化。
与C#的变体显示了另一个由对代码优化器工作的误解而引起的误导性错误。代码没有显示,dotnet编译器有几倍的优化方法,可以破解像坚果这样的测试实例的退化情况。我刚才给你举了一个简单的例子,在简单的情况下,把虚拟函数转换成普通函数。我们也将启用这种优化(在像这个测试这样的简单情况下),你也会看到一个 "虚拟 "方法是如何突然超过一个直接方法的。
似乎无论我得到什么结果都是错误的,都是误导性的。
- 为了什么?
- 印度人,先生。
(xf 独行侠)
尽管我尝试了很多,但没有办法让它比通过开关的虚拟方法工作得慢。试图这样做,但对不起,没有成功。
这里的附录是第一个C#测试。结果 是这样的
证据将来自于另一方。或者再一次只是说说而已。
总的来说,我只对事实感兴趣。
虽然我已经知道OOP比较慢,但它提供了相当具体的便利条件
证据将来自于另一方。
证明什么?
为什么要用OOP来编写玩具?)
无论如何,这个问题被提出来是件好事。
我们一直在努力改进编译器及其优化器。现在我们将专注于优化虚拟方法的调用(许多虚拟方法可以变成直接方法)。