Newest at the top
| 2025-01-10 23:49:11 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2025-01-10 23:46:29 +0100 | target_i | (~target_i@user/target-i/x-6023099) (Quit: leaving) |
| 2025-01-10 23:44:11 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-10 23:41:11 +0100 | JuanDaugherty | (~juan@user/JuanDaugherty) JuanDaugherty |
| 2025-01-10 23:40:45 +0100 | mari51520 | (~mari-este@user/mari-estel) (Remote host closed the connection) |
| 2025-01-10 23:33:26 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 252 seconds) |
| 2025-01-10 23:28:49 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-10 23:28:34 +0100 | Tuplanolla | (~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) Tuplanolla |
| 2025-01-10 23:27:14 +0100 | peterbecich | (~Thunderbi@syn-047-229-123-186.res.spectrum.com) peterbecich |
| 2025-01-10 23:25:39 +0100 | __monty__ | (~toonn@user/toonn) (Quit: leaving) |
| 2025-01-10 23:22:53 +0100 | housemate | (~housemate@2a04:9dc0:0:162::5d91:d7ed) (Remote host closed the connection) |
| 2025-01-10 23:22:34 +0100 | housemate | (~housemate@2a04:9dc0:0:162::5d91:d7ed) housemate |
| 2025-01-10 23:21:24 +0100 | housemate | (~housemate@2a04:9dc0:0:162::5d91:d7ed) (Remote host closed the connection) |
| 2025-01-10 23:20:30 +0100 | housemate | (~housemate@2a04:9dc0:0:162::5d91:d7ed) housemate |
| 2025-01-10 23:19:53 +0100 | housemate | (~housemate@2a04:9dc0:0:162::5d91:d7ed) (Remote host closed the connection) |
| 2025-01-10 23:18:58 +0100 | housemate | (~housemate@2a04:9dc0:0:162::5d91:d7ed) housemate |
| 2025-01-10 23:18:23 +0100 | housemate | (~housemate@2a04:9dc0:0:162::5d91:d7ed) (Remote host closed the connection) |
| 2025-01-10 23:17:48 +0100 | housemate | (~housemate@2a04:9dc0:0:162::5d91:d7ed) housemate |
| 2025-01-10 23:17:46 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds) |
| 2025-01-10 23:16:50 +0100 | housemate | (~housemate@2a04:9dc0:0:162::5d91:d7ed) (Max SendQ exceeded) |
| 2025-01-10 23:15:45 +0100 | housemate | (~housemate@2a04:9dc0:0:162::5d91:d7ed) housemate |
| 2025-01-10 23:14:49 +0100 | ahisho | (~ahisoooo@88.90.222.87.dynamic.jazztel.es) |
| 2025-01-10 23:14:44 +0100 | <euouae> | & it won't be -- I still wanted to know (perhaps curiosity) how to produce the rationals without duplicates |
| 2025-01-10 23:14:36 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) |
| 2025-01-10 23:14:09 +0100 | <euouae> | mari51520: yes that's true. it's just an enumeration of the rationals, it doesn't need to be in the middle of it |
| 2025-01-10 23:12:29 +0100 | <mari51520> | that looks like it could be just another input to it |
| 2025-01-10 23:11:44 +0100 | <mari51520> | do you need that to be in the middle of the crunching euouae? |
| 2025-01-10 23:11:34 +0100 | <mchav> | That'll give you a sense of how the approach will scale. |
| 2025-01-10 23:11:23 +0100 | <mchav> | Well if you try it and get the performance under control it'll make for a lot of learning. I would still say do a prototype on your machine and profile it. |
| 2025-01-10 23:10:46 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) merijn |
| 2025-01-10 23:10:21 +0100 | <euouae> | because the paper has Haskell pseudo-code to explain its concepts... call me easily influenceable |
| 2025-01-10 23:09:54 +0100 | <euouae> | I was reading this paper <https://www.cs.ox.ac.uk/people/jeremy.gibbons/publications/rationals.pdf> which I need in some small part in my code, and it sort of made me think about doing it all in Haskell for the fun of it |
| 2025-01-10 23:09:13 +0100 | <euouae> | Yeah fair enough. I'm fairly good at reasoning with C++ so I don't need to involve Haskell to end up having to write expert-level Haskell for it |
| 2025-01-10 23:08:20 +0100 | <mchav> | Well I would still profile the run. I've been working on a dataframe library and I find I REALLY have to be careful to avoid copies. Intuitive/readable Haskell ends up being a memory hog. Or maybe I'm not that good at writing it. I don't know how this changes when you use something that FFIs to C and how GHC will then deal with pinned memory etc. |
| 2025-01-10 23:07:35 +0100 | <mari51520> | the interface will not need much logic anyways |
| 2025-01-10 23:06:01 +0100 | <euouae> | Ah -- memory-wise. hm... OK fine. Maybe I'll do it in C++. |
| 2025-01-10 23:05:31 +0100 | <mchav> | Memory and as result money, I guess. Have you profiled a sample implementation on your computer? |
| 2025-01-10 23:05:00 +0100 | <euouae> | does the jumpstart matter? |
| 2025-01-10 23:04:49 +0100 | <euouae> | mchav, OK but what do you mean costly? If my computations need 1+hr each? |
| 2025-01-10 23:04:37 +0100 | <mari51520> | well but it makes sense to have a server for crunching and another for haskell |
| 2025-01-10 23:04:32 +0100 | <mchav> | *GHC |
| 2025-01-10 23:04:24 +0100 | <mchav> | Haskell is really heavy-handed for this sort of thing. It'll be costly just to have Haskell running on each instance. |
| 2025-01-10 23:03:43 +0100 | <euouae> | also, for fun |
| 2025-01-10 23:03:29 +0100 | <euouae> | I'm expecting Haskell to simplify the MPI integration |
| 2025-01-10 23:03:24 +0100 | <euouae> | openMP is for single-host. if you want multi-host you need MPI. I don't have that code |
| 2025-01-10 23:03:18 +0100 | tromp | (~textual@92-110-219-57.cable.dynamic.v4.ziggo.nl) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-01-10 23:03:14 +0100 | <haskellbridge> | <magic_rb> But id recommend equinix or hetznee, theyre cheaper and more simple. Also youre not helping jeff bazos |
| 2025-01-10 23:03:02 +0100 | <mari51520> | why do you need haskell-friendly then? |
| 2025-01-10 23:02:55 +0100 | <euouae> | magic_rb: a single dedicated machine though? |
| 2025-01-10 23:02:40 +0100 | <euouae> | mari51520: I don't depend on anything, it's all my own code. In C++ it was with OpenMP and libgmp/libmpfr. |