Broadcom BCM2711 vs Intel Celeron N2830
Debido a mi plena curiosidad, he decidido enfrentar el SoC de la Raspberry Pi 4 de 2GB de RAM, esto es el Broadcom BCM2711 contra una laptop ASUS X200MA cuyo corazón es un Intel Celeron N2830 y 2GB de RAM. La razón de esto, pese a que en principio no habría nada en que se pudiese justificar una comparativa necesaria o incluso “adecuada”, lo hago simplemente por ver hasta dónde ha llegado la arquitectura arm64 frente a x86_64. Viendo que tengo disponibilidad de estos dos equipos con similares características, es lo que me ha alentado a hacerlo. Estas son las especificaciones:
| Raspberry Pi 4 | Asus X200MA | |
|---|---|---|
| Procesador | Broadcom BCM2711 | Intel Celeron N2830 |
| Velocidad | 1.5 GHz | 2.41 GHz |
| Nucleos | 4 (Cortex A72) | 2 (Bay Trail-M) |
| Litografia | 28nm (TSMC) | 22nm (Intel) |
| L1 Cache | Data 32 KiB (x4) Instruction 48KiB(x4) |
Data 24 KiB (x2) Instruction 32KiB(x2) |
| L2 Cache | 1024KiB (x1) | 1024KiB (x1) |
| GPU | Broadcom VideoCore VI | Intel® HD Graphics for Intel Atom® Processor Z3700 Series |
| Shader Units | 4 (8 slices?) QPUs (Quad Processor Units) |
4 EU (Execution Units) |
| Frecuencia | 500 MHz | 750 MHz |
| Ram | 2GB LPDDR4-32bits-@3200MHz | 2GB DDR3L-64bits-@1333MHz |
| Ancho de Banda | Teorico: 12.8 G/s Real: 2012.37 MiB/sec |
Teorico: 10.66 G/s Real: 2222.12 MiB/sec |
| Salidas de Video | 2x Micro HDMI | x1 HDMI x1 VGA |
| Soporte Gráfico y de Video | H.265 (4kp60 decode), H264 (1080p60 decode, 1080p30 encode) OpenGL ES 3.2, OpenGL 4.5, Vulkan 1.0 |
H264 (1080p60 decode, 1080p30 encode) OpenGL ES 3.2, OpenGL 4.5, Vulkan 1.0 (parcial) |
| Almacenamiento | 32GB MicroSDHC Clase 10 UHS-I (U1) | 500GB - 2.5 SATA III - 7200rpm |
| Conectividad | 1Gbps Broadcom Ethernet + 802.11ac Wifi + Bluetooth 5 (BLE) | 100mbps Realtek RTL810xE Ethernet + 802.11b/g/n Wifi + Bluetooth 4 |
| Puertos | 2x USB 3.0, 2x USB 2.0 Raspberry Pi Standard 40 PIN GPIO Header (completamente compatible con las tablas anteriores) |
1x USB 3.0, 2x USB 2.0 |
| Entrada de Alimentación | 5V DC via USB-C connector (minimum 3A) | AC 120/230 V (50/60 Hz) - 33 Watt, 19 V, 1.75 A |
Especificaciones de ambos equipos en general. Debo añadir que lo referente a las apis que se mencionan fueron los valores que me dio el haber ejecutado
glxinfo | grep "OpenGL version"
glxinfo | grep "OpenGL ES profile version"
Esto es debido a que tengo habilitados los mesa backports en ambos sistemas con la versión 25.0.4-1~bpo12+1 disponible tanto para arm64 como x86_64. Entonces la verdad no es nada mal en términos de soporte gracias a Linux y sobre todo Debian. Por otro lado, ambos están funcionando a frecuencias de stock, es decir, que las raspberry pi 4 puede ir aún mucho mejor, empero, durante las pruebas trabaje con la frecuencia base de 1.5Ghz, mientras el N2830 llegara máximo a 2.4ghz. En ambos casos, cuentan con refrigeración activa, ventiladores por cierto, muy pequeños y relativamente silenciosos. El kernel en ambos casos fue de la misma rama LTS del 6.12 aunque con ligeros cambios. En específico el Celeron estaba con LXDE con DE mientras la raspasberry pi estaba en el clásico y fresco labwc:wlroots. A continuación se encuentran los neofetch de cada uno:
Raspberry Pi 4 de 2GB:
_,met$$$$$gg. luis@raspberrypi
,g$$$$$$$$$$$$$$$P. ----------------
,g$$P" """Y$$.". OS: Debian GNU/Linux 12 (bookworm) aarch64
,$$P' `$$$. Host: Raspberry Pi 4 Model B Rev 1.1
',$$P ,ggs. `$$b: Kernel: 6.12.25+rpt-rpi-v8
`d$$' ,$P"' . $$$ Uptime: 1 hour, 6 mins
$$P d$' , $$P Packages: 2079 (dpkg)
$$: $$. - ,d$$' Shell: bash 5.2.15
$$; Y$b._ _,d$P' DE: labwc:wlroots
Y$$. `.`"Y$$$$P"' Theme: Numix [GTK2/3]
`$$b "-.__ Icons: PiXflat [GTK2/3]
`Y$$ Terminal: lxterminal
`Y$$. Terminal Font: Monospace 10
`$$b. CPU: (4) @ 1.500GHz
`Y$$b. Memory: 510MiB / 1850MiB
`"Y$b._
`"""
Intel Celeron N2830:
_,met$$$$$gg. luis@debian-n2830
,g$$$$$$$$$$$$$$$P. -----------------
,g$$P" """Y$$.". OS: Debian GNU/Linux 12 (bookworm) x86_64
,$$P' `$$$. Host: X200MA 1.0
',$$P ,ggs. `$$b: Kernel: 6.12.22+bpo-amd64
`d$$' ,$P"' . $$$ Uptime: 1 hour, 55 mins
$$P d$' , $$P Packages: 2295 (dpkg)
$$: $$. - ,d$$' Shell: bash 5.2.15
$$; Y$b._ _,d$P' Resolution: 1366x768
Y$$. `.`"Y$$$$P"' DE: LXDE
`$$b "-.__ WM: Openbox
`Y$$ WM Theme: catppuccin-frappe
`Y$$. Theme: Arc-Dark [GTK2/3]
`$$b. Icons: Papirus-Dark [GTK2/3]
`Y$$b. Terminal: lxterminal
`"Y$b._ Terminal Font: JetBrains Mono 10
`""" CPU: Intel Celeron N2830 (2) @ 2.415GHz
GPU: Intel Atom Processor Z36xxx/Z37xxx Series Graphics & Display
Memory: 755MiB / 1854MiB
Libbenchmark
Empiezo con una biblioteca de soporte para microbenchmarks, algunas veces conocida como “Google Benchmark” utilizada principalmente para medir el rendimiento de funciones de código. El código que se ejecutó fue este:
#include <benchmark/benchmark.h>
#include <vector>
#include <numeric>
#include <cmath>
#include <random>
// 1. Prueba de memoria
static void BM_MemoryTest(benchmark::State& state) {
const int size = 1024 * (1 << state.range(0)); // Tamaño en KB
std::vector<uint8_t> data(size);
for (auto _ : state) {
uint8_t sum = 0;
for (const auto& val : data) {
sum += val;
}
benchmark::DoNotOptimize(sum);
}
state.SetBytesProcessed(state.iterations() * size);
}
BENCHMARK(BM_MemoryTest)->Arg(0)->Arg(6); // 1KB y 64KB
// 2. Prueba de operaciones enteras
static void BM_IntegerMath(benchmark::State& state) {
int a = 1;
int b = 1;
for (auto _ : state) {
for (int i = 0; i < 1000; ++i) {
benchmark::DoNotOptimize(a += b);
benchmark::DoNotOptimize(b *= a);
}
}
}
BENCHMARK(BM_IntegerMath);
// 3. Prueba de operaciones flotantes
static void BM_FloatMath(benchmark::State& state) {
float a = 1.0f;
float b = 1.0f;
for (auto _ : state) {
for (int i = 0; i < 1000; ++i) {
benchmark::DoNotOptimize(a = std::sqrt(b));
benchmark::DoNotOptimize(b = a * 1.1f);
}
}
}
BENCHMARK(BM_FloatMath);
// 4. Prueba de predicción de saltos (versión corregida)
static void BM_BranchTest(benchmark::State& state) {
const int count = 1000;
std::vector<uint8_t> flags(count); // Usamos uint8_t en lugar de bool
std::bernoulli_distribution dist(0.7);
std::mt19937 gen(42);
// Inicialización
for (int i = 0; i < count; ++i) {
flags[i] = dist(gen) ? 1 : 0;
}
int sum = 0;
for (auto _ : state) {
for (int i = 0; i < count; ++i) {
if (flags[i]) {
sum += 1;
}
}
}
benchmark::DoNotOptimize(sum);
}
BENCHMARK(BM_BranchTest);
BENCHMARK_MAIN();
Lo que se puso a prueba fue BM_MemoryTest, una pequeña prueba de ancho de banda en la memoria, donde tenemos en cuenta tres puntos claves. La eficiencia en accesos secuenciales a memoria, el ancho de banda entre CPU y RAM y, por último, el rendimiento del subsistema de memoria. Luego, BM_IntegerMath, una prueba de Operaciones Enteras donde en tres variables vemos el desempeño gracias a la velocidad en operaciones aritméticas básicas (suma, multiplicación), el rendimiento de la ALU (Unidad Aritmético-Lógica) y en últimas la latencia de operaciones dependientes (cada operación usa el resultado anterior). Por otra parte, BM_FloatMath es una prueba de operaciones de punto flotante y nos sirve para ver el rendimiento en operaciones con números decimales, la velocidad de la FPU (Unidad de Punto Flotante) y le eficiencia en cálculo de raíz cuadrada (operación costosa). Por último, BM_BranchTest es una prueba de predicción de saltos. Para entender este punto prefiero puntualizar un ejemplo, imagina que estás leyendo un libro y, de repente, una nota dice: “Ve a la página 50 para continuar la historia”. Esa nota es un salto; te desvía del flujo secuencial de páginas. Bueno, en lo que refiere esta parte del benchmark, mide eso la eficiencia del predictor de saltos y la penalización por saltos mal predichos.
Teniendo en cuenta este breve contexto, ahora sí vamos con los resultados:
| Benchmark | Métrica | BCM2711 (Media) | Celeron N2830 (Media) | Diferencia (ARM-x86) | x86_64 vs ARM64 (Rendimiento) |
|---|---|---|---|---|---|
| BM_MemoryTest/0 | Tiempo (ns) | 1381.08 | 871.97 | -509.11 (x86 más rápido) | x86 ~1.58x más rápido |
| Bytes/sec (x10⁸) | 7.41 | 11.74 | +4.33 | x86 ~1.58x mayor ancho de banda | |
| BM_MemoryTest/6 | Tiempo (ns) | 88683.64 | 56292.07 | -32391.57 | x86 ~1.58x más rápido |
| Bytes/sec (x10⁸) | 7.39 | 11.64 | +4.25 | x86 ~1.58x mayor ancho de banda | |
| BM_IntegerMath | Tiempo (ns) | 2669.91 | 1662.14 | -1007.77 | x86 ~1.61x más rápido |
| BM_FloatMath | Tiempo (ns) | 29387.26 | 15759.85 | -13627.41 | x86 ~1.86x más rápido |
| BM_BranchTest | Tiempo (ns) | 1347.01 | 837.10 | -509.91 | x86 ~1.61x más rápido |
Notas:
- Los datos de “bytes_per_sec” para operaciones matemáticas no son aplicables (0.00).
- Las desviaciones estándar (stddev) fueron mínimas en ambos casos, indicando mediciones estables.
- El coeficiente de variación (cv) es bajo, confirmando consistencia en los resultados.
- Los resultados completos de los test están adjuntados al final del artículo.
Con esto podemos decir que el Intel Celeron N2830 es aproximadamente 1.58x más rápido en ambos tests de memoria (BM_MemoryTest/0 y /6) ademas de contar con mayor ancho de banda con un aproximado de ~11.7 vs ~7.4 x10⁸ bytes/sec. En operaciones matemáticas tenemos dos variables, en enteros, x86_64 es 1.61x más rápido (1662 ns vs 2669 ns) mientras que en flotantes la ventaja de x86_64 aumenta a 1.86x (15759 ns vs 29387 ns). Por último, en la prediccion de saltos o “Branch Prediction” x86_64 es 1.61x más rápido en pruebas de bifurcación.
Sysbench
Es un clásico esta herramienta de benchmarking y pruebas de rendimiento multiplataforma (Linux, Windows, macOS), diseñada para evaluar diferentes aspectos de un sistema, como lo es cpu, memoria, almacenamiento y bases de datos. En este caso hice pruebas en la CPU y la memoria.
| Métrica | BCM2711 | Celeron N2830 | Diferencia | Rendimiento Relativo |
|---|---|---|---|---|
| CPU - Eventos/seg | 579.89 | 192.83 | +387.06 | arm64 ~3x más rápido |
| CPU - Latencia (avg) | 1.72 ms | 5.18 ms | -3.46 ms | arm64 3x menor latencia |
| Memoria - MiB/seg | 2012.37 MiB/s | 2222.12 MiB/s | -209.75 MiB/s | amd64 ~1.1x más rápido |
| Memoria - Operaciones/seg | 2,060,663.64 ops/s | 2,275,448.35 ops/s | -214,784.71 ops/s | amd64 ~1.1x más rendimiento |
Aquí las conclusiones son arrolladoras, la Raspberry Pi 4 domina ampliamente en rendimiento de CPU (3x más eventos/seg y latencia 3x menor). Lo que significa que el Celeron N2830 tiene un rendimiento significativamente menor (66.7% menos eventos/seg). Cuando hablamos de memoria, N2830 es ligeramente mejor (~10%) en velocidad de escritura y rendimiento. Supongo que se debe a tener un bus de 64bits frente a los 32bits de arm64. A nivel general, podemos ver que si el uso es CPU-intensivo como llega a ser servidores, cálculos, programas o navegación por internet, el BCM2711 es claramente superior. Por otro lado, para cargas centradas en memoria (ej. bases de datos), el Celeron N8230 tiene una ligera ventaja.
Timed Mesa Compilation
Decidí incluir un benchmark de la phoronix-test-suite a esta comparativa para tener alguna idea más precisa. Luego de intentar por una buena cantidad de tiempo, por fin pude ejecutar en ambos sistemas la prueba de Timed Mesa Compilation, una breve prueba de cuánto tiempo lleva compilar Mesa con Meson/Ninja. Al principio presento fallos debido a que descargaba y compilaba la versión 21, sin embargo, en artículos recientes de Phoronix vi que usaban Mesa 24 o lo que es dentro de la suite la versión build-mesa-1.1.0. Después de un tiempo, por fin pudo funcionar correctamente. Debo admitir que intenté hacer otros test, pero la paciencia me terminó ganando debido a que bajaba versiones desactualizadas. Sin más, aquí los resultados:
| Métrica | ARMv8 Cortex-A72 (RPi 4) | Intel Celeron N2830 (x86) | Diferencia (ARM - Intel) | Diferencia % (vs Intel) |
|---|---|---|---|---|
| Tiempo (segundos) | 727.452 | 1017.378 | -289.926 | -28.5% (más rápido) |
| Error Estándar | ±2.08 | ±3.84 | -1.76 | -45.8% |
| Desviación Estándar | 0.50% | 0.65% | -0.15% | -23.1% |
Sin duda alguna, el ARM Cortex-A72 supera significativamente al Intel Celeron N2830 en esta prueba (+28.5% de velocidad). Curiosamente, el ARM también muestra una ligera menor cantidad de variabilidad.
Geekbench 6.4
Se trata de uno de los benchmarks mas famosos del mundo por lo que ire al grano. A nivel general:
| Métrica | Raspberry Pi 4 (ARM A72) | Celeron N2830 (x86) | Diferencia (%) |
|---|---|---|---|
| Single-Core Score | 257 | 182 | +41.2% (Pi 4 mejor) |
| Multi-Core Score | 536 | 251 | +113.5% (Pi 4 más del doble) |
A nivel single-core este es un destacado de las pruebas mas relevantes:
| Prueba | Pi 4 (A72) | N2830 (x86) | Diferencia (%) |
|---|---|---|---|
| File Compression | 278 (39.9 MB/s) | 248 (35.6 MB/s) | +12.1% |
| HTML5 Browser | 337 (6.89 p/s) | 289 (5.91 p/s) | +16.6% |
| PDF Renderer | 390 (8.99 Mp/s) | 373 (8.60 Mp/s) | +4.6% |
| Clang (Compilación) | 360 (1.77 Klines/s) | 343 (1.69 Klines/s) | +5.0% |
| Ray Tracer | 308 (298.3 Kp/s) | 243 (235.4 Kp/s) | +26.7% |
La Pi 4 supera al Celeron N2830 en todas las pruebas single-core, con mejoras de 4.6% a 41.2%.
Cuando hablamos del multi-core:
| Prueba | Pi 4 (A72) | N2830 (x86) | Diferencia (%) |
|---|---|---|---|
| File Compression | 306 (43.9 MB/s) | 324 (46.6 MB/s) | -5.6% (N2830 mejor) |
| HTML5 Browser | 722 (14.8 p/s) | 291 (5.96 p/s) | +148.1% (Pi 4 domina) |
| Clang (Compilación) | 1004 (4.94 Klines/s) | 605 (2.98 Klines/s) | +66.0% |
| Asset Compression | 1273 (39.4 MB/s) | 582 (18.0 MB/s) | +118.7% |
Cuando hablamos de rendimiento de varios núcleos, la Pi 4 es muy superior en multi-core siendo hasta +148% en navegación web. El único caso donde se queda por detrás es en la compresión de archivos, el N2830 es 5.6% más rápido (posiblemente por mejor soporte de instrucciones x86).
Ya a un nivel general, la Pi 4 es superior en ambos escenarios, pero su ventaja es mucho más notable en multi-core debido a su arquitectura y los núcleos adicionales. En el ámbito Single-Core sus diferencias son algo más moderadas (~25-30%), excepto en puntuación general (+41%). Aunque sigue siendo impresionante desde mi punto de vista. Por otro lado, en multi-Core la Pi 4 domina, con casi el doble de rendimiento en cargas optimizadas para paralelismo.
pytest-benchmark
Hablamos de un plugin para pytest (el popular framework de testing en Python) diseñado específicamente para medir y comparar el rendimiento de tu código Python mediante benchmarks. El código que se ejecuto en este caso es este:
import pytest
import random
import math
# 1. Prueba de operaciones matemáticas
def test_factorial(benchmark):
def factorial(n):
return 1 if n <= 1 else n * factorial(n-1)
benchmark(factorial, 100)
# 2. Prueba de acceso a listas
def test_list_operations(benchmark):
def list_ops(size):
lst = list(range(size))
random.shuffle(lst)
return sorted(lst)
benchmark(list_ops, 1000)
# 3. Prueba de operaciones con strings
def test_string_manipulation(benchmark):
def str_ops(times):
s = ''
for i in range(times):
s += str(i)
return s
benchmark(str_ops, 1000)
# 4. Prueba de operaciones NumPy (opcional)
def test_numpy_operations(benchmark):
numpy = pytest.importorskip("numpy") # Requiere numpy instalado
def numpy_ops(size):
a = numpy.random.rand(size)
return numpy.fft.fft(a)
benchmark(numpy_ops, 1024)
# 5. Prueba con parámetros variables
@pytest.mark.parametrize("size", [10, 100, 1000])
def test_with_parameters(benchmark, size):
benchmark(lambda: sum(range(size)))
Explicaré brevemente lo que evalua este codigo, en test_factorial se hace un cálculo recursivo del factorial de 100 cuyo efecto es medir la velocidad de operaciones matemáticas recursivas (CPU-bound). Para test_list_operations se hace la creación, mezcla y ordenamiento de una lista, donde al final se evalua el rendimiento en manipulación de listas (memoria y algoritmos). Por otro lado, en test_string_manipulation se hace una concatenación de strings en un bucle y como tal sirve para probar la eficiencia de operaciones con strings (inmutabilidad en Python). En test_numpy_operations se compara el rendimiento en cálculos científicos y por último, en test_with_parameters interesa analizar cómo escala el rendimiento con diferentes volúmenes de datos.
| Test | arm64_mean (s) | amd64_mean (s) | Δ Mean (%) | arm64_ops | amd64_ops | Δ Ops (%) |
|---|---|---|---|---|---|---|
| test_numpy_operations | 0.000076 | 0.000169 | +121.40 | 13,226.42 | 5,973.96 | −54.83 |
| test_factorial | 0.000049 | 0.000071 | +44.41 | 20,448.96 | 14,160.58 | −30.75 |
| test_with_parameters[10] | 0.000001437 | 0.000001769 | +23.13 | 696,028.62 | 565,265.30 | −18.79 |
| test_with_parameters[100] | 0.000003003 | 0.000003389 | +12.86 | 332,926.63 | 294,992.13 | −11.39 |
| test_with_parameters[1000] | 0.00003125 | 0.00003142 | +0.54 | 32,006.05 | 31,835.65 | −0.53 |
| test_string_manipulation | 0.0003955 | 0.0004339 | +9.47 | 2,528.69 | 2,309.93 | −8.65 |
| test_list_operations | 0.001195 | 0.001053 | −11.80 | 837.00 | 949.03 | +13.38 |
En general ARM64 muestra mejor rendimiento en la mayoría de las pruebas, especialmente en operaciones numéricas (test_numpy_operations, test_factorial), donde supera a AMD64 por márgenes significativos (+121.4% y +44.41% respectivamente). Sorprendente es que AMD64 solo supera a ARM64 en test_list_operations (−11.8% en tiempo, +13.38% en operaciones por segundo), lo que sugiere que su arquitectura puede manejar mejor ciertas operaciones con listas. Estos resultados me hacen pensar que un Bay-trail de 4 nucleos seria capaz de plantar cara de tu a tu contra una raspberry pi 4, por lo menos en este enfoque. A un nivel masivo, las diferencias se reducen en cargas escalables (1000) lo que da a entender que la elección de arquitectura es menos crítica.
7zip
Comprimir y descomprimir, algo muy normal en el mundo cotidiano. Por suerte 7zip tiene su benchmark integrado, aqui los resultados:
| 7zip | Pi 4 (A72) | N2830 (x86) | Diferencia (%) |
|---|---|---|---|
| Compresión (KiB/s) | 3,810 (Avr) | 2,693 (Avr) | +41.5% (Pi 4 más rápido) |
| Descompresión (KiB/s) | 6,331 (Avr) | 4,045 (Avr) | +56.5% (Pi 4 más rápido) |
| MIPS (Compresión) | 1,129 | 1,620 | -30.3% (N2830 tiene mejor IPC) |
| MIPS (Descomp.) | 1,590 | 2,032 | -21.8% (N2830 más eficiente) |
| Rating Total | 5,070 | 3,369 | +50.5% (Pi 4 mejor puntuación) |
En compresión, la Raspberry Pi 4 es un +41.5% más rápido que un Celeron N2830. En descompresión, esta diferencia se eleva a un +56.5%. Ahora esto no significa que sea una paliza en todo el sentido, ya que en términos de eficiencia por ciclo de instrucción (MIPS) cambia un poco la cosa. X86 sigue manteniendo mayor eficiencia por ciclo gracias a su arquitectura, tomando una ventaja del 30.3% en compresión en comparación con la Pi 4. Tendencia que se mantiene en la descompresión, llegando a una ventaja del 21.8%. Como dato no menos importante, la Pi 4 usa unos 882 MB (48% de su RAM) en comparación al N2830 que usa 441 MB (24% de su RAM). Diferencia que se comprende en tanto la Pi 4 necesita asignar más memoria para optimizar el rendimiento
Silverbench
Es una herramienta de benchmarking online diseñada principalmente para evaluar el rendimiento de la CPU tanto de computadores como moviles. Su particularidad es que funciona completamente en el navegador, utilizando JavaScript y un motor de renderizado de mapeo de fotones para simular cargas de trabajo exigentes.
| Sistema | Puntuación SilverBench | Diferencia |
|---|---|---|
| Intel Celeron N2830 (x86, 2 núcleos @ 2.16 GHz) | 1920 pts | +8.2% frente al Pi 4 |
| Raspberry Pi 4 (ARM Cortex-A72, 4 núcleos @ 1.5 GHz) | 1775 pts |
Aquí podríamos afirmar con cierta duda que gracias a una mayor frecuencia (2.16 GHz vs 1.5 GHz) y mejor IPC en ciertas cargas es debido a que sale ganando nuestro N2830 que como ya habíamos podido confirmar antes, tiene instrucciones x86 optimizadas para operaciones matemáticas simples, lo que lo hace destacar en benchmarks sintéticos como SilverBench.
hdparm
Nuestra ultima prueba se reduce a ver la potencia del disco en nuestro sistemas, ya muy conocida por cierto al ahora de medir el desempeño. Aqui estan los resultados:
| Métrica | Raspberry Pi 4 (microSD /dev/mmcblk0) | Celeron N2830 (HDD SATA /dev/sda) |
|---|---|---|
| Cached Reads (MB/sec) | 980.52 | 1439.43 |
| Buffered Disk Reads (MB/sec) | 43.24 | 120.31 |
A nivel general, no se puede sorprender, un HDD SATA sigue siendo mucho más rápido que una microsd clase 10. Hablamos de casi un +178% de mejoría frente la Raspberry Pi 4. En mi caso necesitaba de estos datos, ya que estoy llevando a cabo un proyecto de mejorar la raspberry pi y necesito algunos números de referencia
Conclusiones:
Después de todo esto, puedo decir que, en primer lugar, para el ambiente multihilo, es decir, las cargas paralelizables se realizan en la Rasbperry Pi 4 de forma increíble gracias a sus 4 núcleos (vs 2 del N2830). Esto en benchmarks y numeros se refleja en casos como Geekbench 6 Multi-Core: +113.5% (536 vs 251 pts) o cuando se hizo la compilación de Mesa siendo un 28.5% más rápida, y como olvidar la prueba de sysbench CPU teniendo casi 3x más eventos/seg y una latencia 3x menor. En el caso de mononucleo el N2830 es más eficiente por ciclo (mayor IPC en x86), pero su limitación de 2 núcleos lo hace perder en rendimiento bruto, mientras en los benchmarks sintéticos (SilverBench), el N2830 supera al Pi 4 en un 8.2% debido a su mayor frecuencia (2.16 GHz vs 1.5 GHz) y optimizaciones para operaciones matemáticas simples. Cuando nos referimos a la memoria y ancho de banda, en este último el N2830 tiene ventaja (~1.58x mayor en libbenchmark) debido a su bus de memoria de 64 bits (vs 32 bits del Pi 4) y que aun logra conservar cierta distancia en la prueba de sysbench que hace uso de la memoria, el N2830 es ~10% más rápido en operaciones secuenciales. Empero, la Pi 4 compensa con mejor gestión de caché y paralelismo en cargas multihilo. En almacenamiento de momento, no mucho más que decir, el HDD es 2.78x más rápido que la microsd, espero dentro de poco hacer un upgrade para ver que tanto puede hacer un rp4 sin limitaciones. Por último, en el apartado multimedia, la Raspberry Pi 4 claramente es superior, tanto a nivel de apis como soporte para codificar y descodificar (algo que se “perdió” con la Rpi5) así como cuando hablamos del nivel de eficiencia energética.
Espero que sea de ayuda esta comparativa para quien la necesite. A continuación, los anexos donde están todas las pruebas de los resultados.
Anexos:
Resultados Libbenchmark en Rp4:
python3 resultados.py
name time_ns iterations bytes_per_sec
0 BM_MemoryTest/0 1381.061364 2027382 7.414587e+08
1 BM_MemoryTest/0 1381.080228 2027382 7.414486e+08
2 BM_MemoryTest/0 1381.089508 2027382 7.414436e+08
3 BM_MemoryTest/0_mean 1381.077033 3 7.414503e+08
4 BM_MemoryTest/0_median 1381.080228 3 7.414486e+08
5 BM_MemoryTest/0_stddev 0.014341 3 7.699310e+03
6 BM_MemoryTest/0_cv 0.000010 3 1.038412e-05
7 BM_MemoryTest/6 88686.139152 31577 7.389655e+08
8 BM_MemoryTest/6 88683.999652 31577 7.389834e+08
9 BM_MemoryTest/6 88680.784527 31577 7.390102e+08
10 BM_MemoryTest/6_mean 88683.641110 3 7.389863e+08
11 BM_MemoryTest/6_median 88683.999652 3 7.389834e+08
12 BM_MemoryTest/6_stddev 2.695258 3 2.245928e+04
13 BM_MemoryTest/6_cv 0.000030 3 3.039201e-05
14 BM_IntegerMath 2669.947300 1048863 0.000000e+00
15 BM_IntegerMath 2669.874466 1048863 0.000000e+00
16 BM_IntegerMath 2669.896879 1048863 0.000000e+00
17 BM_IntegerMath_mean 2669.906215 3 0.000000e+00
18 BM_IntegerMath_median 2669.896879 3 0.000000e+00
19 BM_IntegerMath_stddev 0.037304 3 0.000000e+00
20 BM_IntegerMath_cv 0.000014 3 0.000000e+00
21 BM_FloatMath 29387.805175 95347 0.000000e+00
22 BM_FloatMath 29383.126013 95347 0.000000e+00
23 BM_FloatMath 29390.839156 95347 0.000000e+00
24 BM_FloatMath_mean 29387.256781 3 0.000000e+00
25 BM_FloatMath_median 29387.805175 3 0.000000e+00
26 BM_FloatMath_stddev 3.885704 3 0.000000e+00
27 BM_FloatMath_cv 0.000132 3 0.000000e+00
28 BM_BranchTest 1347.014459 2078667 0.000000e+00
29 BM_BranchTest 1347.038835 2078667 0.000000e+00
30 BM_BranchTest 1346.972099 2078667 0.000000e+00
31 BM_BranchTest_mean 1347.008464 3 0.000000e+00
32 BM_BranchTest_median 1347.014459 3 0.000000e+00
33 BM_BranchTest_stddev 0.033769 3 0.000000e+00
34 BM_BranchTest_cv 0.000025 3 0.000000e+00
Resultados Libbenchmark en N2830:
python3 resultados.py
name time_ns iterations bytes_per_sec
0 BM_MemoryTest/0 872.043367 3211852 1.174254e+09
1 BM_MemoryTest/0 872.005919 3211852 1.174304e+09
2 BM_MemoryTest/0 871.867722 3211852 1.174490e+09
3 BM_MemoryTest/0_mean 871.972336 3 1.174349e+09
4 BM_MemoryTest/0_median 872.005919 3 1.174304e+09
5 BM_MemoryTest/0_stddev 0.092513 3 1.246001e+05
6 BM_MemoryTest/0_cv 0.000106 3 1.061014e-04
7 BM_MemoryTest/6 56293.993405 49736 1.164174e+09
8 BM_MemoryTest/6 56293.714714 49736 1.164180e+09
9 BM_MemoryTest/6 56288.516487 49736 1.164287e+09
10 BM_MemoryTest/6_mean 56292.074869 3 1.164214e+09
11 BM_MemoryTest/6_median 56293.714714 3 1.164180e+09
12 BM_MemoryTest/6_stddev 3.084798 3 6.380074e+04
13 BM_MemoryTest/6_cv 0.000055 3 5.480157e-05
14 BM_IntegerMath 1662.140337 1684551 0.000000e+00
15 BM_IntegerMath 1662.137695 1684551 0.000000e+00
16 BM_IntegerMath 1662.132615 1684551 0.000000e+00
17 BM_IntegerMath_mean 1662.136882 3 0.000000e+00
18 BM_IntegerMath_median 1662.137695 3 0.000000e+00
19 BM_IntegerMath_stddev 0.003925 3 0.000000e+00
20 BM_IntegerMath_cv 0.000002 3 0.000000e+00
21 BM_FloatMath 15759.737304 177654 0.000000e+00
22 BM_FloatMath 15759.897531 177654 0.000000e+00
23 BM_FloatMath 15759.906847 177654 0.000000e+00
24 BM_FloatMath_mean 15759.847227 3 0.000000e+00
25 BM_FloatMath_median 15759.897531 3 0.000000e+00
26 BM_FloatMath_stddev 0.095311 3 0.000000e+00
27 BM_FloatMath_cv 0.000006 3 0.000000e+00
28 BM_BranchTest 837.078773 3344630 0.000000e+00
29 BM_BranchTest 837.114307 3344630 0.000000e+00
30 BM_BranchTest 837.103385 3344630 0.000000e+00
31 BM_BranchTest_mean 837.098822 3 0.000000e+00
32 BM_BranchTest_median 837.103385 3 0.000000e+00
33 BM_BranchTest_stddev 0.018201 3 0.000000e+00
34 BM_BranchTest_cv 0.000022 3 0.000000e+00
Resultados Sysbench CPU en Rp4:
sysbench cpu --cpu-max-prime=20000 run
sysbench 1.0.20 (using system LuaJIT 2.1.0-beta3)
Running the test with following options:
Number of threads: 1
Initializing random number generator from current time
Prime numbers limit: 20000
Initializing worker threads...
Threads started!
CPU speed:
events per second: 579.89
General statistics:
total time: 10.0013s
total number of events: 5802
Latency (ms):
min: 1.71
avg: 1.72
max: 3.81
95th percentile: 1.73
sum: 9998.30
Threads fairness:
events (avg/stddev): 5802.0000/0.00
execution time (avg/stddev): 9.9983/0.00
Resultados Sysbench memoria en Rp4:
sysbench memory run
sysbench 1.0.20 (using system LuaJIT 2.1.0-beta3)
Running the test with following options:
Number of threads: 1
Initializing random number generator from current time
Running memory speed test with the following options:
block size: 1KiB
total size: 102400MiB
operation: write
scope: global
Initializing worker threads...
Threads started!
Total operations: 20615013 (2060663.64 per second)
20131.85 MiB transferred (2012.37 MiB/sec)
General statistics:
total time: 10.0001s
total number of events: 20615013
Latency (ms):
min: 0.00
avg: 0.00
max: 1.77
95th percentile: 0.00
sum: 4862.72
Threads fairness:
events (avg/stddev): 20615013.0000/0.00
execution time (avg/stddev): 4.8627/0.00
Resultados Sysbench CPU en N2830:
sysbench cpu --cpu-max-prime=20000 run
sysbench 1.0.20 (using system LuaJIT 2.1.0-beta3)
Running the test with following options:
Number of threads: 1
Initializing random number generator from current time
Prime numbers limit: 20000
Initializing worker threads...
Threads started!
CPU speed:
events per second: 192.83
General statistics:
total time: 10.0012s
total number of events: 1929
Latency (ms):
min: 5.18
avg: 5.18
max: 6.17
95th percentile: 5.18
sum: 9998.73
Threads fairness:
events (avg/stddev): 1929.0000/0.00
execution time (avg/stddev): 9.9987/0.00
Resultados Sysbench memoria en N2830:
sysbench memory run
sysbench 1.0.20 (using system LuaJIT 2.1.0-beta3)
Running the test with following options:
Number of threads: 1
Initializing random number generator from current time
Running memory speed test with the following options:
block size: 1KiB
total size: 102400MiB
operation: write
scope: global
Initializing worker threads...
Threads started!
Total operations: 22760459 (2275448.35 per second)
22227.01 MiB transferred (2222.12 MiB/sec)
General statistics:
total time: 10.0001s
total number of events: 22760459
Latency (ms):
min: 0.00
avg: 0.00
max: 0.19
95th percentile: 0.00
sum: 4921.46
Threads fairness:
events (avg/stddev): 22760459.0000/0.00
execution time (avg/stddev): 4.9215/0.00
- Resultados del tiempo de compilacion de mesa 24 en Raspberry Pi 4
- Resultados del tiempo de compilacion de mesa 24 en N2830
- Resultados de Geekbench 6.4 en Raspberry Pi 4
- Resultados de Geekbench 6.4 en N2830
- Resultados completos de pytest aqui.
Resultados 7zip en Rp4:
7z b
7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=es_CO,Utf16=on,HugeFiles=on,64 bits,4 CPUs LE)
LE
CPU Freq: - - - - - - - - -
RAM size: 1826 MB, # CPU hardware threads: 4
RAM usage: 882 MB, # Benchmark threads: 4
Compressing | Decompressing
Dict Speed Usage R/U Rating | Speed Usage R/U Rating
KiB/s % MIPS MIPS | KiB/s % MIPS MIPS
22: 3997 341 1140 3889 | 74487 398 1596 6355
23: 3837 351 1115 3910 | 73425 398 1594 6353
24: 3755 360 1122 4038 | 72203 399 1590 6338
25: 2980 299 1137 3403 | 70521 398 1578 6276
---------------------------------- | ------------------------------
Avr: 338 1129 3810 | 398 1590 6331
Tot: 368 1359 5070
Resultados 7zip en n2380:
7z b
7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=es_CO.UTF-8,Utf16=on,HugeFiles=on,64 bits,2 CPUs Intel(R) Celeron(R) CPU N2830 @ 2.16GHz (30678),ASM)
Intel(R) Celeron(R) CPU N2830 @ 2.16GHz (30678)
CPU Freq: 64000000 64000000 - - - - - - -
RAM size: 1860 MB, # CPU hardware threads: 2
RAM usage: 441 MB, # Benchmark threads: 2
Compressing | Decompressing
Dict Speed Usage R/U Rating | Speed Usage R/U Rating
KiB/s % MIPS MIPS | KiB/s % MIPS MIPS
22: 2665 161 1611 2593 | 47502 199 2039 4056
23: 2524 158 1627 2572 | 46841 199 2036 4055
24: 2552 168 1633 2744 | 45993 199 2029 4038
25: 2507 178 1611 2863 | 45284 199 2026 4031
---------------------------------- | ------------------------------
Avr: 166 1620 2693 | 199 2032 4045
Tot: 183 1826 3369
Imagen de SilverBench en rp4:
Imagen de SilverBench en n2380:
Resultados hdparm en rpi4:
luis@raspberrypi:~ $ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
mmcblk0 179:0 0 29G 0 disk
|-mmcblk0p1 179:1 0 512M 0 part /boot/firmware
`-mmcblk0p2 179:2 0 28,5G 0 part /
luis@raspberrypi:~ $ sudo hdparm -tT /dev/mmcblk0
/dev/mmcblk0:
Timing cached reads: 1960 MB in 2.00 seconds = 980.52 MB/sec
Timing buffered disk reads: 130 MB in 3.01 seconds = 43.24 MB/sec
Resultados hdparm en n2380:
luis@debian-n2830:~$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 465,8G 0 disk
├─sda1 8:1 0 512M 0 part /boot/efi
├─sda2 8:2 0 464,3G 0 part /
└─sda3 8:3 0 976M 0 part [SWAP]
luis@debian-n2830:~$ sudo hdparm -tT /dev/sda
/dev/sda:
Timing cached reads: 2872 MB in 2.00 seconds = 1439.43 MB/sec
Timing buffered disk reads: 362 MB in 3.01 seconds = 120.31 MB/sec
Bibliografia:
https://docs.broadcom.com/doc/12358545
https://en.wikipedia.org/wiki/VideoCore
Sobre las “8 slices”: Es en este punto donde hay cierta confusión. Las especificaciones de Broadcom de la VideoCore VI indican 4 QPUs. Sin embargo, algunas fuentes y herramientas de depuración reportan 8 QPUs debido a la forma en que se organizan los “slices” dentro de la GPU. Para propósitos de comparación general, se suele referir a ella como una mejora significativa sobre la VideoCore IV. Todo esto a raiz de que la VideoCore VI tiene “slices” que contienen las QPUs. Mientras que se pueden contabilizar 8 QPUs en total de forma interna, la arquitectura es diferente a la de las VideoCore IV y VII. Para simplificar, la cifra de “4 QPUs” se utiliza comúnmente en las especificaciones oficiales de la VC6.
https://forum.rvspace.org/t/has-anyone-here-had-the-guts-to-delid-the-cpu-and-grab-a-die-shot/1080/3
-
https://www.howtoforge.com/how-to-benchmark-your-system-cpu-file-io-mysql-with-sysbench
-
https://nksistemas.com/prueba-de-rendimiento-en-tu-linux-con-sysbench/
-
[https://www.geeksforgeeks.org/linux-unix/hdparm-command-in-linux-with-examples/] (https://www.geeksforgeeks.org/linux-unix/hdparm-command-in-linux-with-examples/)