61–69 of 69 posts
Earlier quoted context omitted.
"off-package dram" Yes, the real ARM vs. x86 discussion will come around Ryzen Max 2025Q1 with 128mb on-package dram (hope we get desktop board manufacturers to sell this).
what does 128mb on package dram help with? That seems like it's way to small to suspend to ram or anything.
Joke aside, typo, s/mb/gb/g - thanks for catching.
Earlier quoted context omitted.
My experience with our riscv build deamons in Debian is everything works, but there is some spurious segfaults from time to time. Check the green build matrix on this page: https://qa.debian.org/developer.php?login=alexander.kjall%40...
It is kind of amazing where the build process is[0][1]. 0. https://buildd.debian.org/status/architecture.php?a=riscv64&... 1. https://buildd.debian.org/stats/graph-week-big.png
E.g. arm64 dropped very low for a while or all arches dropped around 2024.68
Earlier quoted context omitted.
>good luck compiling LLVM on it 4 cores, thus 2GB/core. Plenty.
I regularly get OOMs at 16 GB/core doing debug builds. LLVM is practically a memory stress test.
GCC on the other hand is another story. On a machine that I was able to compiled LLVM (thanks swap), I couldn't even extract GCC source code.
Earlier quoted context omitted.
It is kind of amazing where the build process is[0][1]. 0. https://buildd.debian.org/status/architecture.php?a=riscv64&... 1. https://buildd.debian.org/stats/graph-week-big.png
Anyone familiar with debian can explain what these drops in percentages are? E.g. arm64 dropped very low for a while or all arches dropped around 2024.68 https://buildd.debian.org/stats/graph-quarter.png
If there's a huge drop, it is most of the time because a package a lot of software depends on got updated or modified (e.g. built with different options) and it caused ABI changes, thus causing rebuilds of everything that depends on it.
Earlier quoted context omitted.
The biggest thing I want to see from framework is ARM (or better, Risc-V that achieves great low power performance) with an enormous battery and linux or BSD with all the optimizations to improve battery life. I bought a macbook a while ago specifically because I can get it to last about 45-50 hours non-stop usage on one charge, so getting a system tailored for even better performance and a longer battery life (macbo…
Between Zoom (not the whole time, but just by having it in the background), Slack and Crowdstrike's Falcon agent, I usually can't make more than 5 or 6 hours away of a wall outlet with my MacBook Pro M2 Max... I hate corporate software.
I usually get barely a working day out of my corporate MacBook Pro M1 with Corpo Security Special Sauce, CLion and Teams. But I have to kill CLion when it gets too crazy (i.e. often). Do you have any insights from Activity Monitor on who is draining the battery?
My biggest offenders: - Symantec Data Loss Prevention Agent (x86 Emulation) - $Corporation App Store (I never use it, don't know why it burns CPU time)
This corporate "security" software is the essence of everything that's wrong with a corporation.
Earlier quoted context omitted.
Performance per watt is nearly identical for the Apple M4 and the Ryzen AI 9 HX 370, despite the Ryzen being manufactured on 4nm while the M4 is on 3nm: https://www.phoronix.com/review/apple-m4-intel-amd-linux/3 Sorry to burst your bubble.
The biggest thing I want to see from framework is ARM (or better, Risc-V that achieves great low power performance) with an enormous battery and linux or BSD with all the optimizations to improve battery life. I bought a macbook a while ago specifically because I can get it to last about 45-50 hours non-stop usage on one charge, so getting a system tailored for even better performance and a longer battery life (macbo…
A lot of comments are focusing on the value as a RISC-V development platform, which is obviously important, but I'm also hopeful that this presages more Framework mainboard options besides just what Framework itself offers. There is already a pretty big community offering I/O modules beyond Framework's options, but the true benefit of a Framework system is in the ability to not be locked in to only what one company t…
There's not really a lot of room for anyone to make a board that isn't a curiosity or highly-specific developer platform though. Framework already have both x86 vendors covered for people who want Intel or AMD. The only other chip worth making a board for is Snapdragon X Elite. There's nothing else in the same performance class.
Earlier quoted context omitted.
Performance per watt is nearly identical for the Apple M4 and the Ryzen AI 9 HX 370, despite the Ryzen being manufactured on 4nm while the M4 is on 3nm: https://www.phoronix.com/review/apple-m4-intel-amd-linux/3 Sorry to burst your bubble.
The biggest thing I want to see from framework is ARM (or better, Risc-V that achieves great low power performance) with an enormous battery and linux or BSD with all the optimizations to improve battery life. I bought a macbook a while ago specifically because I can get it to last about 45-50 hours non-stop usage on one charge, so getting a system tailored for even better performance and a longer battery life (macbo…
Earlier quoted context omitted.
Between Zoom (not the whole time, but just by having it in the background), Slack and Crowdstrike's Falcon agent, I usually can't make more than 5 or 6 hours away of a wall outlet with my MacBook Pro M2 Max... I hate corporate software.
Oh, wow. That's a pity. I mean, you're down to the battery time of any random x86 laptop. I usually get barely a working day out of my corporate MacBook Pro M1 with Corpo Security Special Sauce, CLion and Teams. But I have to kill CLion when it gets too crazy (i.e. often). Do you have any insights from Activity Monitor on who is draining the battery? My biggest offenders: - Symantec Data Loss Prevention Agent (x86 Em…
But that only shows "Apps", not processes. If I list all processes, the one that's almost always in the top is Crowdstrike Falcon. Specially when there's disk access, as it seems to intercept everything...
