edición general

Un solucionador de sudokus de realidad aumentada hecho en WebAssembly [eng]

#2 es posible que sí lo haga por frame. El tiempo de resolución de un sudoku de este estilo puede rondar la centésima de segundo.
#7 #2 el proceso de reconocer la imagen debe de ser 50 o 100 veces mayor, así que es una optimización innecesaria.
#10 ole tus huevos, asi que como hace algo mas complicado eso no hace falta optimizarlo? jaja teniendo en cuenta que la optimizacion lleva dos lineas y ahorra cientos de veces minimo tiempo de ejecución de esas dos lineas....
#13 Es mucho más productivo dedicar el tiempo a optimizar el código que ocupa el 90% del proceso.
Es lo que aprendes cuando tienes una deadline. Lo más valioso es el tiempo de desarrollo, no el tiempo de proceso.
Pero si nos ponemos así, este servidor en sus tiempo contaba los ciclos de proceso y bloqueaba la caché con el código del bucle principal.
#16 Vamos no me vendas la moto de que contabas ciclos y me suelte la burrada esa de que como otra tarea es enorme eso no hace falta... estoy de acuerdo que si nos podemos a optimizar podemos no acabar nunca y hay momentos que ya no interesa... lo que me deja alucionado es tu criterio de oye que esto ya no lo optimizo que como va con algo mas grande pa que!! se optimiza siempre que el trabajo de hacer la optimización y el resultado merezca la pena vaya acompañado de tareas mega grandes o tareas mega pequeñas.
Estamos hablando de una optimización mega trivial!! tener en memoria el ultimo sudoko escaneado y el ultimo resultado, comparar el nuevo sudoku escaneado, si por ejempo usa strings de 81 caracteres es hacer:
if ultimosudoku=nuevosudoku then resultado=ultimoresultado. // una misera linea!!!!!!!!!!!!!
Ten encuenta que hablamos de webassembly no es codigo que corre directamente en cpu sino que se "desvirtualiza" primero. Ten en cuenta tb que la idea es que esto corra incluso en dispositivos moviles cuya potencia y autonomia de bateria depende de que tu codigo no consuma mas de lo necesario.
BTW Ponte como quieras yo comparaba los ciclos de ejecucion contra espacio de la instrución de ensamblador para hacer demos gráficas de sólo 4 kilobytes.
#16 Hombre, entre una optimización que ya tienes hecha (son 2 líneas) y otra que tienes que dedicarle mucho tiempo a ver si encuentras algo (y puede ser que no lo encuentres).

Aquello del pájaro en mano...
#31 #35 Este el el principal error humano de la programación, que lleva a las dos primeras regla de la ingeniería de proyectos:

1. Todas las estimaciones de tiempo y esfuerzo están infravaloradas.
2. Están infravaloradas POR MUCHO.

La broma es que toda estimación de tiempo se convierte en el doble de la siguiente escala. Es decir, dos días acaban siendo cuatro semanas.
Veinticinco años con proyectos. No ha fallado una sola vez.
#41 bla bla bla es un if con una condicion booleana que ahorra tocho de codigo, el tiempo de saber que ese if te lo ahorra es de 30 segundos de un programador medio decente.
#43 ¿Pero tu te crees que si fuera tan fácil no lo habría hecho ya el programador a la primera?
#45 para empezar de donde sacas que no esta hecho? Sé que es asi de fácil se trata de comparar dos arrays de 81 numeros enteros y si son todos iguales no ejecutar algo ES DE PRIMERO DE PARVULOS DE PROGRAMACIÓN
#45 #2 github.com/ColinEberhardt/wasm-sudoku-solver/blob/master/src/steps/sol
de hecho lo ha hecho incluso parece que tiene una cache de mas de un resultado:
#49 aprende!!  media
#41 Una optimización trivial, como interrumpir un ciclo cuando es evidente que lo tienes que interrumpir, no se discute en ninguna parte, si sabes donde lo tienes que interrumpir es absurdo pararse a hacer cálculos de rendimiento porque vas a tardar infinitamente más haciendo cálculos que en interrumpirlo y no interrumpir un bucle no afectará significativamente al rendimiento, pero los miles que forman generalmente un programa lo más seguro es que sí.


Resumiendo: que cuando es evidente que tienes que interumpir un bucle tan absurdo es no interrumpirlo como ponerse a hacer cálculos de rendimiento para ver si merece la pena hacerlo, lo interrumpes y ahorras tiempo de programación y tiempo de ejecución. Es lo mejor de lo mejor.
#16 Si, y más productivo aún es no optimizar nada. Total si así se vende bien ¿para qué "perder el tiempo"?
#13 Sí, así es como funciona el mundo real. #10 Tiene razón. Tu pensamiento es poco práctico y poco profesional

Mucha gente se equivoca optimizando bucles chorras y gestión de memoria cuando hay otras secciones críticas que usan mil veces esos recursos y es donde hay que poner el esfuerzo.
#32 estamos hablando de poner un if y evitar un monton de bucles for. No me digas que en la vida real tu trabajo no consiste en evitar un monton de bucles poniendo un misero if por que si dices eso es no sabes tampoco programar....
Lo que tu y el otro #10 pretendeis decir es que optimizar por optimizar es de locos y estoy de acuerdo pero estoy hablando de poner un if para evitar una ejecucion mucho mas compleja....
Segun vosotros:
for i=0 to 1000000 do wahtever
no tiene sentido optimizarlo a:
if esnecesario then for i=0 to 1000000 do wahtever
no me jorobes!!
el trabajo de programador consiste en saber donde con un if ahorras una ejecucion pesada.... que yo no estoy hablando de inventar un nuevo metodo de ordenacion basado en tecnología cuantica para evitar usar una busqueda binaria de libro... estamos hablando de poner un if que ahrorra ejecutar un monton de for.... en una aplicacion de tiempo real ademassss....
#35 Posíblemente todo eso ya esté en el código original, y todo sea "un pelín" más complejo de como se ve por fuera.
#42 un if en cualquier codigo incluso en ensamblador es trivial modo dios.... no cuela
#54 Es lo que quería decir y lo he dicho también en #42
#38 gracias de verdad que pensaba que estaba en la dimension oculta... por que #32 va y le da la razón...
#40 Es que yo tengo mis años en esto. Soy de la época en que había que adaptarse al hardware.
Actualmente el programador tiene como objetivo terminar cuanto antes. No importa si quedan errores y mucho menos importa optimizar el código. Si el programa va lento el usuario ya se las arreglará comprando un ordenador más potente.
Hoy en día la gente piensa que si un software es pesado y requiere un equipo más rápido es porque debe ser bueno y hacer muchas cosas importantes.
#13 Tienes razón. @sillicon está listo para trabajar en Microsoft. :troll:

¿Para qué escribir 2 líneas más si puedes evitarlo?
#13 En general se optimiza el tiempo del programador, que suele ser mucho más caro.

EDIT: Mirando el código parece que el solver tiene cache

github.com/ColinEberhardt/wasm-sudoku-solver/blob/master/src/steps/sol
#64 en general pero no en este caso razones:

- es un aplicación que busca hacer un monton de cosas en tiempo real cualquier mejora en el tiempo de ejecución merece la pena ver si es "rentable"
- si ya sin optimizar los tiempos son buenos quizas no merezca la pena mirar nada (si miras el video los fotogramas se saltan van justos)
- es webassemlby la idea es ejecutarlo incluso en moviles se ahorraria bateria si se sonsume menos cpu
- la optimización es mega trivial un programador medio que la ve y la escribe instintivamente en 30 segundos. (coste zero)

pero vamos que una aplicacion que realiza en tiempo real 3 tareas a b y c de pesos 1000 100 y 900 decir que si hay opcion super sencilla a reducir la de 100 a 1 no aplica por que total ya hay tareas de 1000 es....demencial..
#2 #7 me respondo: github.com/sunjay/sudoku 0.644 seconds to solve 95 "hard" puzzles

menéame