| 9 Jul 2025 |
 fgaz | we do have eic7700x boards though, i have one on my desk | 09:02:57 |
 dramforever | to be honest, i'm not sure why i said "this year". i know milkv megrez very much exists now | 09:18:12 |
| dramforever | * to be honest, i'm not sure why i said "this year". i knew milkv megrez very much exists now | 09:18:17 |
| dramforever | maybe i was thinking about the software situation | 09:18:27 |
| fgaz | or eic7702 | 09:59:40 |
| fgaz | that one is still not out, is it? | 10:00:07 |
 zimward | In reply to @dramforever:matrix.org
re: riscv i think we should probably wait for more reliable hardware what do you mean with more reliable hardware? (i would assume that most current SBCs will run fine without crashing) the builders don't need good single core performance as long as we can get enough cores with the memory to support them in a small enough form factor to cram them in a 1 or 2U chassis. | 10:04:33 |
| zimward | also: has anyone used the advertised TPUs of those chips? basically any new one advertises them (supposedly to make investors happy ig) but i never saw any real use of them | 10:05:47 |
| dramforever | most would do, SG2042 is ... weird | 10:07:13 |
| dramforever | but it is the most powerful one we have now | 10:07:59 |
| dramforever | so my main point is that i think we should skip sg2042 | 10:08:14 |
| dramforever | eic7700x should be pretty good apart from only having 4 cores | 10:08:34 |
| zimward | its the first real server grade riscv chip we have so far (atleast spec-wise), if you can share any experiences whats wrong with it i would appreciate it as i never got the opportunity to play with one. that being said im not opposed to throwing 20 4-core SoMs in a cluster | 10:10:33 |
| dramforever | i don't know how much i can share but it is a really scuffed chip | 10:15:08 |
| dramforever | ghostwrite is just the most well known of all problems | 10:18:41 |
| dramforever | and i'll just say turning the non-compliant vector extension off is almost a trivial workaround | 10:19:50 |
| zimward | its a bug in silicon. there is just no other workaround lol | 10:20:43 |
 Alex | Yikes. Did they not do enough test simulations while designing the core? | 10:21:50 |
| zimward | no differential fuzzing atleast | 10:22:06 |
| dramforever | what do you simulate? | 10:22:11 |
| dramforever | but also there's two teams involved, the now-called xuantie that made the c920v1 cores, and the sophgo team the made the whole processor by slapping together 16 of 4 core clusters | 10:24:09 |
| dramforever | this ... did not go particularly well | 10:25:38 |
| dramforever | oh, i remembered something i can share: LLVM-compiled multi threaded programs may run very slowly because fence(acq_rel) is compiled to fence.tso | 10:26:41 |
| dramforever | which the cores raise an illegal instruction exception due to a misunderstanding in the specs | 10:27:02 |
| Alex | So the system has to context switch on most fences?
Pure pain. | 10:27:55 |
 Steven Keuchel | I have both the pioneer (sg2042) and the megrez (eic7700x). the c920 cores in the sg2042 are kinda slow. too slow to use as a desktop. and a lot of processes swamp the memory subsystem. the p550 are already much faster. I would estimate that 4x eic7700x might outperform the sg2042, and would probably also be cheaper. | 10:28:36 |
| dramforever | not most fences, just this specific one | 10:28:38 |
| dramforever | just randomly fences taking hundreds of cycles | 10:28:53 |
| dramforever | but it is every time it executes | 10:29:04 |
| Alex | Ah, I'm not very familiar with LLVM's multithreading primitives... | 10:29:12 |
