Home freenode/#haskell: Logs Calendar

Logs: freenode/#haskell

←Prev  Next→
Page 1 .. 521 522 523 524 525 526 527 528 529 530 531 .. 5022
— 502,152 events total
2020-10-09 00:00:31 → polyrain joins (~polyrain@2001:8003:e501:6901:d439:cec4:3811:73e4)
2020-10-09 00:00:42 <dolio> Well, he'd be wrong about that.
2020-10-09 00:01:13 <nshepperd1> huh, I'd expect sequential consistency in the absence of documentation saying there isn't sequential consistency
2020-10-09 00:01:24 <dolio> It says there may not be.
2020-10-09 00:01:29 <dminuoso> Your point about IORef is interesting, does GHC actually reorder them?
2020-10-09 00:01:30 <dolio> That's how I know about it.
2020-10-09 00:01:36 <dolio> No, the CPU does.
2020-10-09 00:01:39 <dminuoso> Oh
2020-10-09 00:02:05 × conal quits (~conal@66.115.157.46) (Client Quit)
2020-10-09 00:02:08 <dminuoso> You mean `writeIORef f 1 >> writeIORef f 2` could leave me with `1`?
2020-10-09 00:02:21 <dolio> No, it's more complicated than that.
2020-10-09 00:02:35 × frdg quits (47b88ff9@pool-71-184-143-249.bstnma.fios.verizon.net) (Remote host closed the connection)
2020-10-09 00:02:50 <maralorn> It's worse on ARM, right?
2020-10-09 00:02:52 <dolio> That one would be pretty bad.
2020-10-09 00:02:55 <monochrom> No. But funny things happen when one thread goes "write to x; read from y; write to y" and another thread is also playing with x and y.
2020-10-09 00:03:06 <nshepperd1> https://hackage.haskell.org/package/base-4.14.0.0/docs/Data-IORef.html#g:2 ah
2020-10-09 00:03:10 <dminuoso> Oh if its just that..
2020-10-09 00:03:21 <dminuoso> I see
2020-10-09 00:03:36 <dminuoso> That seems expected
2020-10-09 00:03:53 <monochrom> CPU can look at 1st thread and say "looks like x and y are independent, I can change it to "read from y; write to y; write to x""
2020-10-09 00:03:58 × emmanuel_erc quits (~user@2604:2000:1382:ce03:6c74:afa7:7b91:b469) (Remote host closed the connection)
2020-10-09 00:04:02 <dolio> Anyhow, IO is an algebra, and the machine is the model, and does what it wants.
2020-10-09 00:04:04 <nshepperd1> well i guess that's fine since you'll probably use tvar for concurrent stuff anyway
2020-10-09 00:04:08 <dminuoso> monochrom: Yeah, but that's just memory
2020-10-09 00:04:09 → emmanuel_erc joins (~user@2604:2000:1382:ce03:ddc4:166d:60ea:ae29)
2020-10-09 00:04:11 <dminuoso> Nothing fancy here
2020-10-09 00:04:13 <monochrom> If the 2nd thread has assumptions about 1st thread's order, it's toasted.
2020-10-09 00:04:15 → conal joins (~conal@66.115.157.46)
2020-10-09 00:04:32 <monochrom> I think the IORef doc has a better example than mine.
2020-10-09 00:04:34 <nshepperd1> or use atomicModifyIORef if you're a masochist
2020-10-09 00:04:44 <monochrom> And then starts rambling about memory barriers
2020-10-09 00:05:09 <monochrom> Oh, two IORefs have to be involved, so atomicModifyIORef is beside the point.
2020-10-09 00:06:28 <nshepperd1> except for the memory barrier rambling
2020-10-09 00:06:31 <dminuoso> Haha, reminds me of C and how endless programmers use volatile thinking it helps with memory orderings.
2020-10-09 00:06:35 → ericsagnes joins (~ericsagne@2405:6580:0:5100:841d:b2f8:a54e:9827)
2020-10-09 00:06:57 <dolio> Someone was saying that in here the other day.
2020-10-09 00:06:57 <monochrom> https://downloads.haskell.org/~ghc/8.10.2/docs/html/libraries/base-4.14.1.0/Data-IORef.html#g:2
2020-10-09 00:07:25 <dolio> I decided to go read the C specification, and it didn't say anything about how much a pointer dereference or assignment costs.
2020-10-09 00:07:49 <nshepperd1> The c specification barely says anything
2020-10-09 00:07:57 <monochrom> Well, "rambling" is my view, I have this very purist opinion that if you need memory barriers you're abusing mutable shared variables.
2020-10-09 00:08:06 <dolio> It's pretty long for not saying anything.
2020-10-09 00:08:29 <dminuoso> nshepperd1: It says quite a lot, just not the things you hope it says.
2020-10-09 00:08:32 <c_wraith> It says lots of things that turn out to not be useful
2020-10-09 00:08:49 <nshepperd1> perhaps the c specification should run for political office
2020-10-09 00:08:52 <monochrom> I think setting out a grammar is useful.
2020-10-09 00:09:14 × remexre quits (~nathan@207-153-38-50.fttp.usinternet.com) (Quit: WeeChat 2.9)
2020-10-09 00:10:19 <dolio> Even the grammar parts are pretty amazing. Like, there could be a 'type too big' error.
2020-10-09 00:10:20 <monochrom> The Haskell Report isn't all that better either.
2020-10-09 00:10:21 × siloxid quits (~user@unaffiliated/siloxid) (Remote host closed the connection)
2020-10-09 00:10:48 <dolio> No, I wanted to make sure the C one wasn't significantly better than the Haskell one, like was claimed.
2020-10-09 00:11:23 <dolio> Like Haskell, most of what it talks about is 'what' and not 'how'.
2020-10-09 00:12:47 × emmanuel_erc quits (~user@2604:2000:1382:ce03:ddc4:166d:60ea:ae29) (Ping timeout: 240 seconds)
2020-10-09 00:13:15 <koz_> dolio: In many cases for the C Standard, that 'what' is followed by 'the fuck'.
2020-10-09 00:13:19 <dolio> I had to read the '17 one, though, because the '18 one was like $100. Maybe it's much improved.
2020-10-09 00:13:26 → emmanuel_erc joins (~user@2604:2000:1382:ce03:ddc4:166d:60ea:ae29)
2020-10-09 00:13:43 <koz_> (apologies if I broke any channel norms)
2020-10-09 00:14:02 <monochrom> hehe
2020-10-09 00:14:36 <dolio> I was surprised at how little was specified about the floating point numbers.
2020-10-09 00:15:42 <koz_> dolio: Yeah, contrary to popular belief, the C standard requires IEEE 754 precisely nowhere.
2020-10-09 00:15:49 <koz_> (C++ I believe does, or at least nowadays)
2020-10-09 00:16:00 <dolio> Maybe ISO doesn't want to pay royalties.
2020-10-09 00:16:04 <koz_> But then again, C doesn't even require integer representations to be 2s comp.
2020-10-09 00:16:10 <koz_> (again, C++ does, as of recently)
2020-10-09 00:16:48 <dolio> Yeah. I could see how to really play games with an implementation. You can use sign-and-magnitude with as many padding bits as you want, etc.
2020-10-09 00:16:57 → justsomeguy joins (~justsomeg@unaffiliated/--/x-3805311)
2020-10-09 00:17:33 <justsomeguy> If I want to define a default class method, do I put the term-level implementation of that method directly in the type class?
2020-10-09 00:17:40 <koz_> Also, again contrary to popular belief, char doesn't have to be 8 bits.
2020-10-09 00:17:50 <monochrom> That's too easy. Unless you use, like, a dynamically determined middle bit position for the sign bit.
2020-10-09 00:17:54 <koz_> (it has to be at least 7, and nothing else can be smaller than it, but otherwise, go nuts)
2020-10-09 00:18:11 <koz_> (there are legit computers for sale _today_ which have 9-bit chars)
2020-10-09 00:18:11 <dolio> Yeah.
2020-10-09 00:18:40 <koz_> justsomeguy: Yeah, it goes under the type signature in the class definition, as if you were just writing a normal function.
2020-10-09 00:19:37 <koz_> Ultimate implementation trolling - x86_64, every type is 64 bits wide.
2020-10-09 00:19:44 <justsomeguy> koz_: Hmm, ok. I'll try that out.
2020-10-09 00:19:46 <koz_> (well, not _that_ ultimate)
2020-10-09 00:19:50 <koz_> (but it'd be funny)
2020-10-09 00:19:55 <dolio> 64bits is too fast.
2020-10-09 00:20:19 <monochrom> GHC comes close to that. Every type is a multiple of 64 bits wide.
2020-10-09 00:20:25 <koz_> Something something Atari Jaguar.
2020-10-09 00:20:37 <monochrom> Err I guess not really "every".
2020-10-09 00:20:42 → Wolfy87 joins (~Wolfy87@s91904426.blix.com)
2020-10-09 00:21:22 <monochrom> But for example Word8 is 64 bits for the data constructor, 64 bits for the number.
2020-10-09 00:22:17 <koz_> WordNotReally8.
2020-10-09 00:22:30 <maralorn> I love how this conversation has drifted from CT to processor behavior.
2020-10-09 00:22:33 <{abby}> Word8, the "12" is silent
2020-10-09 00:23:03 <koz_> Maybe it's actually short for 'WordMultipleOf8'?
2020-10-09 00:23:23 <koz_> maralorn: This is how we roll.
2020-10-09 00:23:46 <monochrom> Nah, the real explanation is really boring. Alignment-friendly.
2020-10-09 00:24:01 × emmanuel_erc quits (~user@2604:2000:1382:ce03:ddc4:166d:60ea:ae29) (Ping timeout: 272 seconds)
2020-10-09 00:24:08 <koz_> monochrom: Yeah, but I can dream!
2020-10-09 00:24:51 <monochrom> Right? In popular C implementations, if you malloc(1) you expect alignment to ruin it and you're wasiting at least 7 bytes, too.
2020-10-09 00:25:31 <koz_> Not if you have 64-bit char!
2020-10-09 00:26:04 <monochrom> That's going to be interesting.
2020-10-09 00:26:10 <koz_> UTF-64 lolol.
2020-10-09 00:26:27 <monochrom> For, one thing the C standard does require very clearly, is "sizeof(char) = 1".
2020-10-09 00:26:42 <koz_> Yes, but 1 can be whatever bit count you want.
2020-10-09 00:26:49 <koz_> As long as it's at least 7.
2020-10-09 00:27:35 <koz_> You are within your rights as an implementer to decide that sizeof(char) == sizeof(short int) == sizeof(int) == sizeof(long int) == sizeof(long long int)
2020-10-09 00:27:47 <monochrom> Yeah, so it's interesting in blowing up the proportion of most people's expectations.
2020-10-09 00:28:55 <koz_> I also believe, though I am unsure, that sizeof(float) == sizeof(double) is legal.
←Prev  Next→
Page 1 .. 521 522 523 524 525 526 527 528 529 530 531 .. 5022

All times are in UTC.