Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zig's new bitCast semantics and LLVM back end improvements

ziglang.org

Post reply on HN
Print view View original

61–70 of 159 posts

Re: Zig's new bitCast semantics and LLVM back end improvements

#61

Post by nvme0n1p1 »

ozgrakkurt wrote: post #54
nvme0n1p1 wrote: post #51

Earlier quoted context omitted.

Take the address and deref afterwards, and it's exactly the same. Or to say another way: if you want bits to be reinterpreted raw as if they're in memory, then... put them in memory, then reinterpret them. > You could use it to define a function that implements bitCast. Which defeats the purpose of having any @bitCast intrinsic Yes, and this is one reason @bitCast was changed to have different semantics that are not…

> Take the address and deref afterwards, and it's exactly the same. It is significantly worse to take address and deref afterwards. You have to do something like: @as( const u32, @ptrCast(&x)). instead of just @bitCast(x) > Yes, and this is one reason @bitCast was changed to have different semantics that are not trivially achieved with @ptrCast. This makes sense except breaking existing code that properly handled end…

> This makes sense except breaking existing code

Before Zig hits 1.0, users should expect language changes. Has anyone claimed otherwise?

If you need the old thing often enough, you can write a wrapper for it. It's a trivial one-liner, as you've shown.

Re: Zig's new bitCast semantics and LLVM back end improvements

#62

Post by grayhatter »

f13f1f1f1 wrote: post #59
epolanski wrote: post #19

OT: I'm always surprised at how popular Zig discussions get here, or Youtube and other medias. Don't get me wrong, I love Zig and I think it's a great C replacement, but I'm very confused on why C3 or Odin rarely get any attention at all, despite being in the same C-replacement crowd. But still surprised at what Zig does better than these other projects? Is Andrew much better at marketing/promoting the language? He's…

Andrew pushes lots of "social issues" so he has that crowd and they push zig as a way of pushing their social views.

How confident are you? I ask because I'm a zig zealot, and am constantly shilling for it. But I disagree with a number of ark's positions, and think of him as a bit of a shitter... So I don't think "cult of personality" accounts for it, despite how easy it would be for someone to be able disregard zig if was just a personality cult.

Re: Zig's new bitCast semantics and LLVM back end improvements

#63

Post by tomjakubowski »

QuaternionsBhop wrote: post #33

Is pasting em-dashes everywhere some kind of inside joke?

Macintoshes have had mnemonic keyboard shortcuts for inserting en- and em-dashes since forever: option-hyphen and option-shift-hyphen. They've been in my digital repertoire since I first switched to a Mac around 2004.

Re: Zig's new bitCast semantics and LLVM back end improvements

#64

Post by tremon »

peesem wrote: post #42
tremon wrote: post #26

Earlier quoted context omitted.

But doesn't that show why this is a bad idea? If I understand correctly, this code: const MyUnion = packed union { full: u16, bytes: [2]u8, }; const value: u16 = 0x55aa; const in_union: MyUnion = @bitCast(value); const without_union: [2]u8 = @bitCast(value); std.debug.assert(without_union[0] == in_union.bytes[0]); std.debug.assert(without_union[1] == in_union.bytes[1]); ...will now succeed or fail depending on the en…

zig does not allow arrays in packed structs/unions specifically for endianness reasons (there may be other reasons as well but endianness is what i know of)

Ah, that is useful to know. Is that documented somewhere? From what I can quickly find in the obvious place [0], the only requirement is that "all fields in a packed union must have the same @bitSizeOf" and [2]u8 does satisfy that requirement.

[0] https://ziglang.org/documentation/0.16.0/#packed-union

Re: Zig's new bitCast semantics and LLVM back end improvements

#65

Post by f13f1f1f1 »

grayhatter wrote: post #62
f13f1f1f1 wrote: post #59

Earlier quoted context omitted.

Andrew pushes lots of "social issues" so he has that crowd and they push zig as a way of pushing their social views.

How confident are you? I ask because I'm a zig zealot, and am constantly shilling for it. But I disagree with a number of ark's positions, and think of him as a bit of a shitter... So I don't think "cult of personality" accounts for it, despite how easy it would be for someone to be able disregard zig if was just a personality cult.

I have no issues w/ the zig language and I'm not saying that's the only reason why people talk about it. There is however a subset of very vocal people who will go out of there way to bring stuff up and push something if they do see that is a part of it. Not that it's the only reason why either, just additional motivation for people to go out and push it that otherwise you might not get. All you need is a couple people who view that as a kind of campaign and they can radically increase the visibility of something on the internet, and turning programming that has some broader social or moral thing related to it even just through the creator is a very easy way of doing that. Rust has a similar thing. I don't view the instinct that leads to language zealotry or zealotry related to social issues(or say religion) being that distinct and it's probably a similar personality trait that encourages both, and it's generally one I find unpleasant regardless of the particular content. FP can also lean in that direction. If you get some narrative you can say this language fixes stuff in a fundamental way + also can appeal to the social thing it just riles people up who will go around talking about it online non stop.

Re: Zig's new bitCast semantics and LLVM back end improvements

#66

Post by jmalicki »

mathisfun123 wrote: post #58
jmalicki wrote: post #57

Earlier quoted context omitted.

While the GP might be technically wrong in a narrow sense, GPUs are built for FP, and that's what you want to be doing if you're using them as accelerators.

You don't know what you're talking about: an enormous amount of TOPs now runs through quantized (read: integer) kernels. Many GPUs don't have even FP64 or even FP32 support.

EDIT: I was completely wrong, I have mostly worked with GGUF and related quantizations that are LUTs, thank you for correcting me.

Re: Zig's new bitCast semantics and LLVM back end improvements

#67

Post by piker »

zamadatix wrote: post #16

This change + the existing packed struct logic will be great for working with bit packed binary headers w/o having to manually twiddle so much about the bit handling along the way.

It's so interesting to read comments like this and contrast them with the "don't read the code" type of vibes out right now. It feels like half of the developer world is optimizing low-level struct packing and the other half is YOLO'ing 300 KLOC Electron apps. Very confusing.

Re: Zig's new bitCast semantics and LLVM back end improvements

#68

Post by mathisfun123 »

jmalicki wrote: post #66
mathisfun123 wrote: post #58

Earlier quoted context omitted.

You don't know what you're talking about: an enormous amount of TOPs now runs through quantized (read: integer) kernels. Many GPUs don't have even FP64 or even FP32 support.

EDIT: I was completely wrong, I have mostly worked with GGUF and related quantizations that are LUTs, thank you for correcting me.

> The quantized integer kernels aren't running true integer multiplication, the quantization is it's own thing, they're basically enums not integers

ELI-a-GPU-compiler-engineer-working-at-a-major-vendor (because I am). Ie I can pull up the design docs for our ALUs and literally see that you're wrong.

Re: Zig's new bitCast semantics and LLVM back end improvements

#69

Post by samatman »

ozgrakkurt wrote: post #9

> Consider, for instance, bitcasting a [2]u8 to a u16. Under the old semantics, the result of this operation depends on the target endian: on big-endian targets, the first array element became the 8 most significant bits, whereas on little-endian targets, the first array element became the 8 least significant bits. Under the new semantics, because we only care about logical bit representation (which is endian-agnosti…

I understand the reaction, but I don't agree. I suggest reading the associated proposal[0] along with the devlog, and having a real think about what's going on here. I'm responding to you saying that you "don't understand" the approach: reasonable, and resembles my initial reaction.

I was inclined to agree with you, but what decided it for me is that Zig has another mechanism for "reinterpret bytes". It's exposed on the stdlib as std.mem.asBytes, but this is literally a wrapper for the following:

    @ptrCast(@alignCast(ptr));
So nothing is lost here: if you need, for whatever reason (and those do exist), to get a raw array of underlying bytes, you absolutely may. Std.mem also has bytesToValue(T, bytes) T, which makes a copy. All the ingredients are there, and this family of mem functions are thin wrappers over builtins, which boil down to pointer casting, dereferencing, and comptime magic.

Also worth noting: packed structs in Zig are already defined as logically little-endian: the first field is of low significance, the second is above that, and so on. So this makes `@bitCast` consistent with an existing convention of treating integers as logically little-ended, without regard to how they're actually arrayed in memory.

Plus it stands to make low-level bit-twiddling, using oddly-sized integers, optimize better. I like that, especially when what we trade for that is: nothing. Nothing at all, this is a pure win.

I'd even guess it's that rare language update which silently fixes buggy code, where someone figured "well, basically everything is little-endian already" (or just didn't think about it), and now that code works properly on big-endian machines.

[0]: https://github.com/ziglang/zig/issues/19755

Re: Zig's new bitCast semantics and LLVM back end improvements

#70

Post by grayhatter »

mlugg wrote: post #18
grayhatter wrote: post #2

> Quite long devlog coming up, apologies—I got a little carried away with this one! mlugg, please don't apologize for creating something I actually want to read. I'm drowning in low effort garbage, the in depth technical explanation is a refreshing breath of fresh air. Might as well apologize for creating a language without a garbage collector, sure most people are unwilling to think, but some of us like nice things…

I appreciate the kind words :)

BAH! and I forgot to say the most important part.

Much more important, thanks for not just the devlog, and explaining the changes. But also; thanks for fixing/improving this!

I appreciate all the work you've put in, I really enjoy watching the the language I like constantly improve.

Post reply on HN