Muchos fabricantes de portátiles prometen actualmente una duración de batería que va desde las 15 hasta incluso las 25 horas como hemos visto en los últimos que llevan Snapdragon 850. El problema es que muchos usuarios se quedan muy atrás de esa duración, con apenas 5 o 10 horas a lo sumo. ¿Por qué pasa esto?
#6 Y es cierto. Tienes un procesador dedicado para MP4 por hardware. Cuesta casi 0 de esfuerzo al procesador. Si acaso dibuja la ventana, el resto lo hace la gráfica poniendo las texturitas que el procesador MP4 le envia.
En cambiendo, abriendo una suite de oficina (que no un EDITOR) de textos, puedes darle caña al procesador perfectamente sin saberlo. Office 2016 consume cojón y medio.
#11 Muy poco, un coste ridículo, son procesadores dedicados a decodificar videos y nada más.
Ten en cuenta que el procesador dedicado a manejar un MP3 y decodificarlo y mostrar un menu en un reproductor portátil, es un triste z80, igual que el del spectrum. Para MP4 estoy seguro que cualquier ARM de muy bajo consumo tipo el de la Game Boy Advance sirve de sobra. Eso si, no le pidas que haga nada más en paralelo. ¿Pero decodificar la peli? Toda suya.
#12 para decodificar por hardware un H264 tienes ahora mismo casi seguro dos hardwares en tu PC, el programa fijo de tu micro Intel y la aceleración GPU de tu Nvidia o AMD.
Pero solo cuando todos los elementos de la pipeline encajan bien se puede hacer 100% hardware desde la adquisición de los buffers hasta que se muestran en pantalla.
Es un tema muy extenso y algo complejo.
#16 Solo uso Intel con gráfica integrada. El reproductor de video tiene tanto salida OpenGL como Vaapi. X.org hace eso mismo con el video, internamente es una textura y con DRI no hay duplicado de capas, todo va directo.
Y en movil Android ya te digo yo que Surface Flinger mete todo al SOC acelerado con todo el apoyo posible por HW, donde el consumo es bastante inferior al PC.
#17 ya pero si por ejemplo tienes dos tarjetas, un plugin de la pipeline puede estar decodificando el H264 en el Intel y los buffers YUV llevándose RAM para copiarlos a la Nvidia y pasar de YUV a RGB final, y ya veremos si ese RGB final se usa tal cual la surface en el programa o se copia otra vez a una textura propia.
No es tan fácil tenerlo todo hardware ni es tan fácil saber si lo tienes sin analizar la pipeline a ver qué está pasando con los buffers, depurar plugins y demás.
#19 Normalmente en portátiles tienes la APU integrada, sobre todo con AMD y los nuevos Intel. Creo que Nvidia aprendió desde la serie M churruscandose como si nada.
#16 Por no hablar que reproducir videos en pantalla completa es como 5 veces más rápido a que lo haga el gestor de ventanas, y encima se salta el gestor de composición, por lo que ver una peli en tu PC es mucho menos cargante que redibujar un procesador de textos con cientos de widgets e iconos, más la caché del documento con imágenes en memoria.
Y encima dicen que el nuevo Office usa Native React o Electron, por lo que con el segundo estás jodido sí o sí.
De LibreOffice ni hablo, de Sal a GTK/Win32/OSX tienes un baile guapo de dibujados que traga con amor.
#12 luego en casa lo pruebo. Dudo bastante. Cuando reproducia vídeos con mi anterior ordenador si tenían buena calidad iba a saltos porque el procesador no podía con ellos, sin embargo el Word, eclipse, Photoshop iban como la seda
#10 con el Office metiendo caña puede, pero con un bloq de notas o algo así el 99% del tiempo de CPU está esperando que pulses algo.
La aceleración hardware de vídeo tampoco es mágica. Se aceleran algunas cosas como H264 /H265, V8/9 y etc, pero no cualquier formato (MP4 es un container no un formato).
Después ojo que no es fácil que el pipeline entero esté acelerado, puedes tener algún filtro o algo que obligue a salir a RAM.
Y el Stream de audio casi nunca es por hardware, aunque es cierto que un AAC o MP3 gasta muy poco.
#14 El bloc de notas no es un procesador de texto, eso lo hace cualquier PC desde el 79. Office 2016 y LibreOffice 2016 tragan, y la GPU no ayuda demasiado.
Sobre AAC no estaría tan seguro, al menos creo que Sony da soporte a AAC y Atrac3.
Ok, donde digo MP4 por MP4/MKV con H264. Un AAC o MP3 en el vídeo para un equipo de hoy en día no es nada, pero un documento de cien páginas en Word contínuamente cacheado y con objetos OLE puede darle muchísima caña, más de la que crees.
Ni te digo ya si es un Excel.
Con Wordpad sería distinto, pero como digo Word, Pages y Writer son monstruos.
A mi Writer con un doc de 40 páginas me consume mucho más que MPV con vídeo HD y Vaapi.
#8 No son sandeces. En los móviles y en la PSP el decodificar vídeos en MP4 se hace por hardware, como la RaspBerry Pi. ¿Por qué te crees que la RPI puede con vídeo HD a 720p y 1080p en MPEG4, y si abres un video MPEG2 a la misma calidad le haces sudar?
En la RPI un DiVX a 720p ya se calienta debidamente, imagina un webm por ejemplo, usado por Google con video Theora y audio Opus.
#13 No estamos comparando dos tipos de formatos de vídeo, estamos comparando reproducir un vídeo (cualquiera) con utilizar un procesador de texto. Decir que requiere menos consumo energético ver un vídeo que usar un procesador de textos es, repito, una sandez.
#20 >Decir que requiere menos consumo energético ver un vídeo que usar un procesador de textos es, repito, una sandez.
Una sandez hasta que no distingues un procesador de textos de una suite moderna de un editor cualquiera
No menosprecies el consumo de una suite como Office hoy en día. Y creo que no tienes claro que reproducir un vídeo a pantalla completa, sobre todo hoy bajo GPU, es de un coste ridículo para una CPU.
#22 Que me da igual el balance de coste entre CPU y GPU, que me da igual cuál tenga que hacer más cálculos que cual en cada caso. Que ni antes estaba comparando dos tipos de formato de vídeo ni ahora el consumo de la CPU y la GPU.
A ver si queda claro: El consumo energético TOTAL de todo un portátil reproduciendo un vídeo va a ser mayor que el consumo energético TOTAL de trabajar con un procesador de textos.
Acotamos, venga: el procesador de textos que tú quieras de entre los pensados para la plataforma que sea con un trabajo normal, el vídeo que tú quieras en el formato que tú quieras siempre que sea un vídeo "normal" (que tenga un tamaño razonable, una resolución razonable y unos fps razonables).
#23 >A ver si queda claro: El consumo energético TOTAL de todo un portátil reproduciendo un vídeo va a ser mayor que el consumo energético TOTAL de trabajar con un procesador de textos.
No. El procesaror de textos dibuja todos sus widgets mediante la CPU y con suerte apoyo de la GPU mínimo via Glamor en Unix si tienes el driver de X especificado mediante modesetting y no el nativo de Intel.
DIbujar todo eso más cachear el documento puede tener un coste enorme, a ver si te crees que MS Office 2016 es Wordpad. La gente no usa ese procesador de texto en la vida real. Usa el monstruo gordaco, sea LibreOffice, Word o Pages.
Mientras tanto, con un video a pantalla completa no dibujas widget alguno, es que ni la venta porque el X.org todo video en pantalla completa se salta hasta el compositor, y encima como sabrás dibujar a pantalla completa para la GPU en vez de redibujar la venta cada X segundos tiene un coste mucho más inferior que el anterior caso. Y si añades widgets GTK o los propios de Office (sí, Microsoft dibuja widgets propios de Office desde el Office 97), eso es otro proceso que ha de estar vigilando y no es poco si tienes un cojón y medio de botones.
Por no hablar que los picos del procesador en el caso de la edición de textos suben y bajan constamente al realizar una tarea dinámica. Al ver una peli, el coste de la tarea es fijo desde el inicio hasta el fin.
Ahora vas y me comparas eso con un video sin dibujar el marco, a pantalla COMPLETA (dibujado absoluto, no debe buscar valores relativos) donde el soporte GL/Vulkan o incluso GDI es casi gratis ya que las gráficas saben hacer eso especialmente bien... desde el Amiga.
#24 Mu bien todos los datos técnicos y las siglas sobre qué usa para dibujar.
¿Nos metemos ahora en el consumo de CPU, de GPU, de leer sistema de ficheros (tarea constante e intensa en reproducción de vídeo), pasar a memoria, decodificar (sea por hardware o por software), etc.?
#26 > decodificar (sea por hardware o por software), etc.?
Por hardware en un portátil desde el 2011 es ridículo, no te digo nada en el 2018. Sobre leer el FS... pues mejor me lo pones. En un procesador de textos eso es de continuo, al guardar y volver a guardar un documento para cambios. Sobre RAM... la cache de Libreoffice se puede llevar 200-300MB en imágenes sin problema, y un doc de 50 páginas se puede llevar un giga. Ahora añade tareas de edición contínuas sobre un documento y verás que la CPU no lleva un consumo constante ni loco.
En un video, en OSX, tiene un modo donde las tareas en segundo plano pasen a baja proridad mientras que el video tenga prioridad media y créeme que junto la aceleración por hardware de corevideo y la API de OSX multimedia hace que puedas ver una peli o dos en un trayecto de bus de 7 horas. Windows hará lo mismo seguramente.
El office de ahora poco tiene que ver con 2003. Y como digo la edición de un documento puede ser bastante pesada en contextos medios.
#26 >¿Nos metemos ahora en el consumo de CPU, de GPU, de leer sistema de ficheros (tarea constante e intensa en reproducción de vídeo)
Pero lineal, se puede precedir el consumo fácilmente y reducir la CPU al mínimo. El vídeo a no ser que sea un monstruo de 8k, un vídeo 1080p con una iGPU Kabylake para arriba ni lo huele. Te recuerdo que todo reproductor, hasta los libres, tienen aceleración por hardware para ello. No sube del 5-10% de uso de CPU en todo momento.
Otra cosa es PopCornTime, donde es una mierda con Electron, pero ¿abrir SMplayer y ver una peli en HD? en 2018 el equipo ni se inmuta.
Estamos hablando de ver pelis en un reproductor cualquiera moderno, no por ejemplo de abrir Youtube a 1080p donde sí, ahí lo fríes.
#23 Y se me olvidaba: en un procesador de textos, al margen de lo anteriormente descrito, vas a estar realizando funciones constantemente. Eso puede ser una carga en segun que contextos bastante medio-alta al abrir bastantes ventanas y widgets, guardar documentos, establecer formatos, cosa que el reproductor de video como que no, película del tirón y ya.
Que como digo un documento medio en un procesador de textos, si es de 50-80 páginas con imágenes, en el Office de ahora, la CPU no se va a quedar quieta precisamente.
Comentarios
...en los últimos que llevan Snapdragon 850
Habla de portátiles o de tablets con teclado?
#6 Y es cierto. Tienes un procesador dedicado para MP4 por hardware. Cuesta casi 0 de esfuerzo al procesador. Si acaso dibuja la ventana, el resto lo hace la gráfica poniendo las texturitas que el procesador MP4 le envia.
En cambiendo, abriendo una suite de oficina (que no un EDITOR) de textos, puedes darle caña al procesador perfectamente sin saberlo. Office 2016 consume cojón y medio.
#10 y ese procesador dedicado no consume electricidad?
#11 Muy poco, un coste ridículo, son procesadores dedicados a decodificar videos y nada más.
Ten en cuenta que el procesador dedicado a manejar un MP3 y decodificarlo y mostrar un menu en un reproductor portátil, es un triste z80, igual que el del spectrum. Para MP4 estoy seguro que cualquier ARM de muy bajo consumo tipo el de la Game Boy Advance sirve de sobra. Eso si, no le pidas que haga nada más en paralelo. ¿Pero decodificar la peli? Toda suya.
#12 para decodificar por hardware un H264 tienes ahora mismo casi seguro dos hardwares en tu PC, el programa fijo de tu micro Intel y la aceleración GPU de tu Nvidia o AMD.
Pero solo cuando todos los elementos de la pipeline encajan bien se puede hacer 100% hardware desde la adquisición de los buffers hasta que se muestran en pantalla.
Es un tema muy extenso y algo complejo.
#16 Solo uso Intel con gráfica integrada. El reproductor de video tiene tanto salida OpenGL como Vaapi. X.org hace eso mismo con el video, internamente es una textura y con DRI no hay duplicado de capas, todo va directo.
Y en movil Android ya te digo yo que Surface Flinger mete todo al SOC acelerado con todo el apoyo posible por HW, donde el consumo es bastante inferior al PC.
#17 ya pero si por ejemplo tienes dos tarjetas, un plugin de la pipeline puede estar decodificando el H264 en el Intel y los buffers YUV llevándose RAM para copiarlos a la Nvidia y pasar de YUV a RGB final, y ya veremos si ese RGB final se usa tal cual la surface en el programa o se copia otra vez a una textura propia.
No es tan fácil tenerlo todo hardware ni es tan fácil saber si lo tienes sin analizar la pipeline a ver qué está pasando con los buffers, depurar plugins y demás.
#19 Normalmente en portátiles tienes la APU integrada, sobre todo con AMD y los nuevos Intel. Creo que Nvidia aprendió desde la serie M churruscandose como si nada.
#16 Por no hablar que reproducir videos en pantalla completa es como 5 veces más rápido a que lo haga el gestor de ventanas, y encima se salta el gestor de composición, por lo que ver una peli en tu PC es mucho menos cargante que redibujar un procesador de textos con cientos de widgets e iconos, más la caché del documento con imágenes en memoria.
Y encima dicen que el nuevo Office usa Native React o Electron, por lo que con el segundo estás jodido sí o sí.
De LibreOffice ni hablo, de Sal a GTK/Win32/OSX tienes un baile guapo de dibujados que traga con amor.
#12 luego en casa lo pruebo. Dudo bastante. Cuando reproducia vídeos con mi anterior ordenador si tenían buena calidad iba a saltos porque el procesador no podía con ellos, sin embargo el Word, eclipse, Photoshop iban como la seda
#10 con el Office metiendo caña puede, pero con un bloq de notas o algo así el 99% del tiempo de CPU está esperando que pulses algo.
La aceleración hardware de vídeo tampoco es mágica. Se aceleran algunas cosas como H264 /H265, V8/9 y etc, pero no cualquier formato (MP4 es un container no un formato).
Después ojo que no es fácil que el pipeline entero esté acelerado, puedes tener algún filtro o algo que obligue a salir a RAM.
Y el Stream de audio casi nunca es por hardware, aunque es cierto que un AAC o MP3 gasta muy poco.
#14 El bloc de notas no es un procesador de texto, eso lo hace cualquier PC desde el 79. Office 2016 y LibreOffice 2016 tragan, y la GPU no ayuda demasiado.
Sobre AAC no estaría tan seguro, al menos creo que Sony da soporte a AAC y Atrac3.
Ok, donde digo MP4 por MP4/MKV con H264. Un AAC o MP3 en el vídeo para un equipo de hoy en día no es nada, pero un documento de cien páginas en Word contínuamente cacheado y con objetos OLE puede darle muchísima caña, más de la que crees.
Ni te digo ya si es un Excel.
Con Wordpad sería distinto, pero como digo Word, Pages y Writer son monstruos.
A mi Writer con un doc de 40 páginas me consume mucho más que MPV con vídeo HD y Vaapi.
Porque emosido engañado
La mía dura más.
#6 Vale, me acabas de ahorrar entrar a mirar. Paso de leer sandeces.
Gracias.
#8 No son sandeces. En los móviles y en la PSP el decodificar vídeos en MP4 se hace por hardware, como la RaspBerry Pi. ¿Por qué te crees que la RPI puede con vídeo HD a 720p y 1080p en MPEG4, y si abres un video MPEG2 a la misma calidad le haces sudar?
En la RPI un DiVX a 720p ya se calienta debidamente, imagina un webm por ejemplo, usado por Google con video Theora y audio Opus.
#13 No estamos comparando dos tipos de formatos de vídeo, estamos comparando reproducir un vídeo (cualquiera) con utilizar un procesador de texto. Decir que requiere menos consumo energético ver un vídeo que usar un procesador de textos es, repito, una sandez.
#20 >Decir que requiere menos consumo energético ver un vídeo que usar un procesador de textos es, repito, una sandez.
Una sandez hasta que no distingues un procesador de textos de una suite moderna de un editor cualquiera
No menosprecies el consumo de una suite como Office hoy en día. Y creo que no tienes claro que reproducir un vídeo a pantalla completa, sobre todo hoy bajo GPU, es de un coste ridículo para una CPU.
#22 Que me da igual el balance de coste entre CPU y GPU, que me da igual cuál tenga que hacer más cálculos que cual en cada caso. Que ni antes estaba comparando dos tipos de formato de vídeo ni ahora el consumo de la CPU y la GPU.
A ver si queda claro: El consumo energético TOTAL de todo un portátil reproduciendo un vídeo va a ser mayor que el consumo energético TOTAL de trabajar con un procesador de textos.
Acotamos, venga: el procesador de textos que tú quieras de entre los pensados para la plataforma que sea con un trabajo normal, el vídeo que tú quieras en el formato que tú quieras siempre que sea un vídeo "normal" (que tenga un tamaño razonable, una resolución razonable y unos fps razonables).
#23 >A ver si queda claro: El consumo energético TOTAL de todo un portátil reproduciendo un vídeo va a ser mayor que el consumo energético TOTAL de trabajar con un procesador de textos.
No. El procesaror de textos dibuja todos sus widgets mediante la CPU y con suerte apoyo de la GPU mínimo via Glamor en Unix si tienes el driver de X especificado mediante modesetting y no el nativo de Intel.
DIbujar todo eso más cachear el documento puede tener un coste enorme, a ver si te crees que MS Office 2016 es Wordpad. La gente no usa ese procesador de texto en la vida real. Usa el monstruo gordaco, sea LibreOffice, Word o Pages.
Mientras tanto, con un video a pantalla completa no dibujas widget alguno, es que ni la venta porque el X.org todo video en pantalla completa se salta hasta el compositor, y encima como sabrás dibujar a pantalla completa para la GPU en vez de redibujar la venta cada X segundos tiene un coste mucho más inferior que el anterior caso. Y si añades widgets GTK o los propios de Office (sí, Microsoft dibuja widgets propios de Office desde el Office 97), eso es otro proceso que ha de estar vigilando y no es poco si tienes un cojón y medio de botones.
Por no hablar que los picos del procesador en el caso de la edición de textos suben y bajan constamente al realizar una tarea dinámica. Al ver una peli, el coste de la tarea es fijo desde el inicio hasta el fin.
Ahora vas y me comparas eso con un video sin dibujar el marco, a pantalla COMPLETA (dibujado absoluto, no debe buscar valores relativos) donde el soporte GL/Vulkan o incluso GDI es casi gratis ya que las gráficas saben hacer eso especialmente bien... desde el Amiga.
#24 Mu bien todos los datos técnicos y las siglas sobre qué usa para dibujar.
¿Nos metemos ahora en el consumo de CPU, de GPU, de leer sistema de ficheros (tarea constante e intensa en reproducción de vídeo), pasar a memoria, decodificar (sea por hardware o por software), etc.?
#26 > decodificar (sea por hardware o por software), etc.?
Por hardware en un portátil desde el 2011 es ridículo, no te digo nada en el 2018. Sobre leer el FS... pues mejor me lo pones. En un procesador de textos eso es de continuo, al guardar y volver a guardar un documento para cambios. Sobre RAM... la cache de Libreoffice se puede llevar 200-300MB en imágenes sin problema, y un doc de 50 páginas se puede llevar un giga. Ahora añade tareas de edición contínuas sobre un documento y verás que la CPU no lleva un consumo constante ni loco.
En un video, en OSX, tiene un modo donde las tareas en segundo plano pasen a baja proridad mientras que el video tenga prioridad media y créeme que junto la aceleración por hardware de corevideo y la API de OSX multimedia hace que puedas ver una peli o dos en un trayecto de bus de 7 horas. Windows hará lo mismo seguramente.
El office de ahora poco tiene que ver con 2003. Y como digo la edición de un documento puede ser bastante pesada en contextos medios.
#26 >¿Nos metemos ahora en el consumo de CPU, de GPU, de leer sistema de ficheros (tarea constante e intensa en reproducción de vídeo)
Pero lineal, se puede precedir el consumo fácilmente y reducir la CPU al mínimo. El vídeo a no ser que sea un monstruo de 8k, un vídeo 1080p con una iGPU Kabylake para arriba ni lo huele. Te recuerdo que todo reproductor, hasta los libres, tienen aceleración por hardware para ello. No sube del 5-10% de uso de CPU en todo momento.
Otra cosa es PopCornTime, donde es una mierda con Electron, pero ¿abrir SMplayer y ver una peli en HD? en 2018 el equipo ni se inmuta.
Estamos hablando de ver pelis en un reproductor cualquiera moderno, no por ejemplo de abrir Youtube a 1080p donde sí, ahí lo fríes.
#23 Y se me olvidaba: en un procesador de textos, al margen de lo anteriormente descrito, vas a estar realizando funciones constantemente. Eso puede ser una carga en segun que contextos bastante medio-alta al abrir bastantes ventanas y widgets, guardar documentos, establecer formatos, cosa que el reproductor de video como que no, película del tirón y ya.
Que como digo un documento medio en un procesador de textos, si es de 50-80 páginas con imágenes, en el Office de ahora, la CPU no se va a quedar quieta precisamente.
10horas de duracion de bateria?
El mio no llega a 1:30 y dandole gracias...
#1 a nadie le chirría en artículo cuando dice que prueban con vídeos porque consumen menos recursos que el procesador de texto?
Duran el 10% de lo que dicen.
Los vídeos de YouTube y los memes es lo que tiene.
mierda articulo oara poner publi