¡¡¡Ideas ambiciosas !!! - página 5
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
Te equivocas porque no conoces las cosas más sencillas.
Los datos de cualquier matriz se almacenan en la memoria en una secuencia lineal. Del primero al último, y para dirigirse a un elemento x[15], el compilador calculará la dirección del principio del array más el desplazamiento 15 para calcular la dirección de esta variable. Con un array de dos dimensiones, por ejemplo, x[2][5], primero se calcula el desplazamiento de la segunda fila y luego se le añade el desplazamiento del 5º elemento, es decir, el doble de operaciones.
x[2] [5] --> x[((2-1)* ArrayRange(x[0])+5)]
x[15] --> x(+15)
todo esto es a nivel de compilador, pero ArrayRange(x[0]) para un array estático es SIEMPRE constante, no necesita ser calculado todo el tiempo, sólo una vez y guardado en tiempo de compilación
¿practicas ensamblador? ¿por qué estos problemas? si estás haciendo ensamblador, por desgracia - no he visto ninguna documentación rusa para la carga correcta de la tubería de instrucciones en los procesadores más antiguos que el Pentium-I, y la carga correcta del procesador no está comprometida ni siquiera por los desarrolladores de compiladores, sino por los desarrolladores del sistema operativo y la arquitectura del procesador
Si te preocupa que una operación de adición tarde más en ejecutarse en ciclos de reloj del procesador que una operación de suma, por desgracia, ese barco ha zarpado con el procesador 486, la carga de las cachés y los pipelines de instrucciones lleva más tiempo que las operaciones aritméticas y lógicas.
SZZY: Apelo una vez más - empezar a leer las fuentes primarias, aquí https://www.mql5.com/ru/docs/basis/types/classes desarrolladores mql5 describir cómo organizar la alineación de los datos, la misma información es para todos los compiladores, hay información sobre cómo utilizar correctamente llamar a las funciones del sistema de Windows, etc. - Escribo esto para decir que hay poca documentación rusa que se corresponda con las capacidades modernas del SO y de los procesadores, y lo antiguo, lo que enseñan en colegios y universidades, no se corresponde con la realidad en esta fase de desarrollo del SO y del hardware
x[2] [5] --> x[((2-1)* ArrayRange(x[0])+5)]
x[15] --> x(+15)
todo esto es a nivel del compilador, pero ArrayRange(x[0]) para el array estático es SIEMPRE constante, no necesita ser calculado constantemente, es suficiente calcular y guardar una vez en tiempo de compilación
En la fase de compilación sólo se calcula la dirección del primer elemento. Todos los demás elementos se contarán en modo de recuento a través del desplazamiento, que es diferente cada vez.
Para un array bidimensional, es necesario contar dos desplazamientos por columnas y por filas multiplicados por el número de fila, y por supuesto también en el proceso de recuento. El asemblador y el compilador no tienen absolutamente nada que ver, es sólo un direccionamiento de memoria básico para el uso correcto de los recursos informáticos en la práctica.
De esto se desprende fácilmente que, aunque haya una pérdida de rendimiento tan grande entre las matrices unidimensionales y las bidimensionales, los tiempos de direccionamiento son mucho más lentos en casos más complejos, por ejemplo, con objetos.
Sólo se calcula la dirección del primer elemento en tiempo de compilación. Todos los demás elementos se contarán en el modo de recuento a través de un desplazamiento, que es diferente cada vez.
Para un array bidimensional hay que calcular dos desplazamientos por columnas y filas multiplicados por el número de fila y en el proceso de conteo también, por supuesto. El asemblador y el compilador no tienen absolutamente nada que ver, es sólo una cuestión de direccionamiento de memoria básico para el uso correcto de los recursos informáticos en la práctica.
De esto se desprende fácilmente que, aunque haya una pérdida de rendimiento tan grande entre las matrices unidimensionales y las bidimensionales, los tiempos de direccionamiento son mucho más lentos en casos más complejos, por ejemplo, con objetos.
éxitos en la comprensión de lo que sucede y la pérdida de productividad
No tengo ningún problema en optimizar los compiladores y escribir mis propios diseños de acceso a datos
SZY: los objetos no son casos complejos - todas las manipulaciones para crear enlaces - todo a nivel del compilador, por desgracia, el procesador no le importa objeto o no, no tiene ningún problema con la computación de los desplazamientos en relación con los datos alineados, incluso si el "programador milagro" ahorra memoria - escribe los datos en matrices como byte, pero no mira la documentación al compilador, la eficacia de este código será visible sólo en un reflejo de una fisonomía de presunción del programador en el espejo, pero en realidad es una falsa
todo es a nivel de compilador, por desgracia al procesador no le importa si es un objeto o no, no tiene problema en calcular los desplazamientos relativos a los datos alineados
Parece que se acaba de explicar en un ejemplo sencillo cuánto se ralentiza el array bidimensional respecto al unidimensional durante la ejecución del programa, no durante la compilación. No veo la necesidad de repetirme. Así que ya ves que no te tomas la tarea de escribir un código de cálculo más o menos óptimo demasiado tiempo, y quizás no lo necesites. En este caso, la OOP está creada para usted. :)
Estás pensando en categorías de amebas :) .
" Deberíamos olvidarnos de las pequeñas eficiencias, digamos el 97% de las veces: la optimización prematura es la raíz de todos los males. Sin embargo, no debemos dejar pasar nuestras oportunidades en ese 3% crítico".
Es la cuarta vez que me citan en este foro.
Parece que se le acaba de explicar en un ejemplo sencillo cuánto más lento será un array bidimensional respecto a uno unidimensional en el proceso de ejecución del programa, no de compilación. No veo la necesidad de repetirme. Así que ya ves que no te molestas en escribir un código computacional más o menos óptimo, y quizás no lo necesites. En este caso, la OOP está creada para usted. :)
¿De qué tipo de código óptimo estamos hablando? No tienes ni idea de cómo funcionan los compiladores y las máquinas virtuales
El programador no necesita averiguar cómo se realiza el acceso y el direccionamiento a los elementos de la memoria física en cada compilador particular (aunque sea en diagonal, no en columna - aquí no se puede hacer nada) - es la tarea de los desarrolladores, si el programador no está satisfecho con el código - optimizará su código:
- aumentando el tamaño del código y disminuyendo el tamaño de los datos y perdiendo velocidad de cálculo
- aumentando el tamaño de los datos en el código y consiguiendo una mayor velocidad
- alternativamente, utiliza un compilador diferente
¡TODAS LAS OPCIONES han desaparecido!
La POO es otra rama para escribir código EFICIENTE, la efectividad de la POO es que el programador puede crear un modelo matemático en forma de algún tipo de arquitectura - logrando así una gran versatilidad de su código, si piensa que las clases tienen otro tipo de direccionamiento para el acceso físico a los datos - se equivoca, esa microscópica cantidad extra de datos - una tabla de objetos enlazados no aumentará en absoluto el tiempo de acceso a los datos físicos en memoria y los datos extra serán compensados con creces por el multi
Estoy sorprendido - usted comenzó a cagar en OOP, y luego cambió a los argumentos sobre el direccionamiento en arrays multidimensionales y unidimensionales - ¿estudió esto en alguna parte, o simplemente - todas las especulaciones y fantasías?
El trabajo con matrices multidimensionales se ha implementado durante mucho tiempo a nivel de hierro - el mismo búfer Z cuando se trabaja con tarjetas de vídeo, ah, sí, "ovejas, los desarrolladores de hierro" - no han consultado y no han aprendido cómo el direccionamiento eficaz de matrices multidimensionales, y no consultar - todos los programadores utilizan matrices multidimensionales sin pensar, y no buscan la felicidad en el aumento de código en aras de la eficiencia imaginaria cuando se trabaja con matrices unidimensionales
¿Depende la fiabilidad de la información de quién la presenta? Cualquier persona sensata debería entender que la información es objetiva, no subjetiva. :)
si el programador no está satisfecho con el código, optimiza su código:
- aumentando el tamaño del código y disminuyendo el tamaño de los datos y perdiendo velocidad de cálculo
- aumentando el tamaño de los datos en el código y ganando más velocidad
- alternativamente utiliza un compilador diferente
¡TODAS LAS OPCIONES han desaparecido!
Laoptimización del código requiere que el programador tenga un conocimiento mínimo de la intensidad de recursos de un fragmento de código en términos de operaciones elementales realizadas (suma, multiplicación, accesos a memoria, cálculos de direcciones, etc.). Sin esto, ninguna optimización es posible en principio, e incluso el mejor compilador será impotente contra este pobre programador. Parece una obviedad, pero veo que esto también puede ser una gran noticia para muchos programadores. :)
Y cualquiera que se proponga entender la cuestión se dará cuenta de que la información, como la cantidad, es algo subjetivo, no objetivo:))
Bueno hay que confundir y mezclar en una mezcla de cascabeles diferentes cosas. :)
Uno es una fuente de información, que es objetiva, y el otro es un receptor, que es subjetivo porque no siempre es capaz de percibir toda la información, sino sólo una parte.