2024/06/26

Newest at the top

2024-06-26 02:27:09 +0200philopsos1(~caecilius@user/philopsos)
2024-06-26 02:22:38 +0200 <Axman6> also ping EvanR since you were looking into it too
2024-06-26 02:22:18 +0200 <Axman6> yeah that came to mind for me too
2024-06-26 02:22:05 +0200 <lambdabot> Consider it noted.
2024-06-26 02:22:05 +0200 <jackdk> @tell joeyadams https://well-typed.com/blog/2021/08/large-records/ might be relevant here
2024-06-26 02:19:29 +0200euleritian(~euleritia@dynamic-176-000-205-223.176.0.pool.telefonica.de) (Ping timeout: 252 seconds)
2024-06-26 02:18:55 +0200Tuplanolla(~Tuplanoll@91-159-69-59.elisa-laajakaista.fi) (Quit: Leaving.)
2024-06-26 02:08:21 +0200gmg(~user@user/gehmehgeh) (Quit: Leaving)
2024-06-26 02:08:11 +0200joeyadams(~joeyadams@2607:fb91:1617:1400:929b:26f0:654:cc5a) (Quit: Leaving)
2024-06-26 02:04:54 +0200 <joeyadams> Thanks. Maybe I should just create a single record and derive FromJSON, and look at the assembly. I'm mainly curious why it takes so much code to do (what should be) so little.
2024-06-26 02:00:47 +0200 <EvanR> there might be some more you could try https://stackoverflow.com/questions/6115459/small-haskell-program-compiled-with-ghc-into-huge-bina…
2024-06-26 01:59:55 +0200 <joeyadams> (the "program" is just a single .hs file where I copied some of my records over and pruned them. It references aeson, uuid-types, scientific, text, and bytestring.
2024-06-26 01:58:52 +0200 <joeyadams> strip takes the program from 24M to 14M, and the .o file from 2.3M to 1.2M. Better, but still a lot.
2024-06-26 01:58:31 +0200 <EvanR> guess not...
2024-06-26 01:57:50 +0200 <EvanR> -Os
2024-06-26 01:57:41 +0200 <joeyadams> Same size with -O2. Does GHC have something like -Os ?
2024-06-26 01:56:51 +0200 <EvanR> also you can try to strip the binary after the fact
2024-06-26 01:56:16 +0200 <EvanR> what about -O2
2024-06-26 01:56:06 +0200 <joeyadams> I looked into some flags a while back, it didn't help much. My results are with -O1. If I use ghc -O0 it makes the binary even bigger.
2024-06-26 01:55:27 +0200 <EvanR> you can issue flags to optimize for speed or size... -Os ?
2024-06-26 01:55:08 +0200 <EvanR> template haskell and generics does have a compile time cost, but you were asking about binary size
2024-06-26 01:54:20 +0200 <joeyadams> I'm just using GHC 9.4.8 installed through ghcup, not sure what that compiled in. I also tried with later GHC versions and saw similar results (slow compiles and large binaries).
2024-06-26 01:53:14 +0200 <EvanR> are you compiling in profiling support
2024-06-26 01:53:00 +0200 <EvanR> joeyadams, did you try flags to reduce the binary size, did you try to strip the binary
2024-06-26 01:52:06 +0200 <safinaskar> EvanR: okay :(
2024-06-26 01:51:40 +0200 <joeyadams> I should try writing the instances manually to see how big the code footprint is.
2024-06-26 01:51:39 +0200 <EvanR> Hi can you not respond to a haskell question by saying use rust
2024-06-26 01:51:23 +0200 <joeyadams> But I am curious why derived instances might take up so much code. Deriving FromJSON/ToJSON for 15 records produces as much binary code as the whole Aeson library.
2024-06-26 01:48:19 +0200 <joeyadams> An important detail I left out: I had deriving Show on all my records. I took that off and that took off 300K.
2024-06-26 01:46:56 +0200 <safinaskar> and then serde_json uses these instances
2024-06-26 01:46:49 +0200 <safinaskar> joeyadams: first package called "serde" derives all needed instances in compile time using so-called proc macros (it is code, which executes in compile time and generates AST, similar to template haskell)
2024-06-26 01:45:55 +0200 <safinaskar> joeyadams: serde_json works in compile-time
2024-06-26 01:45:46 +0200 <joeyadams> So I just need to write a quick sed replace to turn my Haskell code into Rust, and I'll be set :-)
2024-06-26 01:45:06 +0200 <safinaskar> joeyadams: binary sizes likely to be big, too. but compilation speed will be nice
2024-06-26 01:45:03 +0200 <joeyadams> Just curious, does serde_json use a generic system sort of like Haskell has, or is it more like C# where it's all run-time reflection?
2024-06-26 01:44:14 +0200 <safinaskar> joeyadams: instances for serde_json are generated automatically, too
2024-06-26 01:43:47 +0200 <safinaskar> joeyadams: aeson in rust world is called serde_json
2024-06-26 01:43:27 +0200 <safinaskar> joeyadams: use rust. it compiles fast (compared to haskell)
2024-06-26 01:35:44 +0200 <joeyadams> This means if I generate bindings for a database with 100 tables, I end up with an absurdly large binary. Not the end of the world, just slightly disappointing.
2024-06-26 01:34:18 +0200 <joeyadams> Records compile into somewhat large binaries, is this a known issue? For example, I have a module with 16 records (205 fields), and it produces a 490K .o file (versus 99K if I remove the records). If I derive generic Aeson instances, it becomes 2.3M, and takes several seconds to compile.
2024-06-26 01:11:36 +0200 <safinaskar> for example, "f :: forall (a :: Type -> Type). Int" can be written in C++ so: "template <template <typename> typename T> int f()"
2024-06-26 01:10:22 +0200 <safinaskar> i'm not sure about Rust, but in C++ this seems to be totally possible
2024-06-26 01:09:54 +0200 <safinaskar> how i will try to prove the same thing using C++ and Rust :)
2024-06-26 01:04:25 +0200 <EvanR> and see that it is much more powerful than stuff like coq which cripples itself into only proving true stuff
2024-06-26 01:04:13 +0200waleee(~waleee@h-176-10-144-38.NA.cust.bahnhof.se)
2024-06-26 01:04:09 +0200 <safinaskar> EvanR: unfortunately, this is easy, too. "false :: forall a. a" "false = undefined"
2024-06-26 01:03:21 +0200 <EvanR> for your next trick, use haskell to prove FALSE
2024-06-26 01:01:52 +0200 <safinaskar> so, yes, it is possible to fake type-level lambdas!
2024-06-26 01:01:13 +0200 <safinaskar> so yes, i was able to cope with all problems!
2024-06-26 01:00:57 +0200 <safinaskar> this means that induction actually works!