For a number of years now LG have been making use of 64-bit processors in their LG TV SOCs, at least from my experience of looking into this on the CX, C1, C2 and C3 TVs.
e.g. on my C3:
uname -a
Linux LGwebOSTV 5.4.268-320 #1 SMP PREEMPT Mon Jun 17 01:25:25 UTC 2024 aarch64 GNU/Linux
But instead of shipping a 64-bit userspace to go with it, LG have been continuing to ship a 32-bit userspace only, running in a backwards compatible mode:
getconf LONG_BIT
32
C3 CPU
Architecture: aarch64
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0,1
Off-line CPU(s) list: 2,3
Vendor ID: ARM
Model name: Cortex-A76
Isn’t it about time you switched to a 64-bit tool chain? The Cortex-A76 processor might see a performance uplift of 20%+ by doing so.
It would also increase compatibility as the likes of Google stopped supporting armv7a a while back.
Please do this for future webOS releases. For people who create native apps, it wouldn’t be a big change for them to recompile those apps in 64-bit so that they would work!
We don’t have much relevance to software development of LG devices. For questions/issues about the LG Device and its software, please contact LG customer service center in your region. Thank you.
You’re absolutely right to raise this issue—LG has indeed been using 64-bit capable processors like the Cortex-A76 in their TVs (such as the C3), yet still ships a 32-bit userspace. As you’ve noted, even though the underlying hardware supports 64-bit (as evidenced by the aarch64 architecture), the system reports getconf LONG_BIT as 32, confirming the limited userspace.
Sticking to a 32-bit userspace in 2025 is not only holding back potential performance improvements—likely over 20% in some workloads—but it’s also creating unnecessary compatibility issues. Many modern libraries and applications, especially from major platforms like Google, are already dropping 32-bit support in favor of more secure and performant 64-bit environments. Moving to a full 64-bit toolchain would allow developers to fully leverage the hardware and simplify development for native apps on webOS.
Hopefully, LG takes feedback like this seriously and transitions to a 64-bit userspace in upcoming webOS versions. It would be a forward-thinking move for performance, compatibility, and developer support.
If you’re downloading tutorial videos or development-related content from YouTube to analyze webOS or LG TV behavior further, tools like ssyoutube.online – a YouTube video downloader – can help you save videos quickly and easily.
To prove this, how much your current customers are missing out on performance of this change here are some benchmarks I did on a LG G4 OLED. The only change was switching to a 64-bit compiler instead of the current 32-bit one.
Please consider switching in future webOS versions!
ARMv7‑A softfp vs ARMv8‑A (AArch64) Benchmark Comparison
CoreMark (Integer Workloads)
| Metric |
ARMv7‑A softfp |
ARMv8‑A (AArch64) |
Relative Difference |
| Iterations/sec |
29,025 |
34,646 |
~+19% |
| Total time (secs) |
15.159 |
12.700 |
Faster on ARMv8 |
| Iterations |
440,000 |
440,000 |
Same workload |
| Validation |
Correct |
Correct |
Both validated |
SciMark2 (Floating‑Point Workloads, Default -Os)
| Kernel |
ARMv7‑A softfp |
ARMv8‑A (AArch64) |
Relative Difference |
| Composite |
547.15 |
706.89 |
~+29% overall |
| FFT |
515.76 Mflops |
717.95 Mflops |
~+39% |
| SOR |
508.38 Mflops |
561.64 Mflops |
~+10% |
| Monte Carlo |
232.43 Mflops |
128.91 Mflops |
~‑45% (slower) |
| Sparse MM |
670.36 Mflops |
1057.57 Mflops |
~+58% |
| LU |
808.82 Mflops |
1068.38 Mflops |
~+32% |
SciMark2 (Floating‑Point Workloads, -O3 Optimized)
| Kernel |
ARMv7‑A softfp |
ARMv8‑A (AArch64) |
Relative Difference |
| Composite |
758.81 |
1173.62 |
~+55% overall |
| FFT |
604.05 Mflops |
849.02 Mflops |
~+41% |
| SOR |
812.77 Mflops |
961.39 Mflops |
~+18% |
| Monte Carlo |
225.99 Mflops |
206.58 Mflops |
~‑9% (slower) |
| Sparse MM |
742.25 Mflops |
1159.88 Mflops |
~+56% |
| LU |
1408.97 Mflops |
2691.22 Mflops |
~+91% |