@amonakov@mastodon.gamedev.place avatar

amonakov

@amonakov@mastodon.gamedev.place

This profile is from a federated server and may be incomplete. Browse more on the original instance.

pervognsen, to random
@pervognsen@mastodon.social avatar

There's a bunch of C-like successor languages that say they want to eliminate undefined behavior. I've never been able to figure out how they intend to deal with reads and writes to memory since a lot of these languages take what I would call the "naive" machine-centric view of memory which is hard to reconcile with source-level semantics for variables, etc. You can't really rename all of this stuff as "implementation-defined" and get out of jail for free.

amonakov,
@amonakov@mastodon.gamedev.place avatar

@pervognsen @harold <pic: Fry squinting at the first sentence>

(some behavior in C is undefined by virtue of the language standard not saying anything about it)

Yes, there is the truly weird category of UB which pertains to translation time, not execution time, and it seems completely unnecessary, but I assume that's not what was meant here.

amonakov, to random
@amonakov@mastodon.gamedev.place avatar

(prompted by discussion of detecting bitwise and-not earlier in GCC's optimization pipeline)

My ideal compiler IR would not have and/or/xor as distinct bitwise ops, just generic ternlog and probably the corresponding two-operand function ("bilog"?) too.

amonakov,
@amonakov@mastodon.gamedev.place avatar

Perhaps my ideal CPU would also have a ternlog opcode instead of an incomplete zoo of bitwise ops.

mul-add is another useful three-input instruction (although unlike ternlog it's macro-fusible from separate mul+add). If one made a CPU geared towards such three-input instructions, I wonder what other combined ops would be there (clmul+xor? shift+or?) and what the trade-offs are.

amonakov,
@amonakov@mastodon.gamedev.place avatar

@pervognsen I guess because on GPUs the need for efficient blend is that much higher than on CPUs?

NVIDIA has lop3.

I'm not sure AMD has an equivalent?

amonakov, to random
@amonakov@mastodon.gamedev.place avatar

PSA for people writing Arm SIMD code in C or C++: unlike x86, where you can cast any pointer to __m128* and be able to dereference it regardless of the dynamic type of the pointed-to memory, that is not the case on Arm: Neon types do not carry the may_alias attribute and standard type compatibility rules apply. Compare the differences between 'f' and 'g' on the first pic, and Arm codegen on the second pic.

image/png

pervognsen, to random
@pervognsen@mastodon.social avatar

Digging through old stuff, here's a fairly extreme example of branch predictor training effects in a benchmark of Robin Hood linear probing vs conventional linear probing. Look at the branch misses for 1 vs 1000 outer loop iterations for RH (and the impact on wall clock time): https://gist.github.com/pervognsen/e818251d52f725db7c67e562577a12f6

amonakov,
@amonakov@mastodon.gamedev.place avatar

@pervognsen Is that Rust's built-in perf_event interface in action for {branch,cache} miss counts?

amonakov, to random
@amonakov@mastodon.gamedev.place avatar

In 'less', you can interactively add command-line arguments without leaving the pager by pressing '-': you can press '-S' to flip wrapping/chopping of long lines, and '-j11' to spawn 10 wor^W^W^W see extra ten lines of context above the match when searching!

vegard, to random
@vegard@mastodon.social avatar

Are these all the special sections that run code on program init/exit? Did I miss any?

.section .preinit_array; .quad fun
.section .init, "ax"; callq fun
.section .init_array; .quad fun
.section .ctors, "aw"; .quad fun
.section .dtors, "aw"; .quad fun
.section .fini_array; .quad fun
.section .fini, "ax"; callq fun

amonakov,
@amonakov@mastodon.gamedev.place avatar

@vegard you absolutely did, because you're not asking the right question. The right question is, what makes code from those sections run at startup?

amonakov, to random
@amonakov@mastodon.gamedev.place avatar

shower thought re. rgb 565 vs. theoretical 555|1 (common least significant bit for each component): it introduces higher "distortion" for darker colors (i.e. the closest encodable to dark purple { 1, 0, 1 }/64 is dark grey { 1, 1, 1 }/64), but our vision loses color sensitivity in low-light conditions anyway, so that probably would have been a better fit

amonakov,
@amonakov@mastodon.gamedev.place avatar

Oh, it's not theoretical at all: at least Sharp X68000 and Neo Geo employed it. Thanks, Wikipedia!

  • All
  • Subscribed
  • Moderated
  • Favorites
  • megavids
  • GTA5RPClips
  • thenastyranch
  • ethstaker
  • everett
  • Durango
  • rosin
  • InstantRegret
  • DreamBathrooms
  • magazineikmin
  • Youngstown
  • mdbf
  • slotface
  • tacticalgear
  • JUstTest
  • kavyap
  • modclub
  • cisconetworking
  • cubers
  • ngwrru68w68
  • khanakhh
  • tester
  • anitta
  • normalnudes
  • Leos
  • osvaldo12
  • provamag3
  • lostlight
  • All magazines