00:00:00 --- log: started forth/19.05.03 00:22:32 --- join: proteusguy (~proteusgu@101.109.254.37) joined #forth 00:22:32 --- mode: ChanServ set +v proteusguy 00:36:57 --- quit: proteusguy (Ping timeout: 268 seconds) 00:47:22 --- join: proteusguy (~proteusgu@101.109.254.37) joined #forth 00:47:22 --- mode: ChanServ set +v proteusguy 00:51:00 --- quit: proteusguy (Excess Flood) 00:51:23 --- join: proteusguy (~proteusgu@101.109.254.37) joined #forth 00:51:23 --- mode: ChanServ set +v proteusguy 02:04:34 --- quit: ashirase (Ping timeout: 245 seconds) 02:06:57 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth 02:19:56 --- quit: proteusguy (Ping timeout: 268 seconds) 02:44:49 --- nick: jn___ -> jn__ 02:47:45 --- quit: Keshl_ (Read error: Connection reset by peer) 02:47:59 --- join: Keshl_ (~Purple@207.44.70.214.res-cmts.gld.ptd.net) joined #forth 05:01:56 --- quit: xek (Ping timeout: 246 seconds) 05:07:10 --- quit: nonlinear (Remote host closed the connection) 05:25:30 --- quit: rdrop-exit (Quit: Lost terminal) 05:29:59 --- quit: pierpal (Quit: Poof) 05:30:17 --- join: pierpal (~pierpal@host197-221-static.34-79-b.business.telecomitalia.it) joined #forth 05:31:14 --- quit: PoppaVic (Ping timeout: 276 seconds) 05:31:38 --- join: PoppaVic (~PoppaVic@unaffiliated/poppavic) joined #forth 06:15:54 --- join: proteusguy (~proteusgu@43.249.61.152) joined #forth 06:15:54 --- mode: ChanServ set +v proteusguy 06:33:49 --- join: dys (~dys@2003:5b:203b:102:226:5eff:fee9:68d2) joined #forth 07:15:50 --- quit: reepca (Remote host closed the connection) 07:39:45 --- quit: tabemann (Ping timeout: 250 seconds) 08:05:44 --- quit: chunkypuffs (Remote host closed the connection) 08:14:00 --- join: chunkypuffs (~chunkypuf@2a01:4f9:2b:16d5::1) joined #forth 08:42:54 --- quit: dave0 (Quit: dave's not here) 09:47:21 --- quit: dys (Ping timeout: 276 seconds) 10:57:03 --- join: Rickta59 (~kimballr@unaffiliated/rickta59) joined #forth 11:56:40 --- join: mtsd (~mtsd@94-137-100-130.customers.ownit.se) joined #forth 12:05:47 --- join: nonlinear (~nonlinear@unaffiliated/discrttm) joined #forth 12:16:45 --- quit: gravicappa (Ping timeout: 258 seconds) 12:18:32 --- join: reepca (~user@208.89.170.37) joined #forth 13:48:07 --- quit: pierpal (Ping timeout: 244 seconds) 13:55:36 --- quit: mtsd (Quit: leaving) 14:39:28 --- quit: arrdem__ (*.net *.split) 14:39:29 --- quit: ullbeking (*.net *.split) 14:44:15 --- quit: jimt[m]1 (*.net *.split) 14:44:15 --- quit: a3f (*.net *.split) 14:44:15 --- quit: pointfree (*.net *.split) 14:44:15 --- quit: pareidolia (*.net *.split) 14:44:15 --- quit: moony (*.net *.split) 14:44:16 --- quit: alexshpilkin (*.net *.split) 14:46:42 --- quit: ashirase (Ping timeout: 255 seconds) 14:49:27 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth 14:50:07 --- quit: proteusguy (Ping timeout: 244 seconds) 15:07:48 --- join: arrdem__ (sid333803@gateway/web/irccloud.com/x-myywbwrsfhzzngln) joined #forth 15:08:57 --- join: pareidolia (~pareidoli@87.213.124.143) joined #forth 15:09:08 --- join: ullbeking (sid5364@gateway/web/irccloud.com/x-gqqdmkvesfeiztzg) joined #forth 15:09:25 --- join: moony (moony@hellomouse/dev/moony) joined #forth 15:09:38 --- join: pointfree (sid204397@gateway/web/irccloud.com/x-chwewehjdghqmsxm) joined #forth 15:09:46 --- join: a3f (~a3f@chimeria.ext.pengutronix.de) joined #forth 15:10:10 --- quit: a3f (Changing host) 15:10:10 --- join: a3f (~a3f@unaffiliated/a3f) joined #forth 15:12:26 --- join: alexshpilkin (alexshpilk@gateway/shell/matrix.org/x-lecspbzvndjymijc) joined #forth 15:15:39 --- join: jimt[m]1 (jimtmatrix@gateway/shell/matrix.org/x-dejfianifsvdwhcv) joined #forth 15:17:59 --- quit: nonlinear (Quit: The Lounge - https://thelounge.github.io) 15:44:47 --- join: nonlinear (~nonlinear@unaffiliated/discrttm) joined #forth 15:48:55 --- join: cnidario (~aaa@92.57.58.87) joined #forth 15:51:52 --- join: pierpal (~pierpal@host197-221-static.34-79-b.business.telecomitalia.it) joined #forth 15:56:21 --- quit: pierpal (Ping timeout: 250 seconds) 16:11:56 --- join: tabemann (~tabemann@h193.235.138.40.static.ip.windstream.net) joined #forth 16:15:49 --- join: pierpal (~pierpal@host197-221-static.34-79-b.business.telecomitalia.it) joined #forth 16:27:24 --- quit: catern (Excess Flood) 16:31:55 --- join: catern (~catern@catern.com) joined #forth 16:35:24 --- quit: cnidario (Remote host closed the connection) 16:56:20 --- quit: john_cephalopoda (Ping timeout: 276 seconds) 17:09:52 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth 17:17:38 --- join: dave0 (~dave0@108.060.dsl.syd.iprimus.net.au) joined #forth 17:18:55 hi 17:37:06 morning forthy 17:37:55 good morning 17:38:18 --- join: rdrop-exit (~markwilli@112.201.166.63) joined #forth 17:41:38 hi presiden, crc 17:45:53 c[_] Good morning Forthists 17:46:20 hi rdrop-exit 17:47:47 Hi dave0 17:51:54 hey guys 17:52:02 I'm doing an experiment 17:52:11 Hi tabemann 17:52:14 I'm writing a new version of my sixel code that does RLE compression 17:52:26 and I'm going to test whether my non-compressed or my compressed code is faster 17:52:42 the code is going to be the same, aside from the compression part 17:53:15 it'll show whether the bottleneck is in the terminal emulator (or the passing of data through the OS) or in the sixel code 17:53:29 * dave0 nerds it up 17:53:56 there's probably a formula for the extra cpu time it takes to compress/decompress compared to the time it takes to send it 17:54:18 the big thing is that the forth I'm using, hashforth, is a slow forth 17:54:20 compared to the time you save when sending it 17:54:57 like I measured how fast a tight counted loop is in hashforth and it is half as fast as in CPython 17:55:35 of course I will rerun these tests once I write a version of hashforth that compiles to native code 17:58:33 --- quit: dddddd (Remote host closed the connection) 18:00:54 You could just comment out the code that writes to the terminal descriptor 18:04:36 or write 0 bytes to it 18:05:29 I've tried that oo in the past 18:05:34 *too 18:05:45 but now I've already written the compression code 18:05:59 now I just have to make sure it doesn't cause hashforth to crash 18:06:42 What was the result when you tried that 18:06:43 ? 18:11:18 that was with attoforth, and I was using some horrendously slow dithering code, and what I found was that removing the drawing did not speed it up 18:11:51 whereas the code that I'm using with hashforth is far faster, probably because I'm not attempting to dither 18:12:01 I see 18:24:56 bbiab 18:45:03 okay, I have confirmed 18:45:09 compression definitely slows it down 18:55:19 --- quit: ashirase (Ping timeout: 250 seconds) 18:59:13 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth 19:08:27 --- quit: ashirase (Ping timeout: 258 seconds) 19:11:37 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth 19:14:05 --- join: reepca` (~user@208.89.170.3) joined #forth 19:17:39 --- quit: reepca (Ping timeout: 258 seconds) 19:50:46 --- nick: reepca` -> reepca 19:53:49 --- quit: tabemann (Ping timeout: 250 seconds) 19:59:06 If even simple RLE is a net loss then your bottleneck is definitely somewhere other than the terminal interface. 20:16:16 --- quit: pierpal (Quit: Poof) 20:16:38 --- join: pierpal (~pierpal@host197-221-static.34-79-b.business.telecomitalia.it) joined #forth 20:37:30 tabemann, rdrop-exit: I timed compressed vs uncompressed with cputime in gforth: 12 for compressed and 22193 for uncompressed. Of course it depends on the image, but for the scribble paint it's tangibly faster with compression. https://hub.darcs.net/pointfree/forth-sixel/browse/paint.4th#24 20:41:04 --- join: tabemann (~tabemann@172-13-49-137.lightspeed.milwwi.sbcglobal.net) joined #forth 20:41:25 tabemann: I timed compressed vs uncompressed with cputime in gforth: 12 for compressed and 22193 for uncompressed. Of course it depends on the image, but for the scribble paint it's tangibly faster with compression. https://hub.darcs.net/pointfree/forth-sixel/browse/paint.4th#24 20:42:55 I tried again with the debugging features removed from hashforth, and it seems a bit faster without compression than with compression - the big thing, though, is that it seems less consistent in how much time it takes when using compression 20:43:06 --- quit: X-Scale (Ping timeout: 255 seconds) 20:45:14 Thanks for the numbers pointfree 20:46:40 I'm also running this on Linux which is preemptively multitasking things in the background. 20:47:51 maybe I'll try it on an mcu 20:55:17 --- join: gravicappa (~gravicapp@h109-187-220-185.dyn.bashtel.ru) joined #forth 21:00:07 --- quit: ashirase (Ping timeout: 250 seconds) 21:02:04 If the underlying Forth is still a moving target it may be premature to worry about sixel performance 21:03:08 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth 21:07:49 okay, without compression it takes about ~860 ms - with compression it takes about ~1520 ms 21:08:45 --- quit: dave0 (Ping timeout: 245 seconds) 21:09:42 --- quit: pointfree (Ping timeout: 250 seconds) 21:09:42 --- quit: ovf (Ping timeout: 250 seconds) 21:12:07 and I specifically omitted the startup time for initializing the framebuffer and some precomputed value tables from the time measured 21:13:54 --- join: ovf (sid19068@gateway/web/irccloud.com/x-qjkpdogfiprohawz) joined #forth 21:16:19 Maybe you have a bug in your RLE compressor code 21:25:22 --- join: pointfree (sid204397@gateway/web/irccloud.com/x-vbrhyqaigjtofhuf) joined #forth 21:26:52 I think it's pretty simple 21:27:33 the non-compressing version really just copies a pile of data from hashforth's memory space to mlterm's memory space, where mlterm parses it into pixels 21:28:09 the compression version has the added step of converting the uncompressed framebuffer into RLE compressed data, adding an extra step 21:34:58 What's in your "pile of data", it's not sixel commands? 21:37:03 it's sixel data 21:37:36 the difference between the uncompressed sixel data and compressed sixel data is compressed sixel data has RLE markers added to it and takes up less space 21:39:04 (I wouldn't call sixel data "commands" per se) 21:39:14 The sixel format is actually control sequences not raw data 21:40:04 That's why you can produce deltas with it BTW 21:41:28 You can move around the screen and place sixels where you want 21:42:15 It has carriage return and line feed equivalents 21:42:22 well of course 21:42:28 that's how you draw more than one color on a single line 21:43:20 Therefore you don't need to do 2 passes for RLE 21:43:43 You can generate RLE in the first place 21:44:30 You don't have to fill up a buffer with non-RLE control sequences, and do another pass to compress it 21:44:57 except that makes it hard to have generalized draw-color-at-x-y drawing primitives 21:45:53 You can do that on raw bitmap data 21:46:20 Sixels can just be a back-end format 21:46:56 what I'm doing is having a framebuffer that is encoded as sixels which is accessed in a random access fashion 21:47:12 and then having a compression pass which converts that framebuffer into RLE-encoded data 21:47:35 in the original framebuffer I have all the control characters already added to it, so they don't need to be generated for each frame 21:48:04 and the compression pass only acts on characters between 63 and 126, so the control codes are passed on unmodified 21:49:40 the framebuffer need not be regenerated for each frame, even though in the example code I've written I write the whole thing simply because I modify the entire canvas for each frame 21:51:42 Would it be possible for you to run a test with the same image that pointfree used in his test? 21:55:44 Is the image you're using large and amenable to RLE compression. Perhaps try with an all-white image. 21:56:37 oh, it's large 21:56:48 and very RLE-amenable 21:57:20 it's a 4x4 grid of colors, with one axis being red and the other axis being green, and each frame changing the amount of blue 21:58:03 Try all-white to max out the RLE. 21:58:34 all-white would speed things up greatly, because it would allow me to shrink the palette to one color, rather than having 64 colors 21:59:04 Keep everything else the same, so they don't affect the numbers. 22:00:46 I'm only using monochrome. 22:02:11 okay, switching it to only white speeds things up slightly, i.e. < 100 ms difference 22:05:21 thanks 22:06:05 Hm. Maybe I could get even more compression by overwriting lines: pixel-wise compression instead of just sixel-wise compression. 22:18:03 --- join: proteusguy (~proteusgu@43.249.61.152) joined #forth 22:18:03 --- mode: ChanServ set +v proteusguy 22:22:47 bbl 22:22:54 --- quit: rdrop-exit (Quit: Lost terminal) 23:59:59 --- log: ended forth/19.05.03