code.illumos.org appears very slow for me...

cd

whoops.

:)

yeah

got a bad gateway first time.. now still trying to load

Ok, so it is not my computer then:D

Some folks here might find this useful. It's a re-creation of `=j` from `mdb`, but as a standalone program: github.com/dancrossnyc/jfmt

thats nice, so tired of manually counting bits:)

Great! I hope you find it useful. :-)

um, I'm using ficl-sys as calculator, should probably add this word there:P

heh.. more than once (especially on this work project) I've been firing up mdb just for =j :)

so thanks for that

yep, seems code.illumos.org is dead for good. only getting 502 now.

seems to be back now

code.illumos.org seems to be busted again - more 502 Bad Gateway

or maybe just slow?

never mind, seemed to have been a browser tab that was still befuddled from the earlier outage.

pushing a rebase to gerrit seems to be going very slowly (at the "remote: Counting objects:" stage)

and then I got a "Bad Gateway"

so it's not dead but not healthy either.

it's undead... just in time for halloween :)

Or, alternatively: "It just so happens that your service here is only MOSTLY dead."

so no looking for loose change...

I know this isn't the right place, I do general IT dev/ops, but I became curious how the Grace Hopper programming differs since they are all separate system image nodes, but share "direct" access to memory across the nvlink domain

I wondered if someone in here knew much about it, since I like you'se folks

I would suppose you have a set of processes across different nodes but could share memory pointers on a low level? I'm sorta fishing to be pointed somewhere, because I obviously just know keywords :-P

So, the GH chips have LPDDR5 connected to the Grace CPU and HBM3 connected to the GPU.

So there is hardware coherence within a single "Super Chip" via the C2C NVLink, but I don't believe there's anything coherent about external memory per se.

But I'm not entirely sure which bits you're takling about sharing or accessing per se.

This: developer.nvidia.com/blog/nvidia-gr…cture-in-depth/#extended_gpu_memory

I suspect that the programming doesn't differ in that from anything that you can already do via nvlink with access to remote memory.

But I haven't dug into this deeply myself.

Each grace hopper combo is its own system image instance, so it just got me thinking about the abstractions that would have to take place for jobs running across multiple nodes that are sharing memory

to theoretically approach using all the gpu cores and memory for a single related job