Logs: liberachat/#haskell
| 2021-07-14 15:39:22 | → | Guest21 joins (~Guest21@187.83.249.216.dyn.smithville.net) |
| 2021-07-14 15:39:27 | <Clint> | where? |
| 2021-07-14 15:39:45 | → | ec joins (~ec@gateway/tor-sasl/ec) |
| 2021-07-14 15:40:02 | <hololeap> | https://hackage.haskell.org/package/rio-0.1.20.0/docs/RIO-Process.html |
| 2021-07-14 15:40:17 | <Rembane> | hololeap: Assume that someone will mess it up for you. |
| 2021-07-14 15:40:58 | <tomsmeding> | that's within one process, right? Normally environment variables don't change in one process unless you explicitly change it :) |
| 2021-07-14 15:41:01 | → | MQ-17J joins (~MQ-17J@d14-69-206-129.try.wideopenwest.com) |
| 2021-07-14 15:41:29 | <tomsmeding> | though I guess that "cache PATH lookups" refers to caching the location of particular binary names in the file system as looked up in the PATH, which is a different story altogether |
| 2021-07-14 15:42:28 | → | hnOsmium0001 joins (uid453710@id-453710.stonehaven.irccloud.com) |
| 2021-07-14 15:42:58 | × | merijn quits (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 252 seconds) |
| 2021-07-14 15:49:29 | × | lbseale quits (~lbseale@user/ep1ctetus) (Read error: Connection reset by peer) |
| 2021-07-14 15:50:39 | <Profpatsch> | It introduces a caching layer, which is always a bad idea |
| 2021-07-14 15:50:58 | <Profpatsch> | They probably implement their own lookup logic |
| 2021-07-14 15:51:41 | <Profpatsch> | Granted, environment variables *probably* don’t change in most programs |
| 2021-07-14 15:53:23 | <Profpatsch> | but now you have to have a state that you need to carry around and a lot of logic around something |
| 2021-07-14 15:53:31 | → | slowButPresent joins (~slowButPr@user/slowbutpresent) |
| 2021-07-14 15:55:19 | × | ec quits (~ec@gateway/tor-sasl/ec) (Remote host closed the connection) |
| 2021-07-14 15:55:44 | → | ec joins (~ec@gateway/tor-sasl/ec) |
| 2021-07-14 15:57:29 | <[exa]> | hololeap: PATH lists in some certain environments (I'd even say nix) are pretty fat, if you save say 100 calls of stat(2) for one execve(2) it usually starts paying off |
| 2021-07-14 15:57:53 | × | qbt quits (~edun@user/edun) (Quit: WeeChat 3.2) |
| 2021-07-14 15:58:09 | → | qbt joins (~edun@user/edun) |
| 2021-07-14 15:58:44 | <[exa]> | Profpatsch: feel free remove your L1&L2 cache and reiterate on the caches as bad ideas |
| 2021-07-14 15:59:08 | <ephemient> | (ba)sh caches PATH lookups, but has a (re)hash command to manipulate it because it can be wrong |
| 2021-07-14 15:59:58 | × | Guest21 quits (~Guest21@187.83.249.216.dyn.smithville.net) (Ping timeout: 246 seconds) |
| 2021-07-14 16:00:52 | → | lavaman joins (~lavaman@98.38.249.169) |
| 2021-07-14 16:01:29 | → | mcglk joins (~mcglk@131.191.49.120) |
| 2021-07-14 16:01:41 | <tomsmeding> | caching is sometimes good, sometimes _REALLY_ good, but certainly not always good |
| 2021-07-14 16:01:48 | <EvanR> | a caching layer is great when it's never wrong |
| 2021-07-14 16:02:18 | <tomsmeding> | and pays off in comparison to the required maintenance effort |
| 2021-07-14 16:02:39 | <tomsmeding> | it's an optimisation, and any optimisation is a tradeoff :) |
| 2021-07-14 16:03:06 | <EvanR> | L* cache, my maintenance effort is zero and it's never wrong xD |
| 2021-07-14 16:03:19 | <EvanR> | HTTP caching, maintenance effort high and is never right! |
| 2021-07-14 16:03:44 | → | alan41 joins (~alan@83-245-249-101-nat-p.elisa-mobile.fi) |
| 2021-07-14 16:03:48 | <tomsmeding> | and yet, if you'd turn off http caching in your browser, many websites would get a lot slower |
| 2021-07-14 16:04:06 | <davean> | Uh, if your HTTP cache is wrong, the upstream site fucked up |
| 2021-07-14 16:04:08 | tomsmeding | doubts "never right" |
| 2021-07-14 16:04:18 | <tomsmeding> | davean: which happens |
| 2021-07-14 16:04:26 | <davean> | HTTP has a plenty expressive caching semantics |
| 2021-07-14 16:04:28 | <tomsmeding> | but not enough to warrant "never right" :) |
| 2021-07-14 16:04:34 | × | alan41 quits (~alan@83-245-249-101-nat-p.elisa-mobile.fi) (Client Quit) |
| 2021-07-14 16:04:35 | → | xsperry joins (~as@user/xsperry) |
| 2021-07-14 16:04:36 | <EvanR> | when it's your (my) upstream site, that explains it |
| 2021-07-14 16:05:07 | <EvanR> | anyway web tech gives caching a bad name |
| 2021-07-14 16:05:07 | × | pharmaz0ne quits (~pharmaz0n@92.40.194.74.threembb.co.uk) (Read error: Connection reset by peer) |
| 2021-07-14 16:05:31 | <tomsmeding> | build tools also do, because of the rare instances when they're wrong |
| 2021-07-14 16:05:34 | × | lavaman quits (~lavaman@98.38.249.169) (Ping timeout: 268 seconds) |
| 2021-07-14 16:06:41 | <EvanR> | I am still perplexed that caching schemes are allowed to be wrong |
| 2021-07-14 16:06:43 | <tomsmeding> | some regular in this channel (I forget who) has complained multiple times about weird behaviour because cabal thought some build product could be cached when it should've been recompiled |
| 2021-07-14 16:07:04 | <EvanR> | even if rarely, that would be unacceptable for the memory system's cache |
| 2021-07-14 16:07:09 | <tomsmeding> | EvanR: is there a caching scheme that is _intentionally_ allowed to be wrong? |
| 2021-07-14 16:07:26 | <tomsmeding> | oh right, bash |
| 2021-07-14 16:07:32 | × | jumper149 quits (~jumper149@80.240.31.34) (Quit: WeeChat 3.1) |
| 2021-07-14 16:07:35 | <EvanR> | in the sense that the wrongness is observable |
| 2021-07-14 16:08:00 | → | cheater1__ joins (~Username@user/cheater) |
| 2021-07-14 16:08:12 | × | cheater quits (~Username@user/cheater) (Ping timeout: 272 seconds) |
| 2021-07-14 16:08:12 | cheater1__ | is now known as cheater |
| 2021-07-14 16:08:14 | <EvanR> | whether because you went outside the bounds of unwritten rules of engagement, or just there are no rules here and everyone is doing whatever |
| 2021-07-14 16:09:10 | <davean> | You can only have a correct cache in regards to semantics |
| 2021-07-14 16:09:12 | <EvanR> | lets put it this way, if you hear someone complaining about their build systems cache being wrong, no one ever calls that a bug |
| 2021-07-14 16:09:25 | <EvanR> | it's a problem with the user |
| 2021-07-14 16:09:34 | <tomsmeding> | does no one? |
| 2021-07-14 16:09:37 | <EvanR> | i called that 'allowed to be wrong' |
| 2021-07-14 16:09:49 | <tomsmeding> | I have the exact opposite experience :p |
| 2021-07-14 16:09:50 | <davean> | Uh, no people always call that a bug |
| 2021-07-14 16:10:12 | <EvanR> | ok, the take away here is I have nothing whatsoever to add |
| 2021-07-14 16:10:25 | <EvanR> | just take the opposite of what i say, and we're good i guess |
| 2021-07-14 16:10:29 | <davean> | I guess |
| 2021-07-14 16:10:31 | <tomsmeding> | the _real_ take away is "software engineering is hard" :p |
| 2021-07-14 16:10:48 | → | merijn joins (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-07-14 16:10:54 | → | pfurla joins (~pfurla@216.131.82.58) |
| 2021-07-14 16:11:05 | <EvanR> | you see no difference whatsoever between the track record of memory system cache and other caching systems? xD |
| 2021-07-14 16:11:24 | <tomsmeding> | it's just that if there is a bug in the memory system cache, everything blows up |
| 2021-07-14 16:11:28 | <EvanR> | it seems like one is allowed to be wrong |
| 2021-07-14 16:11:29 | <davean> | The memory system cache is wrong sometimes. |
| 2021-07-14 16:11:43 | <tomsmeding> | that doesn't mean that a bug in cabal's caching scheme wouldn't be a bug |
| 2021-07-14 16:11:57 | <EvanR> | an actual bug, yeah |
| 2021-07-14 16:12:17 | <EvanR> | if you just don't know how to use cabal... |
| 2021-07-14 16:12:37 | <davean> | compilers (mostly) know how to use the memory cache |
| 2021-07-14 16:12:41 | → | abhixec joins (~abhixec@c-67-169-139-16.hsd1.ca.comcast.net) |
| 2021-07-14 16:12:45 | <davean> | but this is actually a point of great debate |
| 2021-07-14 16:12:53 | <davean> | I'm surpised you're unfamiliar with it |
| 2021-07-14 16:13:03 | <davean> | memory ordering is a HUGE deal in compiler code generation |
| 2021-07-14 16:13:14 | × | ubert quits (~Thunderbi@2a02:8109:9880:303c:ca5b:76ff:fe29:f233) (Remote host closed the connection) |
| 2021-07-14 16:13:19 | <EvanR> | I'm totally unfamiliar with that, in any detail |
| 2021-07-14 16:13:54 | × | pfurla_ quits (~pfurla@ool-182ed2e2.dyn.optonline.net) (Ping timeout: 272 seconds) |
| 2021-07-14 16:14:43 | <EvanR> | so compilers don't treat the cache as a 'would be nice' bonus effect, but actively try to whisper it and get as much performance as possible? |
| 2021-07-14 16:15:12 | <EvanR> | that sounds like hell for cache designers |
| 2021-07-14 16:15:14 | → | elf_fortrez joins (~elf_fortr@adsl-72-50-4-118.prtc.net) |
| 2021-07-14 16:15:38 | <davean> | Its not "would be nice" its a "can be incorrect under ..." |
| 2021-07-14 16:15:45 | <davean> | and then they also give it specific commands |
| 2021-07-14 16:15:50 | <davean> | evictions, prefetches ... |
| 2021-07-14 16:16:18 | <davean> | and compilers know the cache can get bad results and try to avoid it |
| 2021-07-14 16:16:26 | <davean> | you can write to a memory location, but read an old value for example |
| 2021-07-14 16:16:39 | → | _ht joins (~quassel@82-169-194-8.biz.kpn.net) |
| 2021-07-14 16:16:51 | <EvanR> | really... I thought that was a serious security problem a while back and had to be fixed |
| 2021-07-14 16:17:07 | → | jneira[m] joins (~jneira@214.red-176-83-92.dynamicip.rima-tde.net) |
| 2021-07-14 16:17:09 | <davean> | No, the security problem was making decisions based on memory *you weren't allowed to read* |
| 2021-07-14 16:17:13 | <davean> | which also interacted with the cache |
| 2021-07-14 16:17:16 | <davean> | but also with speculation |
| 2021-07-14 16:17:19 | <davean> | etc |
All times are in UTC.