-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-10-05 a las 17:21 +0200, Rafa Grimán escribió:
Pues curiosamente los de xine creo que usan raw precisamente para evitar el uso de la cache, porque al ser un fichero enorme que se lee una [fa]nica vez no tiene sentido guardarlo en memoria que es m[e1]s util para otros
Siempre y cuando hablemos de un proceso que accede a disco, ¿qué ocurre si son muchos usuarios que acceden a vídeo en tiempo real? Pues que no es sostenible esto. Necesitas cachear todo lo que puedas a memoria porque los cabezales están como locos saltando de un vídeo a otro para satisfacer las peticiones del resto de usuarios y procesos.
Es que es distinto si estás visionando un (uno) video en un ordenador, o si estás procesando video. En el momento que puedas necesitar volver a leer un mismo dato obviamente el caché ahorra trabajo. Pero si simplemente estás viendo una película, mejor no usar el caché de sistema.
O dicho de otra forma, el programador del proceso conoce el tipo de entrada/salida que va a necesitar y se puede optimizar. El programador de la cach[e9] no: puede orientarla por sectores contiguos de disco, por ficheros completos, por peticiones de procesos, mezclas, algoritmos inteligentes... y todo porque no sabe realmente que es lo que le van a pedir.
Eso es otra historia: hoy en día el desarrollador de aplicaciones se basa ne lo que hacen los desarrolladores del kernel, pero no piden que se implementen determinadas cosas. Por ejemplo, en Linux, el tamaño de bloque máximo son 16 KB (si no recuerdo mal), ¿qué ocurre si mi aplicación funciona mejor leyendo bloques más grandes?
¿Solo 16Ks? En Dos podía hacer lecturas/escrituras de ficheros de datos con tampón dedicado de 64Kb: y no era más porque eso era un segmento. Que raro. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFJUymtTMYHG2NR9URAhpHAJ469ouSHvkcKFONpuFoLfYf2Uqv2gCgk7GM 8s1y7DWRyeodRR2A8CIu8ks= =egUU -----END PGP SIGNATURE-----