HackerTrans
TopNewTrendsCommentsPastAskShowJobs

camel-cdr

2,098 karmajoined hace 5 años

Submissions

Felix86 26.06: Some Gaming

felix86.com
3 points·by camel-cdr·el mes pasado·0 comments

Preliminary in-progress RISC-V "P" Extension

github.com
2 points·by camel-cdr·hace 3 meses·0 comments

RISC-V Integrated Matrix Extension Release for Internal Review

github.com
5 points·by camel-cdr·hace 4 meses·0 comments

Felix86 26.03: AVX, AVX2, BMI1 and F16C Support

felix86.com
3 points·by camel-cdr·hace 4 meses·0 comments

Visualizing the RISC-V Instruction Set

gist.github.com
3 points·by camel-cdr·hace 5 meses·0 comments

RISC-V Oral History Panel [video]

youtube.com
5 points·by camel-cdr·hace 7 meses·0 comments

“One Student One Chip” Course Homepage

ysyx.oscc.cc
185 points·by camel-cdr·hace 8 meses·50 comments

OpenXiangShan Tutorials at MICRO'25

tutorial.xiangshan.cc
1 points·by camel-cdr·hace 9 meses·0 comments

XiangShan Vector Floating-Point Unit Design

docs.xiangshan.cc
70 points·by camel-cdr·hace 9 meses·6 comments

comments

camel-cdr
·hace 39 minutos·discuss
You can benchmark stuff with and without RVC. Once there is faster hardware I want to do such a comparison with a full gentoo build for both sides.

However, quantifying what the result will actually mean is nearly impossible, because you don't know what the hardware cost was.
camel-cdr
·hace 53 minutos·discuss
> E.g. you fetch 66 bytes instead of 64

Not really, you would fetch fewer bytes with RVC [2, page 9], because the code density is better.

> I would be really surprised if the lower code density is worse than the improvement due to everything being nicely aligned.

This is very hard to quantify.

> Especially because Qualcomm had actual data that it isn't (if you add new instructions with the extra coding space you free up).

I've liked the back and forth slides bellow. Though I want to bring up to things regrading the Qualcomm slides:

    > [RVC] Performance benefit is modest
    > • Best case: 2-3% speedup
I recently benchmark compiling programs with a rva23 clang build and clang compiled for rva23-without-C and got a 10% performance improvement from RVC on the SpacemiT X100.

I also have no idea how they got those numbers. (not that they are wildly implausible, it's just not transparent)

    > Improving Android Code Size
In the last presentation they show how you can add a +-64M 32-bit long jump instruction to improve codesize in large binaries, like those in android.

I want to point out, that the JAL opcode has enough space left (7/8th) to encode a long jump of a same range and there is a proposal for a 32-bit +32M -12M 32-bit long jump: https://github.com/riscv/riscv-isa-manual/blob/zijfal/src/un...

[1] https://lists.riscv.org/g/tech-profiles/attachment/321/0/A%2...

[2] https://lists.riscv.org/g/tech-profiles/attachment/353/0/RIS...

[3] https://lists.riscv.org/g/tech-profiles/attachment/378/0/Res...

[4] https://lists.riscv.org/g/tech-profiles/attachment/400/0/AOS...
camel-cdr
·hace 2 horas·discuss
There are two options when designing an ISA to achieve competitive code size, add variable length instructions or add more complex fixed-length instructions which require cracking (2W instructions). The other option is: maybe codesize don't matter?

For high performance implementations both decoding variable length instructions and decoding/cracking fixed-length instructions into uops, are rather analogous in terms of the work hardware needs to do.

However, I think the advantage of fixed-length instructions, is that you can do further tricks, like pre-decoding in Icache. With RVC, you can also do pre-decoding, but now you need twice the amount of pre-decoding data, unless you find other tricks.

Still, in a reasonable variable-length ISA and fixed-length ISA, the variable-length one will get better code size. There are also a lot of other things to consider, RVC is self synchronizing, cracking is challenging for decode, but also keeps the backend better fed, how more instruction starts impact branch predictors, instructions crossing cache-lines...

I benchmark compiling programs with a rva23 clang build and clang compiled for rva23-without-C and got a 10% performance improvement from RVC on the SpacemiT X100. The X100 is a 4-wide out-of-order core and afaik doesn't do anything special for RVC, except for expanding the 16-bit to 32-bit instructions.

It's hard to quantify the real impact on a CPU design, but going the fixed-width route seems to enable more optimizations (not so much the decoding it self).
camel-cdr
·hace 5 horas·discuss
> Yes that's precisely the point of excluding it from the RVA profiles. It would mean that Linux distros don't compile code with C enabled, so chips are free to not support C and therefore can achieve higher performance (probably). And it opens 3/4 of the instruction encoding space for use by other things.

The debate was between 16/32/48/64-bit instructions vs naturally aligned 32-bit and 64-bit instructions + new more complex instructions that require cracking to regain code size (things like load/store pair).

> RISC-V defines a mechanism by which 48/64 bit instructions might be used, but currently none are actually defined

The long-instruction-SIG just started a few weeks ago, and they are working on defining 48/64-bit encodings for instructions that could be used in future RVA profiles (so with high perf implementations in mind). If you are knowledgeable about this stuff, please get involved, so they don't mess it up. (not "you" specifically, but in general)
camel-cdr
·hace 15 días·discuss


    \* Fibonacci hashing spreads packed ARGB keys uniformly.
       Used so that low bits don't dominate the cache.  */
    return (NSUInteger) ((key * 11400714819323198485ULL)
           & (NS_COLOR_CACHE_SIZE - 1));
This is not how hashing works...
camel-cdr
·hace 17 días·discuss
Isn't HTML and CSS already a huge surface to support, unless you are happy with a subset?
camel-cdr
·hace 17 días·discuss
> i wish there was just an SDK for building apps (i'll vibe code towards a great epub experience, i'm fine with that)

That seems to be what crosspoint-reader is: https://github.com/crosspoint-reader/crosspoint-reader
camel-cdr
·hace 17 días·discuss
I skimmed over the project a bit. It seems quite ambitious to aim to reimplement epub, considering that means supporting HTML, CSS, SVG and JavaScript.

Is there a ebook format that isn't just build arround the concept of a webbrowser?
camel-cdr
·hace 25 días·discuss
> unless you're irresponsible enough to connect an LLM to something that actually matters

Remember when people said Artifical Intelligence woun't be dangerous, because nobody will be stupid enough to give it free access to the internet...
camel-cdr
·hace 29 días·discuss
This is not the correct analogy, because we know that they explicitly used a huge ammount of pirated books and other works.
camel-cdr
·hace 2 meses·discuss
> Simplicity in the CPU hardware may reduce the probability of hardware bugs, but it increases the probability of software bugs, because the missing hardware features must be implemented at a much greater cost in software, like in the case with the missing integer overflow detection of RISC-V, which causes most RISC-V programs to omit overflow checks, increasing the chances of undetected bugs.

Since I've got a SpacemiT K3 board my self now, I though I test it again:

I compiled microjs with both tinycc and chibicc, which where both compiled for the target platform with and without -ftrapv:

    Slowdown Zen1: tinycc: 1.34%, chibicc: -0.3% (slight speedup somehow?)
    Slowdown X100: tinycc:  0.1%, chibicc:  3.4%
Last time I did full clang: https://news.ycombinator.com/item?id=47328214#47342362 And there was minimal slowdown (sometimes speedup) on x86, Arm and RISC-V. It was pointed out that llvm mostly uses size_t, however chibicc and tinycc use int as their default type, so there should be lots of overflow checking.
camel-cdr
·hace 2 meses·discuss
Porting this optimization to RISC-V Vector is pretty trivial.
camel-cdr
·hace 2 meses·discuss
There are a lot more ARM extensions than people are aware of. E.g. debian uses ARMv8-A with FEAT_FP and FEAT_AdvSIMDas a base. Yes, floating-point and SIMD are optional in ARMv8-A, as are the following ISA extensions, only including ones that add instructions and excluding the AArch32 stuff: FEAT_CRC32, FEAT_AES, FEAT_PMULL, FEAT_SHA1, FEAT_SHA256, FEAT_RDM, FEAT_F32MM, FEAT_F64MM, FEAT_I8MM, FEAT_LSMAOC, FEAT_SHA3, FEAT_SHA512, , FEAT_SM3, FEAT_SM4, FEAT_SVE, FEAT_EPAC, FEAT_FCMA, FEAT_JSCVT, FEAT_LRCPC, FEAT_DotProd, FEAT_FHM, FEAT_FlagM, FEAT_LRCPC2, FEAT_BTI, FEAT_FRINTTS, FEAT_FlagM2, FEAT_MTE, FEAT_MTE2, FEAT_RNG, FEAT_SB, FEAT_BF16, FEAT_DGH, FEAT_EBF16, FEAT_CSSC, ...

Also fun: FEAT_LittleEnd, FEAT_MixedEnd, FEAT_BigEnd

All of that was just 64-bit ARMv8.x-a, there is a lot more stuff, once you go to R or M profiles, 32-bit and previous versions.

The reason this is mostly not a problem, is that distros converged on a minimum of 64-bit ARMv8-A + FP + SIMD, which will also happen with RVA23 for RISC-V.

Just for fun, here are the Zen4 ISA flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl tsc_reliable nonstop_tsc cpuid extd_apicid tsc_known_freq pni pclmulqdq ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm cmp_legacy svm cr8_legacy abm sse4a misalignsse 3 dnowprefetch osvw topoext perfctr_core ssbd ibrs ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 erms invpcid avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves avx512_bf16 clzero xsaveerptr arat npt nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold v_vmsave_vmload avx512vbmi umip avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq rdpid fsrm

Compared to RVA23 written out: rv64imafdcbv_zicsr_zicntr_zihpm_ziccif_ziccrse_ziccamoa_zicclsm_zic64b_za64rs_zihintpause_zba_zbb_zbs_zicbom_zicbop_zicboz_zfhmin_zkt_zvfhmin_zvbb_zvkt_zihintntl_zicond_zimop_zcmop_zcb_zfa_zawrs_svbare_svade_ssccptr_sstvecd_sstvala_sscounterenw_svpbmt_svinval_svnapot_sstc_sscofpmf_ssnpm_ssu64xl_sha_supm_zifencei
camel-cdr
·hace 2 meses·discuss
> From a bystanderʼs POV it is excessively hard to memorize all the mess with multiple different extensions

It's the same for other ISAs.

> What Iʼm slightly confused for is that all these extensions, useful for a minor part of applications, arenʼt moved to longer instructions (6-byte).

Because these instructions don't need it. There will be future >4-byte instructions, for things thay can't resonably be done in 4-bytes, e.g. much larger immediates.
camel-cdr
·hace 2 meses·discuss
> Also, let's stop with the "vector length agnostic" types being the sole option for SVE extensions

They aren't, see the `arm_sve_vector_bits` attribute.

> I'm fine with recompiling my code, I do it every day

Then you can do that.

> If I have an algorithm that's truly vector length agnostic, I can make the vector length a constant in my code that can change based on the compile target.

You can do that, but why not simply write it in a vector-length-agnostic way?

IMO the better approach is to start thinking about SIMD optimizations in a VLA way, and specialize on the vector length, when that becomes advantageous. Doing it this way is better even if you end up not writing VLA code, because you though about the scalability problem.

Many libraries currently don't scale beyond 128-bit, not because they couldn't make efficient use of >128-bit, but because the library was architect around 128-bit and changing that amounts to almost a full rewrite. So now you are stuck wasting 3/4th of your ALUs running 128-bit SSE on Zen5.
camel-cdr
·hace 2 meses·discuss
greater then 512-bit SIMD isn't currently and in the near future relevant for regular general purpose processors.

But for smaller more specialized CPUs in embedded or automotive usecases you can get more parallel compute, while keeping the software model simpler than having to dispatch to a GPU.

Specifically a design like https://saturn-vectors.org/#_short_vector_execution, which like to use 2x or 4x wider vectors that the datapath length for more efficient chaining. I quite like that design, because you can get high utilization and limited out-of-order execution without vector register renaming.
camel-cdr
·hace 2 meses·discuss
In GPUs GLSL like types compile down to what basically is variable length SIMD. A vec4 doesn't get compiled to a SIMD vector with four floats, but rather to four SIMD vectors, each containing N FP32 elements (usually 32 or 64).

Look at what this simple shader compiles down to on RGA: https://godbolt.org/z/4GrfY61vf
camel-cdr
·hace 2 meses·discuss
Looks like that isn't a portable SIMD abstraction, but more similar to adding architecture-specific SIMD intrinsics support to go, with nicer syntax.
camel-cdr
·hace 2 meses·discuss
> This will take decades because you cannot change existing architectures/processors.

I think once, AVX-512, SVE and RVV are wide spread enough, you'll have a rather powerfull baselevel you can target. But this will take a lot of time.
camel-cdr
·hace 2 meses·discuss
Here is a highway example: https://gcc.godbolt.org/z/7sdPr61W6

There is a bit of boilerplate to get dynamic dispatch working, but apart from that it's quite simple to use.