jamesaross

I have a Radeon 7900 XTX 24GB and have been using the deepseek-r1:14b for a couple days. It achieves about 45 tokens/s. Only after reading this article did I realize that the 32B model would also fit entirely (23GB used). And since Ollama [0] was already installed, it as as easy as running: ollama run deepseek-r1:32b

The 32B model achieves about 25 tokens/s, which is faster than I can read. However, the "thinking" time is mostly a lower quality overhead taking ~1-4 minutes before the Solution/Answer

You can view the model performance within ollama using the command: /set verbose

[0] https://github.com/ollama/ollama

An ARM supercomputer was already #1 in 2020 [0]. The Japanese Fugaku is also notable because it doesn't use GPUs to achieve high performance, but rather wide vector units on the CPU.

[0] https://top500.org/system/179807/

I love these puzzles. GNU C supports a label as value for computed goto. This is useful for direct threaded dispatch. You trade off a branch instruction for an address lookup, but it makes the code more structured.

  int main(void) {
    void* A[] = {&&A0, &&A1, &&A2, &&A3};
    void* B[] = {&&B0, &&B1, &&B2, &&B3};
    void* C[] = {&&C0, &&C1, &&C2, &&C3};
    goto *A[SCAN];
    A0: WRITE(1); RIGHT; goto *B[SCAN];
    A1: WRITE(3); LEFT ; goto *B[SCAN];
    A2: WRITE(1); RIGHT; HALT; return 0;
    A3: WRITE(2); RIGHT; goto *A[SCAN];
    B0: WRITE(2); LEFT ; goto *C[SCAN];
    B1: WRITE(3); RIGHT; goto *B[SCAN];
    B2: WRITE(1); LEFT ; goto *C[SCAN];
    B3: WRITE(2); RIGHT; goto *A[SCAN];
    C0: WRITE(3); RIGHT; goto *B[SCAN];
    C1: WRITE(1); LEFT ; goto *B[SCAN];
    C2: WRITE(3); LEFT ; goto *C[SCAN];
    C3: WRITE(2); RIGHT; goto *C[SCAN];
  }

I wrote a short paper for HPEC that included some power and performance benchmarks and analysis on the HiFive Unleashed U540 SoC [0]. The SoC isn't open source as some suggest although I believe the core is based on the open source Rocket Chip Generator [1]. It seems the greatest weakness was in the slow memory interface. The details of memory controller and configuration were proprietary when I tried to find out why it wasn't performing well.

[0] http://www.ieee-hpec.org/2018/2018program/index_htm_files/15...

[1] https://github.com/freechipsproject/rocket-chip

You don't have to worry too much about the low Earth orbit (LEO) sateillites as they will deorbit soon enough. My understanding is that there is also ongoing research into methods to deorbit them at end of life.

There are several efforts including VexCL [0] expression templates, OpenACC [1] preprocessor, Kokkos [2] template metaprogramming, SYCL [3], and many other similar projects. Parallel programming for non-trivial parallelism is still...non-trivial.

[0] https://github.com/ddemidov/vexcl

[1] https://www.openacc.org/

[2] https://github.com/kokkos/kokkos

[3] https://www.khronos.org/sycl

Don't the inevitable methane leaks from natural gas create more of a GHG effect than the CO2 emitted from burning it? It's not just the environment disasters like in California, but everyday minor leaks.

John Gustafson is on the board of Rex Computing, a small semi startup. They claim to have taped out last year, but I don't know if the chip has been validated or if it had posits in silicon, but I know that is one of their longer term goals.

I find Gustafson's UNUMS 2.0 more compelling than the first version.

I may be somewhat qualified to speculate...Based on my experience with both Intel's and AMD's OpenCL implementations for their CPUs, I suggest that Intel has a much better vecorizing compiler than AMD. The benchmarks they are running have different compilers. If it was a simple C code compiled by GCC for each CPU, the comparison would be better. It would be interesting to see the results for AMD's OpenCL compiler on the i7 and Intel's compiler on Ryzen.

"In addition to ditching the requirement for regular password changes, the NIST is also advising sites to allow users to create passwords that are at least 64 characters long and include spaces so people can create pass phrases that may be easier to remember and to ditch special character requirements."

Relevant XKCD: https://www.xkcd.com/936/

It applies to architectures with caches https://en.wikipedia.org/wiki/Cache_coherence

Epiphany-V does not have caching. You explicitly move data around in software. Some software abstractions are better than others.

I think a heterogeneous product was implied in that post, but I don't blame you for the confusion. The Epiphany-V is still homogeneous because of the time/funding constraints.

OpenSHMEM paper: https://arxiv.org/abs/1608.03545

It's backward compatible with Epiphany-III...so it's still Epiphany ISA with new instructions.

Consider that many instruction and data caches are at the 16-32 KB scale. It's obviously a big criticism of the microarchitecture but you have a linear tradeoff between number of cores and available core memory. One core with 64 MB of memory seems less useful than 1024 cores with 64 KB of memory each (which can directly access all other core memory). But 65,536 cores with 1KB of memory each doesn't sound very useful either.