« first day (1821 days earlier)      last day (33 days later) » 

8:08 AM
Guten morgen
 
8:49 AM
Buenos dias
 
 
5 hours later…
1:30 PM
Hola buen dia.
 
2:02 PM
Buenas..
 
2:27 PM
Necesito migrar 500GB de correos de un servidor a otro alguna recomendación como podría hacerlo de manera que el proceso no demore mucho
 
Meterlos en un HDD no es viable ?
 
No, quiero migrarlos de un servidor a otro
Sin necesidad de descargarlos y luego subirlo que se haga directamente
 
2:54 PM
@JuanPerez pues la velocidad va a depender de la interconexión entre los servidores y el tipo de almacenamiento, ram y procesador que usen. Son muchos factores.
 
 
2 hours later…
5:16 PM
¿Alguien sabe cual es el método mágico invocado por Python cuando uno calcula min([obj1, obj2, ..., objN])?. Los objetos son de una clase definida por el usuario.
 
5:49 PM
Bueno, era lt, como lo suponía. Descubri que min(lista, key=lambda x: x.valor...) es muchisimo más rápido que min(lista).
 
6:32 PM
@CandidMoe Entiendo que hay menos llamadas "por debajo", ya que x.valor es un entero (supongo) que python ya sabe cómo comparar, por lo que se ahorra las llamadas a .__lt__()
 
La explicación que encontre es que "key=" esencialmente guarda el valor en cache, mientras que la llamada a "lt" se repita cada vez. Eso incluso para lambdas que calculan. Aqui tengo una misma ejecución con lambda y otra implementando "lt":
48 2638 3533595.0 1339.5 81.3 current = min(openset, key=lambda o:o.G + o.H)
48      2638   24301091.0   9211.9     77.9          current = min(openset)
La misma cantidad de llamadas. Con key=, 3.522.595us, con "lt", 24.301.091us, o sea, 6x.
(usando line_profiler)
 
En una lista de qué longitud?
El factor multiplicador (6x) depende del tamaño de la lista? O la versión con __lt__ siempre tarda seis veces más?
 
Un montón de listas de largo variable. Hice pruebas más cortas y la relación se mantiene. Referencia: Algoritmo de Astar excede el límite de tiempo
 
6:57 PM
Si la relación se mantiene no parece que sea entonces lo de la cache. Entiendo que si la lambda se cacheara, cuanto más larga fuera la lista mayor sería el factor entre velocidades
si el factor es constante parece más bien entonces que la llamada a __lt__ tarda seis veces más que la llamada a la lambda, o que se hace más veces por elemento
 
Hola a todos. ¿Cómo están?
Tengo una pequeña duda con ensamblador
 
Mi ensamblador está un poco oxidado, pero dale
 
¿Si quiero trabajar con registros del kernel, como por ejemplo, registro cause o status, debo usar la instrucción .kdata?. Ensamblador MIPS
 
Lo siento, no puedo ayudarte ahi. El poco assembler que recuerdo era de intel
 
He estado buscando, pero apenas hay documentación sobre este ensamblador en concreto. Y su repertorio de instrucciones es un poco escaso
¿El ensamblador de intel que viste era el x86?
 
7:01 PM
@LearningDeveloper Precisamente :-) Es un RISC (Reduced Instruction)
@LearningDeveloper Sí
 
Yo estoy con él támbien, pero ahora estaba con prácticas de MIPS. ¿Algunas vez has usado algún assembler en algún puesto de trabajo?
Desde que he visto los lenguajes ensambladores, me han llamado mucho la atención, sobre todo cuando vi que se le podía hacer ingeniería inversa a un código ensamblador
 
No creo que se usen apenas en el mundo real, salvo para optimizar algunos trozos de código que sean un cuello de botella. Pero aún en ese caso, se suele programar en C pues los compiladores C hacen una excelente optimización, seguramente mejor de la que harás tú
Necesitas conocer bien ensamblador si estás haciendo un compilador, claro. O para programar partes del kernel del operativo, o controladores de dispositivo
pero me temo que la principal utilidad hoy día puede ser para ingeniería inversa, y para hacer "el mal" (virus, payloads maliciosos, exploits)
También es muy útil tener ideas claras de ensamblador, aún si no lo vas a usar nunca, porque ayuda a entende mejor qué hace la CPU en realidad, y por tanto a escribir código más óptimo, aún si es de alto nivel
 
 
4 hours later…
11:22 PM
@abulafia. Tu avatar es Dan Aykroyd en The Blues Brothers?
 

« first day (1821 days earlier)      last day (33 days later) »