camel-cdr

15 วันที่ผ่านมา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

17 วันที่ผ่านมาdiscuss

Isn't HTML and CSS already a huge surface to support, unless you are happy with a subset?

camel-cdr

17 วันที่ผ่านมา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

17 วันที่ผ่านมา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

25 วันที่ผ่านมา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

28 วันที่ผ่านมา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

2 เดือนที่ผ่านมา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

2 เดือนที่ผ่านมาdiscuss

Porting this optimization to RISC-V Vector is pretty trivial.

camel-cdr

2 เดือนที่ผ่านมา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

2 เดือนที่ผ่านมา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

2 เดือนที่ผ่านมา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

2 เดือนที่ผ่านมา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

2 เดือนที่ผ่านมา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

2 เดือนที่ผ่านมา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

2 เดือนที่ผ่านมา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

2 เดือนที่ผ่านมา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.

camel-cdr

2 เดือนที่ผ่านมาdiscuss

Ah, so you're just doing SoA or AoSoA layout? It sounded like you where doing something more special than the standard SIMD usecase.

This does easily work with SIMD abstractions and even length-agnostic vector ISAs, unless you're doing AoSoA and your storage format has to match your memory format and it has the be the same on all machines. In which case you probably want to do something like 4K blocks anyways, in which case you can make it agnostic for all vector length anybody reasonably cares about for this type of application anyways.

camel-cdr

2 เดือนที่ผ่านมาdiscuss

So you "just" write 4 assembly implementations?

camel-cdr

2 เดือนที่ผ่านมาdiscuss

CNT and CNTP don't seem to be optional for SVE, from what I found. (unless you mean HISTCNT)

It seems to me like you want tp use CNTP on a bitset that tells you, which rows are relevant, skipping them if CNT is 0? Is that what you where describing?

camel-cdr

2 เดือนที่ผ่านมาdiscuss

OK, I thought it couldn't be that, because that should be doable with std::simd or a SIMD abstraction. Well, unless you JIT it, in which case intrinsics wouldn't help either.

> You can match search patterns across a random dozen columns across a schema of hundreds of columns at essentially full memory bandwidth

Do I underatand it correctly, that this would only work, if you have multiple of the same comparisons (e.g. equality check with same sized data) in the WHERE clause and the relevant collumns are within one multiple of the SIMD width of each other?

Submissions

Felix86 26.06: Some Gaming

Preliminary in-progress RISC-V "P" Extension

RISC-V Integrated Matrix Extension Release for Internal Review

Felix86 26.03: AVX, AVX2, BMI1 and F16C Support

Visualizing the RISC-V Instruction Set

RISC-V Oral History Panel [video]

“One Student One Chip” Course Homepage

OpenXiangShan Tutorials at MICRO'25

XiangShan Vector Floating-Point Unit Design

comments