00:00:00 --- log: started forth/18.10.21 00:48:35 --- quit: verisimilitude (Remote host closed the connection) 00:53:24 --- join: dys (~dys@tmo-113-27.customers.d1-online.com) joined #forth 01:06:29 --- quit: dlyund (Ping timeout: 240 seconds) 01:22:02 --- quit: wa5qjh (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) 01:26:10 --- quit: DKordic (Ping timeout: 252 seconds) 01:27:34 --- quit: dys (Ping timeout: 252 seconds) 01:39:46 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth 01:56:01 --- join: dys (~dys@tmo-121-12.customers.d1-online.com) joined #forth 02:03:29 --- quit: ashirase (Ping timeout: 240 seconds) 02:08:00 --- join: ashirase (~ashirase@modemcable098.166-22-96.mc.videotron.ca) joined #forth 02:18:23 --- join: john_metcalf (~digital_w@host81-136-110-38.range81-136.btcentralplus.com) joined #forth 04:07:42 --- quit: FatalNIX (Ping timeout: 252 seconds) 04:08:09 --- join: FatalNIX (~FatalNIX@caligula.lobsternetworks.com) joined #forth 04:40:08 --- quit: wa5qjh (Remote host closed the connection) 05:09:35 --- join: kumool (~kumool@adsl-64-237-239-178.prtc.net) joined #forth 05:12:45 --- join: wa5qjh (~quassel@175.158.225.213) joined #forth 05:12:45 --- quit: wa5qjh (Changing host) 05:12:45 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth 05:31:31 --- quit: wa5qjh (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) 05:44:46 --- quit: kumool (Quit: Leaving) 05:45:31 --- join: kumool (~kumool@adsl-64-237-239-178.prtc.net) joined #forth 06:30:39 Yes, it's pretty eye-opening to realize just how "fundamental" a true hardware interface really is. 06:34:25 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 06:37:36 Well, frustrated this morning. I had some work-related testing I needed to do this weekend. Yesterday I got everything in place for it and ran off the first two of eight data sets - each one takes about three hours. 06:37:50 Woke up bright and early this morning to get going on the remainder, and found our office network down. 06:38:07 DHCP problem - I can ssh into my actual product boxes, which use static IP methodology. 06:38:20 But all of the other units I need to do the testing, that use dynamic IPs, are offline. 06:38:50 I've "put the word out," which is all I can do, but it's not too fun when my applecart gets upset like this. 06:39:27 The tests themselves are kind of interesting - the basic goal is latency vs. IOPS under various traffic conditions. 06:40:15 But I have three separate latencies I'm grabbing - 1) the latency measured by my test app, fio, 2) the latency reported by the product, and 3) an "in between" latency I get by taking iostat-reported queue depths and applying Little's Law. 06:40:41 It's interesting looking at how those behave and surmising things about how the various pieces of code must work. 06:42:41 Oof. When networks fail, it sucks big time. 06:42:57 You can't reach the host to debug the problem, so you have to have physical access to it. 06:43:17 Yes, and I'm not the person that fixes such stuff anyway, so I'm reliant on other people. 06:43:48 My current manager, though, who I've had for just a few months, seems to get actively involved in such situations - he plays the bad guy and makes sure the right people know and are chasing it. 06:44:35 So that in-between latency - the iostat-based one. For all queue depths > 1, it seems to move along closer to the fio latency than to the product latency. 06:44:48 But suddenly for qd=1 it snaps down to barely more than the product latency. 06:45:24 I suspect there's a conditional in the code such that when no queuing is required in that layer (primarily the lpfc driver, I think) it's much more efficient. 06:46:27 I may chase down the lpfc code and take a peek - see if I can see that. 06:46:51 The real business at hand here is to compare our performance between regular FC (SCSI over FC) and our new NVMe over FC offering. 06:47:40 It's an uphill battle from the start, because our *product reported* latency is about 30% higher at max IOPS than the SCSI latency. 06:47:58 So whatever goodie the OS is offering us we're sopping some of it up before the data ever even gets out of the product. 06:48:39 And we have a certain amount of parallelism in the box, which is the same for both methods, so 30% more latency means 30% less peak IOPS. 06:49:40 That makes the managers annoyed, because "everyone knows NVMe is faster." 06:50:03 I definitely see lower host CPU utilization for NVMe, by a significant amount. 06:50:22 Unfortunately I don't understand most of those words :P 06:50:30 I should be able to take the numbers I have so far, from those first two tests (random 4k reads) and do some arithmetic to get the OS latency difference. 06:50:40 I see. 06:50:42 Hopefully I'll find that the OS contribution to latency is lower for NVMe. 06:51:06 Um, Fiber Channel is just a protocol for moving data between two units. 06:51:28 Named that because it originally involved fibers, and still does to a large extent, but you can run the same protocol over any kind of cable. 06:51:48 SCSI and NVMe are two different "next layers that run on top ofthe FC layer in the stack. 06:52:14 NVMe is supposed to be able to bypass several of the os driver layers and get the data in and out of your application more "expeditiously." 06:54:23 Right, I see. 06:54:56 I had one look at SCSI and thought, why the fuck is it so complicated? 06:57:50 Yeah, no kidding. 06:57:59 I don't really deal with that level of detail. 06:58:25 The SCSI layer in Linux is what gives you the /dev/sd* devices. 06:58:47 Then in my case that layer calls the lpfc drvier, which was written by Broadcom. 06:58:56 Deals with their fiber channel HBA hardware. 06:59:32 Loosely speaking, I think my application measured latency is giving me product+fiber+(all OS layers). 06:59:43 And the iostat-based latency is giving me product+fiber+lpfc. 07:00:13 And I'm not sure yet how "good" our product latency is - I think product latency should be the time between the last byte of the command going into the product and the last byte of the response coming out. 07:00:21 I.e., what you'd measure with a protocol analyzer. 07:00:26 Taking a read of Threaded Interpretive Languages right now, seems good so far. 07:00:34 But I need to talk with some of the devs and learn whether we think our data is that good. 07:01:08 Cool. 07:01:18 All that sort of Forth stuff is interesting. 07:01:33 I love reading how different people have done things - I have no qualms about "stealing good ideas." :-) 07:01:57 Stealing good ideas makes 100% in CS. 07:02:07 A friend pointed me at a very verbose description of muForth the other day - there are some nice nuggets in there. 07:02:20 https://github.com/nimblemachines/muforth/tree/master/doc 07:02:24 If someone has an algorithm that sorts faster than your own, steal theirs. 07:02:25 etc. 07:02:50 Yep. As long as I understand it - I don't just "blindly copy source." 07:02:57 I try to understand, and then code my own. 07:03:10 Precisely. 07:03:23 By the way, most programming environments still lack a good way to quickly view documentation 07:03:51 The only ones I've come across are Lisp languages & Emacs, or Mathematica, which both provide quick access to documentation. 07:03:57 I suppose adding "doc-strings" to Forth words would be a good idea. 07:04:22 e.g. SEE FOO would give more than just the definition of FOO but its documentation as well. 07:05:11 Yeah, I'm hoping to do better on that. 07:05:23 I'm supporting compressed source code, so the editor will have to be pretty intelligent. 07:05:44 My "protocol" I've come up with for doing that compression is going to allow tokens that point to externally stored comments and documentation. 07:06:14 I'll be able to toggle the rendering of comments on and off, and will also have a separate window that documentation pops up in. 07:06:27 Historically I under-comment, because I hate how it makes my source code look. 07:06:43 There's this obsession with speed and optimization in a lot of ideas with Forth, perhaps breaking them would be acceptable in targets that have large memory. 07:06:43 I'm hoping that by making it possible to "switch off" comments I'll be more willing to do good commenting. 07:06:46 well, damn it just turned out that the SCSI spec text I had access to were badly written. 07:06:47 Ah I see, so you're making it more of an IDE, so to speak. 07:06:58 Yes, right. 07:07:11 I've been known to obsess excessively over performance. 07:07:29 in that annoying repeatitive tech writer meets corporate beurocrazy arse covering style 07:07:31 On this one I "care," and I want the plain vanilla performance to be "pretty good," but I'm not obsessing over it. 07:07:50 I plan to have a profiler that will tell me where speed really counts, and if need be I can do custom code words in those areas. 07:08:40 For example, I debated briefly about jumping to NEXT vs. putting it inline. 07:08:49 I opted for jumping to it, even though that is a hair slower. 07:09:08 Lots of convenience, and code size benefits, arise from doing it with a jump. 07:09:58 The MacOS required me to build this thing so it uses offsets instead of absolute addresses, so I needed the base address of the system in a register to offset off of. 07:10:10 I put NEXT at the very beginning, so that register can double as a NEXT pointer. 07:10:22 So jmp [r15] is my NEXT. 07:10:54 And my support for multiple processes and tasks involves using r14 to point to the currently executing task block. 07:11:01 KipIngram: I have noticed with arch-targets that have deep pipelines that do horribly on branch heavy code 07:11:21 And in the first cell of that block I have a pointer to the owning process block, so r14+offset gives me task stuff, and [r14]+offset gives me process stuff. 07:11:27 r15+offset gives me system stuff. 07:11:56 Even unconditional ones? There's little excuse for that. 07:12:32 even unconditional ones 07:12:54 siraben: So my context switch is 1) store regs in task block, 2) load r14 with new task block pointer, 3) load regs from task block, 4) continue. 07:13:07 That's pretty lame. 07:13:21 But I'll stick with this at this point. Maybe run some tests later to see how it's affecting me. 07:13:32 My NEXT seems to take about 1.3 ns; I'm pretty happy with that. 07:13:39 heck some compilers have switched to do as much straight line code by doing as much dataflow as possible in registers. 07:14:12 basically treat the CPU as DSP that you want to implement a virtual cpu on 07:14:15 I measured a lodsd-based NEXT as well - it's really close to the same. 07:14:27 Interesting. 07:15:04 I use r13 as my IP, and do the increment manually. 07:15:15 I'm hung up about my ITC next being slower than DTC 07:15:15 By a lot 07:15:16 r12 is return stack pointer, r11 data stack pointer. r10 is the frame pointer. 07:15:29 And r8 and r9 are the W and "other scratch" registers for the engine. 07:15:46 I try to think "most code we right isn't performance critical", but it's nice to have fast code. 07:15:47 siraben: Yeah, that can vary based on the processor. 07:15:52 write* 07:15:56 Most of that is probably coming from losing registered TOS. 07:16:13 Oh yes, losing TOS sucks. 07:16:28 I've read that can cause as much as a 30% speed differential. 07:16:45 I didn't realize the Z80 was that "challenged." 07:17:01 The upshot to all this is that I'll be able to make larger programs. 07:17:05 I've never actually coded on it - just read about it. 07:17:09 Yes. 07:17:11 KipIngram: isnt Z80 a variant of the original Intel 8080? 07:17:37 Yes, it was considered a groovy improvement on the 8080. 07:17:47 I might need to create two different Forths. One would be fast, but unable to have more than 400 bytes available for new words, and one would be slower but have basically unlimited space. 07:17:59 KipIngram (IRC): I blame the OS primarily. 07:18:08 The Z80 is not that challenged, it's TI that's making my life hard. 07:18:17 Oh, I see. 07:18:17 I call it the $C000 debacle. 07:18:23 Right. 07:18:30 KipIngram: I recall Intel 8080 was made when it was hip to make complex CISC commands to lure in assembler programmers 07:18:34 And I guess that some registers have to be left alone for the OS? 07:18:40 Just IY 07:18:50 But if you disable interrupts you can use it all you want. 07:19:05 Hmmm. 07:19:06 Except use of the index registers is not encouraged. 07:19:13 Because it's slower. 07:19:16 I suppose you could run with interrupts disabled until you went into KEY. 07:19:28 Right. 07:19:53 or briefly enable interrupts at the begining of NEXT and then disable them at the end 07:19:55 I read about the Z80 and became (at one time) fairly familiar with its instruction set, but some "insights" you just don't get without actually *programming*. 07:20:09 Zarutian: that's better - right. 07:20:33 (that is if your NEXT is a few instructions and interrupts get serviced when they are enabled again) 07:23:13 KipIngram: never got its 'resets' fetishism. How about calling what they are? Hard vectored software interrupts? 07:38:15 ? Not sure what you mean by "resets." 07:38:38 You're talking about like "int" instructions and stuff? 07:44:40 there were some z80 instructions that are only one byte long each and acted like interrupts 07:47:25 but ISA wise I still quite like the canonical dual stackmachine from Stack Machines The New Wave by P. Koopman. There interrupts are just unexpected subroutine call 07:51:53 --- join: ncv (~neceve@2a02:c7d:c5c9:a900:6eaf:6ef7:3b81:d5f6) joined #forth 07:51:54 --- quit: ncv (Changing host) 07:51:54 --- join: ncv (~neceve@unaffiliated/neceve) joined #forth 08:07:18 --- join: dlyund (~marksmith@ip-62-235-65-225.dsl.scarlet.be) joined #forth 08:35:48 --- join: DKordic (~user@178.220.204.159) joined #forth 09:50:44 --- quit: dlyund (Quit: Leaving.) 10:14:30 --- join: [1]MrMobius (~default@c-73-134-82-217.hsd1.va.comcast.net) joined #forth 10:17:12 --- quit: MrMobius (Ping timeout: 244 seconds) 10:17:12 --- nick: [1]MrMobius -> MrMobius 10:46:21 --- quit: ncv (Remote host closed the connection) 11:12:31 --- quit: ecraven (Read error: Connection reset by peer) 11:27:28 --- join: ecraven (ecraven@www.nexoid.at) joined #forth 12:34:14 --- join: pierpa (4f12eaf7@gateway/web/freenode/ip.79.18.234.247) joined #forth 12:36:35 --- join: verisimilitude (~user@2604:180:2:725::698a) joined #forth 12:53:23 --- quit: proteus-guy (Ping timeout: 260 seconds) 13:05:09 --- join: proteus-guy (~proteusgu@2403:6200:88a6:329f:f8f0:3ac0:84ef:151f) joined #forth 13:57:34 --- quit: dys (Ping timeout: 252 seconds) 14:41:52 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth 14:47:28 --- join: dys (~dys@tmo-096-157.customers.d1-online.com) joined #forth 14:57:56 --- quit: verisimilitude (Remote host closed the connection) 15:25:49 --- quit: wa5qjh (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) 15:27:31 --- quit: pierpa (Ping timeout: 256 seconds) 16:21:06 --- quit: nighty- (Quit: Disappears in a puff of smoke) 16:25:41 --- quit: FatalNIX (Changing host) 16:25:41 --- join: FatalNIX (~FatalNIX@unaffiliated/fatalnix) joined #forth 16:42:46 --- quit: tabemann (Ping timeout: 252 seconds) 16:51:22 --- join: xpoqp (~xpoqp@unaffiliated/xpoqz) joined #forth 17:14:22 --- join: tabemann (~tabemann@rrcs-162-155-170-75.central.biz.rr.com) joined #forth 17:39:41 --- join: nighty- (~nighty@kyotolabs.asahinet.com) joined #forth 17:43:34 does anyone know of a standardish word for defining a new CREATE-type word, with a signature like ( c-addr u -- xt )? 18:07:07 I just realized I can do something to create anonymous closures at runtime: :NONAME DOES> within another function 18:18:50 : noname-variable :noname swap , & [ does> @ ; 18:41:43 --- join: wa5qjh (~quassel@freebsd/user/wa5qjh) joined #forth 18:58:25 --- part: kumool left #forth 19:13:01 --- quit: tabemann (Ping timeout: 264 seconds) 19:44:14 --- quit: ashirase (Ping timeout: 264 seconds) 19:46:27 --- join: tabemann (~tabemann@2602:30a:c0d3:1890:d004:a860:b5ff:7c1c) joined #forth 20:58:48 --- quit: dddddd (Remote host closed the connection) 22:18:55 --- join: dave0 (~dave@90.20.215.218.dyn.iprimus.net.au) joined #forth 22:20:22 hi 23:52:57 Hi Dave. 23:53:21 hi KipIngram 23:54:37 KipIngram: siraben is doing a forth for his calculator, it has a Z80 processor in it, i got distracted reading about the Z80 assembly language 23:55:02 Yes, I'm familiar with his project; been in a number of chats with him. 23:55:24 it sounds interesting :-) 23:55:33 Yes, such things are always pretty fun. 23:55:41 It is :) 23:56:15 My whole choice of profession was largely based on the pleasure of making hardware do your bidding. :-) 23:56:29 Well, and just making hardware, period. 23:56:59 Bringing new things into existence kind of has a fundamental joy in it. 23:57:23 It feels good when you can create your own rules and have complete say in what happens in computing 23:57:33 ^ Yes. 23:57:36 Exactly. 23:57:42 Modern software development has clouded that feeling, which can be good or bad 23:57:52 Sometimes you need abstraction, sometimes not. 23:58:03 And designing the hardware and the software, from the ground up, is the purest form of that. 23:58:50 Then you get to make *all* of the rules. This will be done "in hardware, this will be done in software, and this is exactly how." 23:59:14 Right. I want to learn more about hardware this year 23:59:31 By reading a book called "NAND to Tetris" 23:59:58 siraben: bingo, i had read part of that too 23:59:59 --- log: ended forth/18.10.21