Interioridades del algoritmo del motor de evaluación

Here the administration and development teams will publish the announcements related to the COJ. Make sure to come back often, and to comment your thoughts on them.
Post Reply
User avatar
frankr
Posts: 49
Joined: 6 years ago
Location: Las Tunas
Gender: Male

Interioridades del algoritmo del motor de evaluación

Post by frankr » 2 years ago

El motor de evaluación (ME de ahora en adelante) es el mismo para todos los lenguajes. Pueden haber una o más instancias del ME corriendo varios hosts de la red, incluido el host de la aplicación web. Estas instancias toman los envíos de un servidor de colas RabbitMQ, de modo que la plataforma del COJ es programación distribuida. Actualemente hay dos instancias del ME corriendo en hosts distintos al que alberga la aplicación web y el servidor de colas. Una de esas instancias es para los lenguajes no oficiales (Python, JS, Ruby, Bash, etc), la otra es para los lenguajes oficiales (Java, C/C++, C++11), todos los hosts tienen ubuntu 14.04 virtualizado.

El ME recibe una bandera para saber si debe correr todos los casos de prueba como se hace ahora en el archivo de 24 horas o en el futuro en los concursos para preuniversitario(http://coj-forum.uci.cu/viewtopic.php?f=12&t=2946), pero si es un envío de un contest estilo ICPC entonces cuando el ME ya tiene compilado el envío opera así:

Code: Select all

 Para cada archivo con caso de prueba C:
     Ejecuta el código en un sandbox para la entrada C //en este paso no se
     //comprueba la salida del programa con la esperada, solo que el programa
     //enviado haya corrido bien en el entorno restringido del sandbox
     Si el veredicto fue TLE, RTE, IVF, OL o MLE
        Retornar a la aplicación este veredicto y el loop.index como primer
        caso fallido y romper ciclo
     Si el tiempo total consumido es mayor al establecido para el problema
        Retornar a la aplicación TLE y romper ciclo

 //Si la ejecución del ME llega a este punto es que el código enviado
 //puede tener alguno de estos veredictos: AC, PE o WA que se determina
 //comparando (o ejecutando checker) para cada archivo de caso de prueba
 //la salida esperada con la correspondiente generada por el programa
 //en su corrida previa en el entorno restringido del sandbox. 
 

Me detengo aquí para aclarar que esa manera de operar del ME implica que si usted recibe un veredicto como TLE en el caso X no quiere decir necesariamente que del caso 1 al X - 1 sean aceptados. Es por esto que a veces enviamos un código con instrucciones de traceo y en vez de recibir WA recibimos TLE en el algún test mayor al 1 (esto ocurrió en The 1st Western Challenge[http://coj.uci.cu/contest/contestview.xhtml?cid=1506] y fue lo que me motivó a escribir este post ya que escuché decir "el coj no juzga bien" o comentarios similares).


Cuando el estado de una sentencia se queda en 'Judging' por mucho tiempo es o por error en la conexión de red o por algún bug (excepción no manejada) tanto del ME o en la aplicación web. Cuando ocurre esto los desarrolladores usan los logs de la aplicación para tratar de reproducir el error en un entorno de desarrollo que permita la depuración.

Cuando el estado de una sentencia es 'Internal Error' es debido a alguna de las siguientes causas:
* Error en los archivos de casos de prueba, normalmente es que no están en la ubicación esperada por el ME porque el problem-setter no los subió
o porque no han sido sincronizados entre todos los hosts.
* En el caso de los problemas de jurado especial falta el checker o cuando se ejecuta provoca un RTE él mismo.

Cuando el estado es 'Invalid Function' es que el ME detectó una interrupción generada por alguna función en el código enviado que se considera potencialmente peligrosa para la seguridad del sistema, en otras palabras, el código puede estar intentando hackear el sistema. El ME tiene una
lista blanca con las interrupciones seguras para la arquitectura.



Marcelo
Posts: 2
Joined: 2 years ago
Gender: None specified

Re: Interioridades del algoritmo del motor de evaluación

Post by Marcelo » 2 years ago

frankr, entiendo que evaluar los envios de forma distribuida es una ventaja debido al incremento de la eficiencia, sin embargo no veo correcto que exista la posibilidad de TLE en el caso 13 y despues WA en el caso 5. Cuando uno esta resolviendo un problema parte del feedback que recibe es el caso alcanzado. Deja de tener sentido poner el caso de error en la respuesta del judge, dado que esto no es para nada significativo, esto no implica que fueron superados los casos anteriores. En mi opinión decir el caso de error es algo importante, pues como todos saben no es lo mismo WA en el caso 1 que WA en el caso 101, pero estos deben ser consistentes.

Post Reply

Return to “Announcements”