Sigo pensando en el uso que hace Dusk de funciones nativas del host para operaciones costosas.
A primera vista, la lógica es sencilla. Mover la computación pesada fuera de WebAssembly, ejecutarla con más eficiencia en el entorno del host y reducir parte de la sobrecarga en el camino.
Pero hacer más rápido un componente de la ruta de ejecución no significa automáticamente que todo el trabajo se acelere en la misma proporción. Esto importa a medida que Dusk avanza para llevar los mercados financieros a onchain con instituciones con licencia de la UE, donde la arquitectura eventualmente tiene que rendir bajo cargas reales, no solo parecer eficiente sobre el papel. Lo que todavía no sé es si el diseño de funciones del host de Dusk elimina un cuello de botella que realmente domine las cargas reales, o si principalmente acelera trabajo que resulta ser solo una parte menor del tiempo de ejecución total.
Los detalles que vale la pena vigilar son qué operaciones se trasladan fuera de WASM, cuánto más rápidas se vuelven y qué fracción de una carga de trabajo representativa de Dusk cubren esas operaciones.
La arquitectura ofrece una buena razón para esperar una mejora. Eso es evidencia más débil que ver el mismo tipo de carga de trabajo producir una ganancia material, repetible en la práctica.
Me preocuparía menos por la aceleración teórica de un primitivo que por cuánto cambia el rendimiento de la carga de trabajo que Dusk realmente ejecuta.
La cuestión es si Dusk ha eliminado un cuello de botella real del sistema o simplemente aceleró una parte del camino sin mover mucho el rendimiento general.
Estoy observando benchmarks específicos de Dusk que aíslen la ganancia de la función del host y muestren cuánto importa a nivel de carga de trabajo.
#dusk $DUSK @Dusk
A primera vista, la lógica es sencilla. Mover la computación pesada fuera de WebAssembly, ejecutarla con más eficiencia en el entorno del host y reducir parte de la sobrecarga en el camino.
Pero hacer más rápido un componente de la ruta de ejecución no significa automáticamente que todo el trabajo se acelere en la misma proporción. Esto importa a medida que Dusk avanza para llevar los mercados financieros a onchain con instituciones con licencia de la UE, donde la arquitectura eventualmente tiene que rendir bajo cargas reales, no solo parecer eficiente sobre el papel. Lo que todavía no sé es si el diseño de funciones del host de Dusk elimina un cuello de botella que realmente domine las cargas reales, o si principalmente acelera trabajo que resulta ser solo una parte menor del tiempo de ejecución total.
Los detalles que vale la pena vigilar son qué operaciones se trasladan fuera de WASM, cuánto más rápidas se vuelven y qué fracción de una carga de trabajo representativa de Dusk cubren esas operaciones.
La arquitectura ofrece una buena razón para esperar una mejora. Eso es evidencia más débil que ver el mismo tipo de carga de trabajo producir una ganancia material, repetible en la práctica.
Me preocuparía menos por la aceleración teórica de un primitivo que por cuánto cambia el rendimiento de la carga de trabajo que Dusk realmente ejecuta.
La cuestión es si Dusk ha eliminado un cuello de botella real del sistema o simplemente aceleró una parte del camino sin mover mucho el rendimiento general.
Estoy observando benchmarks específicos de Dusk que aíslen la ganancia de la función del host y muestren cuánto importa a nivel de carga de trabajo.
#dusk $DUSK @Dusk