2024/09/21

Newest at the top

2024-09-21 21:42:46 +0200 <tomsmeding> it seems the time is spent in shutdown, not in startup
2024-09-21 21:42:01 +0200 <tuxpaint> huh, but if i set both above 20ms, it then caps at 22ms runtime again
2024-09-21 21:41:25 +0200 <tuxpaint> so it seems it waits for either the first tick of the reschedule timer, or the clock timer or something?
2024-09-21 21:41:05 +0200 <tuxpaint> yeah. if i set V=100ms, and i=5ms, i get 7ms
2024-09-21 21:40:12 +0200 <tomsmeding> oops
2024-09-21 21:40:09 +0200 <tomsmeding> s
2024-09-21 21:39:07 +0200 <tuxpaint> i'm looking around for 20ms in the code. maybe it has something to do with the rescheduling timer?
2024-09-21 21:39:00 +0200 <tomsmeding> case in point: I also got 12ms for the `main = pure ()` with default settings on my machine, but starting a full blown web server and immediately exiting with `exitSuccess` if there are no command line arguments (to ensure that nothing can be optimised away) takes 15ms
2024-09-21 21:36:49 +0200 <tuxpaint> haskell is fun; it was my first language when learning to code many years ago. the IO monad was very nice to work with - didn't have a chance to do IO when i first touched haskell.
2024-09-21 21:36:27 +0200 <tuxpaint> of course there's a balance between the user experience in how easy it is for me to write the cli (more features), and how fast it executes
2024-09-21 21:36:20 +0200 <tomsmeding> same would hold for nodejs
2024-09-21 21:36:06 +0200 <tuxpaint> i am, which is why it was very confusing that haskell was starting up in the same amount of time
2024-09-21 21:35:51 +0200 <tomsmeding> tuxpaint: one thing that you may or may not be taking into account with perl and python is that they are interpreted, hence if you import a bunch of libraries, your startup time is going to suffer significantly
2024-09-21 21:35:49 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds)
2024-09-21 21:33:36 +0200 <tomsmeding> strict functional language, funny syntax sometimes (especially data type declarations), somewhat fewer fancy type system features than haskell, first-class mutability
2024-09-21 21:32:35 +0200 <tuxpaint> ocaml sounds fun, i may give it a try
2024-09-21 21:32:11 +0200 <tuxpaint> yeah, so far i have perl, python, c, go, nim, rust, haskell, c# done
2024-09-21 21:31:40 +0200 <tomsmeding> rust is a good candidate if you like haskell, otherwise (but I don't know anything about startup time here, so YMMV) ocaml
2024-09-21 21:31:27 +0200 <tuxpaint> so i've been going through seeing how the basic experience of reading flags and files is, along with writing to stdout.
2024-09-21 21:31:03 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl)
2024-09-21 21:30:41 +0200 <tuxpaint> 12ms startup time in a cli is perceivable to a user. i'm exploring languages to write clis in.
2024-09-21 21:30:01 +0200 <tuxpaint> interestingly, if i set it to a 8ms clock, runtime is 10ms. if i set it to 15ms clock, runtime is 17ms, up to 20ms, where anything there and above gives me ~22ms
2024-09-21 21:29:50 +0200 <tomsmeding> tuxpaint: is this startup-time benchmark just curiosity, or do you have a real usecase for 1. wanting to use a high-level language like haskell, and 2. needing fast startup time?
2024-09-21 21:28:43 +0200connrs(~connrs@user/connrs)
2024-09-21 21:28:11 +0200 <tomsmeding> ooh
2024-09-21 21:28:09 +0200 <tomsmeding> > The default is 0.001 seconds when profiling, and 0.01 otherwise.
2024-09-21 21:26:49 +0200 <tuxpaint> i guess my program doesn't use any timers, so the fastest option would be to use `-V0` and disable the RTS clock?
2024-09-21 21:24:50 +0200rvalue-rvalue
2024-09-21 21:23:29 +0200connrs(~connrs@user/connrs) (Ping timeout: 248 seconds)
2024-09-21 21:22:33 +0200 <tuxpaint> so i can compile with `-with-rtsopts="-V0.001"` and now it's the same. if i do `-V0.00001` it starts up even faster
2024-09-21 21:20:42 +0200 <tuxpaint> monochrom: your hypothesis is somewhat confirmed i think. compiling with `rtsflags` and using `-V0.001` gets me the same startup time as -prof https://downloads.haskell.org/ghc/latest/docs/users_guide/profiling.html#rts-flag--V%20%E2%9F%A8se…
2024-09-21 21:20:33 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 265 seconds)
2024-09-21 21:20:23 +0200rekahsoft(~rekahsoft@76.69.85.220)
2024-09-21 21:19:11 +0200rekahsoft(~rekahsoft@bras-base-orllon1103w-grc-06-76-69-85-220.dsl.bell.ca) (Remote host closed the connection)
2024-09-21 21:17:49 +0200rvalue(~rvalue@user/rvalue) (Ping timeout: 260 seconds)
2024-09-21 21:17:10 +0200briandaed(~root@185.234.210.211.r.toneticgroup.pl) (Remote host closed the connection)
2024-09-21 21:16:39 +0200rvalue-(~rvalue@user/rvalue)
2024-09-21 21:15:15 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl)
2024-09-21 21:15:10 +0200 <geekosaur> heh
2024-09-21 21:14:56 +0200 <monochrom> Ugh the joke is on me. I lost an old exe that uses regex-base etc, now I have to recompile it again.
2024-09-21 21:08:31 +0200 <geekosaur> overhead can still eat your lunch though…
2024-09-21 21:08:06 +0200 <tomsmeding> tuxpaint: but when a haskell program is going, it's quite a bit faster than python ;)
2024-09-21 21:08:01 +0200 <tuxpaint> regardless if it's correct to care about startup time, many people do, so maybe that is a good enough reason
2024-09-21 21:07:56 +0200 <geekosaur> so now they've moved on to startup
2024-09-21 21:07:44 +0200 <geekosaur> they already did a lot of qwork on shutdown time, which was kinda horrendous
2024-09-21 21:07:32 +0200 <tuxpaint> 12ms puts it at the same speed as the perl/python scripts that do the same thing, which feels a little wrong.
2024-09-21 21:07:29 +0200 <geekosaur> there is ongoing work on optimizing startup time, actually
2024-09-21 21:07:12 +0200merijn(~merijn@204-220-045-062.dynamic.caiway.nl) (Ping timeout: 272 seconds)
2024-09-21 21:05:31 +0200 <tomsmeding> 12ms is a fairly long time
2024-09-21 21:05:01 +0200 <tomsmeding> it's likely not top priority, and it shouldn't be