雄心勃勃的想法!!! - 页 5

 

Andrei01
:

你是错误的,因为你不知道最简单的事情。

任何阵列的数据都是以线性顺序存储在内存中的。从第一个到最后一个,为了寻址一个元素x[15],编译器将计算数组开始的地址加上移位15来计算这个变量的地址。对于一个二维数组,例如x[2][5],首先计算第二行的偏移量,然后再加上第5个元素的偏移量,也就是操作次数的两倍。

x[2] [5] --> x[((2-1)* ArrayRange(x[0])+5)] 。

x[15] --> x(+15)

这都是在编译器层面,但是对于静态数组来说,ArrayRange(x[0])永远是常数,它不需要一直计算,只需要在编译时保存一次。

如果你在做汇编,唉--我没有看到任何关于在比Pentium-I更老的处理器上正确加载指令流水线的俄罗斯文件,而且处理器的正确加载甚至不是由编译器的开发者搞的,而是由操作系统和处理器架构的开发者搞的。

如果你担心加法运算在处理器时钟周期内的执行时间会比加法运算更长,唉,这艘船已经随着486处理器起航了,加载缓存和指令流水线比算术和逻辑运算需要更多时间。

SZZY:我再次呼吁--开始阅读原始资料,这里https://www.mql5.com/ru/docs/basis/types/classes 开发者mql5描述了如何组织数据的排列,同样的信息适用于所有的编译器,有关于如何正确使用调用Windows的系统功能的信息,等等。 - 我写这篇文章是想说,在操作系统和处理器的现代能力方面,几乎没有俄罗斯的文件,而旧的东西,他们在学院和大学里教的东西,在操作系统和硬件发展的这个阶段并不符合现实。

 
IgorM:

x[2] [5] --> x[((2-1)* ArrayRange(x[0])+5)] 。

x[15] --> x(+15)

这都是在编译器层面,但静态数组的ArrayRange(x[0])始终是常数,不需要不断计算,只需在编译时计算并保存一次就够了。

在编译阶段只计算第一个元素的地址。所有其他元素将在计数模式下通过偏移量进行计数,偏移量每次都不同。

对于一个二维数组,你需要按列计算两个偏移量,按行数乘以行数,当然在计数过程中也是如此。汇编器和编译器与此完全无关,它只是一个基本的内存寻址,以便在实践中正确使用计算资源。

从这里你可以很容易地看到,即使一维数组和二维数组之间有如此大的性能损失,在更复杂的情况下,例如对象,寻址时间也会更明显地变慢。

 
Andrei01:

在编译时只计算第一个元素的地址。所有其他元素将通过一个偏移量在计数模式下被计数,这个偏移量每次都不同。

对于一个二维数组,你需要通过列和行乘以行号来计算两个偏移量,当然在计数过程中也要计算。Asembler和编译器与此完全无关,它只是一个基本的内存寻址,以便在实践中正确使用计算资源。

从这里你可以很容易地看到,即使一维数组和二维数组之间有如此大的性能损失,在更复杂的情况下,例如对象,寻址时间就更明显的慢了。


在了解发生的事情和生产力的损失方面取得的成功

我对优化编译器和编写自己的数据访问设计没有问题

SZY:对象不是复杂的情况--所有的操作都是为了创建链接--都是在编译器的层面上,唉,处理器并不关心对象与否,它对计算相对于对齐数据的移位没有问题,即使 "奇迹的程序员 "节省了内存--把数据写在像字节一样的数组中,但并不看编译器的文档,这种代码的有效性将只在镜子中的程序员自以为是的面容的反射中可见,但实际上这是一个假象。

 
IgorM:


一切都在编译器层面,但处理器并不关心它是否是一个对象,它对计算相对于对齐数据的偏移量没有问题。

似乎刚刚在一个简单的例子中向你解释了二维数组相对于一维数组在程序执行 过程中会有多慢,而不是在编译期间。我认为没有必要重复自己的观点。所以你看,你不把编写或多或少的最佳计算代码的任务过多地占用你的时间,也许你也不需要它。在这种情况下,OOP是为你创造的权利。:)

 

你在阿米巴类别中思考 :) 。

"我们应该 忘记小的效率,比如说大约97%的时间:过早的优化是万恶之源。 然而,我们不应放弃这关键的3%的机会"。

这是我第四次在这个论坛上被引用。

 
Andrei01:

似乎刚刚在一个简单的例子上向你解释了二维数组相对于一维数组在程序执行过程中会慢多少,而不是编译。我认为没有必要重复自己的观点。所以你看,你不屑于写或多或少的最佳计算代码,也许你也不需要它。在这种情况下,OOP是为你创造的权利。:)


我们谈论的是什么样的最佳代码?你完全不知道编译器和虚拟机是如何工作的

程序员不需要找出在每个特定的编译器中对物理内存元素的访问和寻址是如何进行的(即使是对角线,而不是列--在这里什么也做不了)--这是开发人员的任务,如果程序员对代码不满意--他将优化他的代码。

- 通过增加代码的大小和减少数据的大小而失去计算速度

- 通过增加代码中的数据大小,获得更高的速度

- 或者,他/她使用一个不同的编译器

所有选项都消失了!

OOP是编写EFFICIENT代码的另一个分支,OOP的有效性在于程序员可以以某种架构的形式创建一个数学模型--从而实现你的代码的极大通用性,如果你认为类对数据的物理访问有另一种寻址方式--你就错了,那微小的额外数据量--链接对象表不会以任何方式增加内存中物理数据的访问时间,额外数据将被多

我很震惊--你开始在OOP上拉屎,然后转向关于在多维和一维数组中寻址的争论--你在什么地方研究过这个,还是只是--所有的猜测和幻想?

使用多维 数组的工作早已在铁的层面上实现了--使用显卡工作时,同样的Z-缓冲区,啊,是的,"羊,铁的开发者"--没有咨询你,也没有了解多维数组的寻址效果如何,也没有咨询你--所有程序员在使用多维数组时都不假思索,在使用一维数组工作时也不会为了想象的效率而寻找增加代码的快乐。

 
Andrei01:
信息的可靠性是否取决于谁在介绍它?任何明智的人都应该明白,信息是客观的,而不是主观的。:)
而任何着手了解这个问题的人都会明白,信息,就像顺便说一下,它的数量,是一个主观的东西,而不是一个客观的东西。)
 
现代(尤其是64位)程序的效率在更大程度上由其开发环境和编译器决定。现代程序对CPU的性能和其代码的效率的依赖性较低。所有想知道为什么是这样而不是相反的人,请看E.Tanenbaum的不朽作品《计算机体系结构》,特别是第五章 "英特尔IA-64 "部分。与简单地过渡到正常的开发环境相比,旧编译器中的任何老式程序代码都不会给你带来这样的性能提升。怎么说呢,以汇编者为例。是的,这是个东西。毋庸置疑,它将永远活着。但我怀疑你是否能够用汇编写出IA-386代码,在性能上超过通常的IA-64代码,使用现代硬件资源,如多核处理器、扩展指令集等等。这就是为什么有一个结论--我们必须写进我们得到的东西。如果他们给了我们.NET,我们就必须用它来写。让成千上万的其他程序员去思考如何提高CIL代码的性能,如何将线程并行化,等等。MQL4也是如此,它的时代已经过去,我们有MQL5。 MetaQuotes将支持它。他们 会思考如何提高自己的语言表现。
 
IgorM:


如果程序员对代码不满意,他/她会优化自己的代码。

- 通过增加代码的大小和减少数据的大小而失去计算速度

- 通过增加代码中的数据大小,获得更多的速度

- 或者使用不同的编译器

所有选项都消失了!

代码优化 要求程序员对一个代码片段在执行基本操作(加法、乘法、内存访问、地址计算等)方面的资源密集程度有一个起码的了解。没有这一点,原则上就不可能进行优化,即使是最好的编译器也对这个可怜的程序员无能为力。这似乎是一件显而易见的事情,但我看到,这对许多程序员来说可能也是一个大新闻。:)

 
alsu:
而任何着手了解这个问题的人都会意识到,信息,如信息量,是一个主观的东西,不是客观的。)

好吧,你必须把不同的东西混淆并混入响尾蛇混合。:)

一个是信息源,是客观的,另一个是接收器,是主观的,因为它并不总是能够感知所有的信息,而只是部分信息。