Kernel de Linux: una línea de código que dispara el rendimiento un 3888%

¿Puede una simple línea de código cambiarlo todo? En el mundo del desarrollo de software, la respuesta es un rotundo sí, y el Kernel de Linux acaba de demostrarlo. Con un solo ajuste, el rendimiento en ciertas tareas individuales se disparó un impresionante 3888,9%. Este cambio no solo resalta el poder de la optimización, sino que también cuestiona la idea de que el hardware es el único responsable de la velocidad.

[#5 tpm1]

"cuestiona la idea de que el hardware es el único responsable de la velocidad."

Nadie que haya programado mínimamente piensa eso.

[#7 pkreuzt]

#5 Ni nadie que haya probado Windows.

[#17 Robus]

#5 recuerdo mi primer programa en ensamblador, en el Commodore 64, era un programa muy simple que movia un sprite por la pantalla, en la versión en Basic se movia a través de la pantalla y se situaba en el centro… en ensamblador la imagen aparecía directamente en el centro.

Tardé en darme cuenta que era tan rápido que no llegaba a ver el movimiento y solo lo veia en el punto final, poniendo un bucle de 255 dentro de otro de 255 fui capaz de ver un pequeño “flash” del sprite moviendose.

Ese día, a mis 14 años, ya tuve clarisimo que el hardware no era el problema.

[#19 jriguera]

#17 Me resultan familiares tus experiencias. La capacidad de un simple ESP32 de hoy en día es increíble viendo el tamaño, y ya sin ir mas lejos algo como una Raspberrypi ... Muchas veces he pensado la cantidad de ciclos desperdiciados y recursos con esos frameworks de alto nivel de hoy en dia, que algunos ni programar se necesita ... y el problema es que al final todo acaba fallando.

[#30 Nostradameus]

#19 Hace muchos muchos años yo entre en una empresa a programar en Delphi 7. Me reportaron un bug en un programa que intentaba insertar en una BDD Oracle una cifra y petaba porque el punto decimal estaba definido como un punto y la codificacion de la BDD estaba definida como una coma.
Bien, como programador que soy (era) busqué la solución más nativa y menos costosa para el sistema, definir en el ámbito de la función que hacía la inserción un "DECIMAL POINT IS COMMA" al principio que…   

[#40 Wajahpantat]

#30 Le molestó tu chulería, solo eso.

[#44 levante]

#40 Y así está el mundo.

[#52 Nostradameus]

#40 Le molestó que tuviera razón, que no es lo mismo. No me gusta trabajar mal porque es costumbre en el sitio, lo siento.

[#54 repl_logos]

#40 Chulería la de la jefa, que es incapaz de reconocer cuando un subordinado puede ahorrate miles de euros.

[#28 tusko]

#17 Claro que no es el problema, por eso los procesadores son los mismos ahora que el del commodore 64.

[#37 ElPerroDeLosCinco]

#17 Con casos parecidos aprendí a controlar la velocidad de mis programas mediante temporizadores y no confiar en que todo iba a correr como corría en mi ordenador.

Recuerdo un juego comercial y supuestamente bien hecho (no se si era el Aladdin o el Rey León), en el que después de cada nivel habia una especie de "jackpot" en el que tenías que detener tres ruletas en el mismo elemento. Debía estar programado a lo bruto, porque si desactivabas el Turbo del PC, las ruletas iban tan despacio que est6aba chupado pararlas en el momento justo.

Joder, qué viejo soy.

[#43 celyo]

#17 hiciste el primer juego sobre The Flash, pide royalties

[#26 lameth]

#5 Es, al fin y al cabo, el espíritu de poner el Doom en todas partes: demostrar que con un buen código se puede.

[#32 ombresaco]

#5 Los electrónicos hacen el hw cada vez más potente y más rápido, pero no te preocupes, que los informáticos diseñan el sw para que no notes la diferencia

[#59 tednsi]

#32 Genial

[#35 HeilHynkel]

#5

Me permito modificarte la frase:
Nadie que haya programado mínimamente bien piensa eso.

[#4 wendigo]

Será Perry la web...pues no va y me salta un anti anti bloqueador de anuncios...

Bueno, a lo que iba c&p "cuestiona la idea de que el hardware es el único responsable de la velocidad." No conozco a nadie minimamente serio que diga eso

Saludos

[#14 alfema]

#4 a mi la primera vez lo mismo, pero en modo lectura tienes acceso, las siguientes veces que accedí ya no saltó el mensaje.

[#20 alfema]

#18 goto #14

[#25 Bourée]

#20 Gracias

[#22 ochoceros]

#4 Me ha pasado lo mismo y he tenido que usar las técnicas de hacking avanzado de #14 (gracias) de poner y quitar el modo lectura.

[#15 comadrejo]

#4 Gracias al bloqueador de anuncios la web va un 3888% mas rápida.

[#31 Yomes]

#4 Yo he desactivado el bloqueador (uBlock Origin), he recargado y ya está. No he visto publicidad invasiva o molesta, así que no me parece necesario tenerlo activo en esta web en concreto.

[#41 tamat]

Como dice este twit: "Si consigues un x2 entonces es que has optimizado tu algoritmo, si consigues x100 es que has dejado de hacer algo estupido"  

[#45 Heni]

#41 This!

Porque sólo te puedo votar 1 vez, si no te daba todo mi Karma. Estaba leyendo todas las respuestas y nadie lo decía.

Sin necesidad de ver en detalle en qué consiste exactamente la mejora, ese incremento sólo se explica si alguien la había cagado antes, y mucho

[#2 cajadecartonmojada]

Hombre, si esa linea era comentar un sleep(1), pues normal

[#16 Cuñado]

Con este tipo de avances, queda claro que la optimización del software seguirá siendo una de las principales claves para maximizar el rendimiento, incluso en hardware ya existente.

Ojocuidao, incluso en el hardware ya existente. Que en el inexistente ya lo dábamos por hecho

[#13 alfema]

#10 básicamente sí, de forma que si la opción THP está activada y está "alineada" con el tamaño de PMD se ejecuta la acción. A mi me gustaría ver una lista de programas o procesos que se ven afectado por esto y la ganancia obtenida.

[#53 repl_logos]

#13 Máquinas virtuales con configuraciones similares, de seguro.

[#12 chavi]

Solo el titular y la entradilla son de traca. Miedo me da el cuerpo de la noticia...

[#1 elGude]

Alguien tiene la linea por ahí?

[#3 pkreuzt]

#1 Yo ya tengo bingo.

[#11 MADMax2]

#3 guau! Guau!

[#6 Cuñado]

#1 Pregúntale a Albert Rivera, que sabe mucho de líneas que disparan el rendimiento...

[#38 snok87]

#6 De que año vienes? normalmente la gente viaja al pasado, no al futuro...

[#39 Cuñado]

#38 Pues de 2019... ¿Albert Rivera ha dejado la farlopa? Bueno, pues mientras busco un sustituto voy a Wuhan a probar el pangolín asado, que me han dicho que está de muerte.

[#51 Albaricoquero]

#6 creo que errejon también entiende.

[#58 elrolo]

#51 de líneas no se, pero de rajas seguro.

[#8 alfema]

#1 sólo hay que bucear un poco, en la misma web hay un enlace al informe en la web de Phoronix, en esta un enlace a mm, mmap: limit THP alignment of anonymous mappings to PMD-aligned sizes donde aparecen los cambios.

>----------
diff --git a/mm/mmap.c b/mm/mmap.c
index 1e0e34cb993f18..9841b4…   

[#10 PauMarí]

#8 sólo el IS_ALIGNED? (lo estoy viendo en el móvil, que conste).
También se tendría que ver que entiende el autor por "en ciertas tareas individuales"...

[#18 Bourée]

#8 A mi me dice: bloqueado por el bloqueador de anuncios...

[#42 anv]

#18 Pues quita el bloqueador de anuncios y deja que los dueños de la página ganen algunos céntimos con tu visita.

[#21 arcangel2p]

#8 Realmente no es una mejora por lo que entiendo, sino una corrección de una regresión. Y parece afectar a las tareas de mapeo de memoria. No sabría decir en qué situaciones 'reales' aplicaria.

[#24 malajaita]

Hello robot, tanks for that 3888.9% RAM performance improvement.

#8 Que digo yo que a lo mejor este parche se lo debemos a la IA.

[#33 geletee]

#8 edit

[#47 torrrquemada]

#8 Hay una cosa que me intriga: ¿Dónde está el paréntesis inicial del último paréntesis de la condiciones else if?

[#48 daphoene]

#47 Los paréntesis son correctos. Revisa otra vez

[#49 torrrquemada]

#48 cierto

[#56 comadrejo]

#47 Lo que esta viendo en #8 es un diferencial con el que se aplica el parche, indica las línas eliminadas y añadidas.

El resultado tras el parche: git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/mma

[#9 frg]

#1 Raya, se dice raya ...

[#34 samsad]

#1 fast=true

[#46 xyria]

#1 Eso iba a preguntar.

[#50 daphoene]

#1 Viene en la imagen de cabecera. No sabía que el kernel linux estaba hecho en javascript, yo pensaba que era C

[#55 repl_logos]

#50 Los de GNU suelen encapsular casi todo en objetos ad-hoc. Mira si no glib.
Que bueno, la verdad es que es más cómodo usar glib+c que el mastodonte de C++.

[#57 daphoene]

#55 Con C he trabajado poco, con C++ sí me ha tocado lidiar. A pesar de que se me daba bastante bien, y de que era hiper potente, me dejó marcado

Eso sí, también aprendí bastante.

[#23 CrudaVerdad]

Cambiaron de llamar a BubbleSort a QuickSort

[#36 zeioth]

3888% → Woah!!
En Intel → Meh

[#27 lgg2]

Por lo visto es una regresión de un parche aplicado en diciembre del 23. Vamos, que vuelve a su estado en esa fecha.

[#29 tusko]

#27 Ya decía yo que Linux iba una 3000 veces más lento últimamente . .. ¿o no será que es un poco sensacionalista todo esto?