00:00:00 --- log: started forth/16.07.19 00:37:42 gnawzie: well 00:37:57 gnawzie: you can use an Arduino as an ICSP adaptor 00:38:13 only thing to watch is that you do only have 2KB of RAM available 00:38:26 i decided to just use gforth 00:38:38 that being said, take a look at the fignition too 00:38:42 hating the way math works though 00:38:51 hm? 00:38:57 what does gforth do? 00:40:01 like, does it do maths in a particularly weird way? 00:40:17 just forth in general with postfix 00:40:32 can't use parenthesis 00:43:04 you don't need to 00:43:13 that's kind of the whole point of RPN 00:43:37 also it simplifies the hell out of parsing, which is why HP used it for their high-end calculators 00:50:20 Had never heard of figniion before. Pretty cool. 00:53:45 do you ever use sockets 00:55:54 proteusguy: it's nice, keyboard's a bit weird 00:56:08 proteusguy: I bought one at OggCamp a few years ago, and fire it up occasionally 00:56:24 gnawzie: in Forth? No, because I tend not to use Forth on machines with network hardware 01:05:26 gordonjcp, I was privately hoping it had a 6809 on it when I saw it was an 8-bit computer. Still, AtMel's asm is quite clean. Just no second stack and everything has to go through registers makes it a bit clumsy for forth. 01:08:55 proteusguy: yeah 01:09:29 I mean basically anything that has a couple of registers you can do indirect addressing with, and autoincrement 01:09:41 but the 6809 is just ridiculous for Forth 01:22:15 AVR is my favorite microcontroller however. 01:30:18 --- quit: gnawzie (Quit: SLEEPY YENA MUST SLEEP!) 02:05:08 --- join: pdewacht (~repent@kulon.2k38.be) joined #forth 02:12:27 oh ffs why is there a car pulling up outside my house 02:12:46 I get a few days off and randoms turn up 02:12:59 * gordonjcp -> off to put a shirt on 02:13:10 trying to implement a bloody stack machine here 02:15:01 --- join: JDat (~JDat@89.248.91.5) joined #forth 02:16:31 ``AtMel forth''?! You mean targeting AVR? 02:21:51 DKordic: don't see why it wouldn't work as a cross-compiled language :-) 02:21:58 or on larger chips with a bit of RAM to play with 02:36:13 I mean it's not written by Atmel. I guess You mean ``[A]T[m]ega [forth]''. 02:36:55 ah 02:58:09 --- quit: nighty (Quit: Disappears in a puff of smoke) 03:07:25 --- quit: JDat (Ping timeout: 264 seconds) 03:20:49 --- join: backer_ (~backer@cowbell.employees.org) joined #forth 03:21:10 --- quit: backer (Read error: Connection reset by peer) 04:07:42 --- join: true-grue (~true-grue@176.14.216.104) joined #forth 04:14:14 --- join: wa5qjh (~Thunderbi@203.111.224.40) joined #forth 04:33:54 --- join: karswell (~user@122.66.200.146.dyn.plus.net) joined #forth 04:36:39 --- quit: wa5qjh (Remote host closed the connection) 04:37:21 --- join: wa5qjh (~Thunderbi@203.111.224.40) joined #forth 05:20:05 Ha-ha-ha! 05:20:21 x86 is so slow that it takes all 10 top positions. 05:23:44 --- quit: DGASAU (Read error: Connection reset by peer) 05:24:01 --- join: DGASAU (~user@194.31.92.26) joined #forth 05:30:55 Alright, this year two or three positions are taken by PPC and SPARC. 05:31:04 Otherwise, Xeon. 06:11:10 --- join: nighty (~nighty@s229123.ppp.asahi-net.or.jp) joined #forth 06:32:09 --- quit: karswell (Remote host closed the connection) 06:32:26 --- join: karswell` (~user@122.66.200.146.dyn.plus.net) joined #forth 06:53:38 DGASAU: what with the ARM buyout, I can see OpenSPARC making a comeback 07:21:14 It may come back, but it isn't fast still. 07:21:27 Never has been in past two decades. 07:22:55 They are all slow. 07:23:53 Check TOP100 supercomputer list. 07:27:32 --- quit: DGASAU (Read error: Connection reset by peer) 07:28:06 --- join: DGASAU (~user@lmpc.drb.insel.de) joined #forth 07:31:16 Last time anything was faster than x86 was around 2000. 07:31:21 Or even earlier. 07:32:47 Sunway SW26010 260C is better than anything else :) 07:33:05 --- quit: karswell` (Read error: Connection reset by peer) 07:33:45 This, probably, explains why Forth lovers think that x86 is slow. 07:33:56 They are stuck in their seventies. 07:41:22 true-grue: actually, we are to compare performance of single core to be fair. 07:42:39 But even if we compare complete MPPCs, x86 is still better. 07:43:12 DGASAU, But it should mean something that Chinese replaced Xeon cores with their own architecture and got 1 place, with the system far superior than other supercomputers. 07:43:45 You do understand that in many cases it is an issue of horizontal scalability. 07:44:14 I do understand that Xeon has the legacy issues. 07:44:24 I agree that it works for problems that are really parallelizable, 07:44:31 DGASAU, Intel has the billions to throw at higher density fabs. Nothing inherently superior about their architecture. No one else can fab that small. 07:45:09 proteusguy: Chinese have same billions as well. 07:45:50 Yet their CPU runs at ca. 1,5 GHz. 07:46:23 It corresponds to energy-saving mode of recent Intel CPUs for laptops. 07:47:53 true-grue: if you consider legacy issues a handicap, you understand that it makes x86 look even better. 07:50:32 quick, let's start up in 16 bit mode, incase someone installs dos on this 3ghz computer 07:50:58 Well, as proteusguy said, Intel has the best techology. But their architecture which is build on top of the technology definitely not the best one. Still these better/worse make sense only in specific context. 07:51:26 Context is specific already: performance. 07:52:19 Last time anything else beated x86 in single core performance was around 2000. 07:52:45 Within last decade most of the time top500 was led by Intel Xeon. 07:52:53 Today we have another important characteristic: energy efficiency for particular kinds of tasks. 07:53:11 "Particular kinds of tasks" is hard to formalize. 07:54:16 another thing is that, in reality, modern x86/64 processors aren't actually x86/64 07:54:22 they've got a lower level 07:54:34 that basically emulates the x86/64 on top of that 07:54:44 vendan: it doesn't matter here. 07:54:45 microcodes for the win! 07:54:57 Architecture is a minor detail. 07:55:28 true, true 07:55:40 the main thing is the tech 07:56:08 not exactly the first time "shitty, but everyone uses it" won over "technically better in all ways, but not popular" 07:56:21 I'm not against having better CPU architecture than x86. 07:56:33 Specialization is a major trend today. That Chiniese chip has 260 cores. So you just can't compare it with some Intel Atom. Moreover no other Intel chip has so many cores inside. But it all make sense for particular kinds of tasks :) 07:56:42 Yet, telling that x86 is slow is plain bullshit. 07:58:14 DGASAU, you measure that as performance per watt or straight up speed at all cost? 07:58:14 true-grue: it's not clear if a layman can turn such architecture that trades number of cores for single core performance into benefit. 07:58:31 proteusguy: I don't measure. 07:58:37 Read above. 07:58:48 Someone suggested that "x86 is slow", which is plain bullshit. 07:59:31 It is bullshit even if top 10 is led by some unknown Chinese chip this year. 07:59:34 x86 is not an efficient processor for forth is probably how I would interpret that. Context is everything. And architecture does matter. 08:00:05 x86 is a flawed architecture 08:00:06 But clearly x86 processors go fast if you're taking a single dimensional measurement. 08:00:16 that's not exactly a hard thing to understand 08:00:22 it just won the market battle 08:01:07 winning the market battle allowed them to turn around and pump a lot of money into making the processor better 08:01:17 DGASAU, Sure, I agree that for a layman casual activity choice of x86 chips is more than enough :) 08:01:33 but even the way modern processor is designed screams "X86 is flawed" 08:01:36 vendan: part of the problem with per-watt measurement is that you can make a CPU that doesn't consume anything and doesn't do anything, making it the most efficient ever. 08:01:56 was that meant for someone else? 08:02:03 I never even suggested per watt 08:02:09 Sorry, that was for proteusguy. 08:02:12 The age of the general purpose CPU is going away... that's Intel's bread and butter. Power consumption is a matter of physics and not a huge concern for them until recently. Now performance per watt and context of app/architecture are getting more important every day. CPUs are memory bandwidth limited rather than computationally limited. Intel's got a lot to work on to stay on top. 08:02:22 true-grue: I meant slightly different thing, actually. 08:03:01 NUMA will be the way forward 08:03:18 DGASAU, the application context matters tremendously. Talking about a measurement of real work done, not a benchmark made by CPU manufacturers. 08:03:38 proteusguy, dark silicon! :) 08:04:19 The separation of hardware and software is getting more blurry every generation now. 08:08:51 DGASAU: diesel engines aren't fast but they power every truck you've ever seen 08:09:14 proteusguy: usage patterns don't comprise continuum. 08:09:27 DGASAU: one of the great things about old Sun kit and old Solaris was that while it wasn't particularly fast, it wasn't particularly load-sensitive either 08:09:42 immensely reliable 08:10:43 I know why 260-core CPU would be useful to me. 08:11:10 But that's quite peculiar type of tasks. 08:12:11 I can't claim that there're a lot of people who can make use of "more slower cores" approach. 08:25:56 DGASAU: what are you doing with it? 08:26:07 something "embarrassingly parallelisable" I guess 08:30:39 Not embarrasingly. 08:31:36 Yes, even in the worst case of NLP, I can use better parallelisable argorithm and hope that it goes faster by throwing more cores in. 08:31:59 Probably, PSO or something alike. 08:32:44 --- quit: nighty (Quit: Disappears in a puff of smoke) 09:43:25 --- quit: beretta (Quit: Leaving) 09:47:04 --- join: JDat (JDat@89.248.91.5) joined #forth 09:51:48 DGASAU: well NLP isn't particularly time-sensitive either so I guess you could throw a ridiculous cluster at it 09:52:36 hash cracking! 09:52:56 easily partitionable! 09:53:09 though, fairly well dominated by GPU based systems right now 09:57:04 wait until you see my sweet PDP8coin mining rig 09:57:13 overclocked to 866kHz, bitches 09:57:17 rofl 09:57:34 well, I've got a box with 6 r9-290x's 10:13:34 gordonjcp: what do you call "time-sensitive"? 10:13:37 --- quit: wa5qjh (Ping timeout: 276 seconds) 10:14:01 DGASAU: realtime audio and video processing 10:14:07 NLP is not easily parallelisable. 10:14:16 where a couple of milliseconds latency is a fucking disasterpiece 10:14:32 Well... It depends on the application where you use NLP. 10:15:51 For instance, do you mean that, say, FFT isn't used in real-time applications? 10:16:11 Pseudo-spectral methods have the same application essentially. 10:18:37 gordonjcp, For audio processing you just need some kind of G144, but for "rest of us", i.e. with simple easily programmable RISC-like cores :) 10:19:15 --- join: wa5qjh (~Thunderbi@203.111.224.40) joined #forth 10:19:25 The idea is to map audio processing graph directly to the array of simple and fast cores. 10:20:40 --- join: Zarutian (~zarutian@168-110-22-46.fiber.hringdu.is) joined #forth 10:24:01 --- quit: wa5qjh (Ping timeout: 276 seconds) 10:25:05 DGASAU: it is, I use it in SDR for example 10:25:17 DGASAU: but you have to be very aware of the effects of latency 10:25:54 Then NLP is time-sensitive too. 10:26:13 It's not necessarily so, yet it has same application. 10:29:41 E.g. we replaced FFT with pseudo-spectral analogue to reduce latency once. 10:34:59 --- join: Carisius (~Carisius@cm-188-171-4-60.telecable.es) joined #forth 10:38:57 --- quit: proteusguy (Ping timeout: 276 seconds) 11:08:04 --- quit: reepca (Ping timeout: 260 seconds) 11:25:09 --- join: proteusguy (~proteusgu@180.183.48.17) joined #forth 11:25:09 --- mode: ChanServ set +v proteusguy 11:34:13 --- quit: gravicappa (Ping timeout: 276 seconds) 12:11:43 --- quit: Carisius (Ping timeout: 252 seconds) 12:51:32 --- quit: Zarutian (Read error: Connection reset by peer) 12:52:50 --- join: Zarutian (~zarutian@168-110-22-46.fiber.hringdu.is) joined #forth 12:53:13 --- quit: Zarutian (Read error: Connection reset by peer) 12:53:59 --- join: Zarutian (~zarutian@168-110-22-46.fiber.hringdu.is) joined #forth 13:49:02 --- join: reepca (~user@184.52.15.40) joined #forth 14:37:42 --- join: ASau (~user@netbsd/developers/asau) joined #forth 14:53:33 --- join: wa5qjh (~Thunderbi@203.111.224.40) joined #forth 15:34:57 --- quit: wa5qjh (Remote host closed the connection) 15:42:31 --- quit: Zarutian (Quit: Zarutian) 15:47:03 --- join: nal (~nal@adsl-64-237-236-16.prtc.net) joined #forth 16:10:07 --- quit: true-grue (Read error: Connection reset by peer) 20:12:05 --- join: wa5qjh (~Thunderbi@203.111.224.40) joined #forth 20:13:20 --- quit: yunfan (Ping timeout: 244 seconds) 20:14:35 --- quit: wa5qjh (Remote host closed the connection) 20:18:13 --- join: wa5qjh (~Thunderbi@203.111.224.40) joined #forth 20:27:27 --- join: yunfan (~roooot@unaffiliated/yunfan) joined #forth 21:14:12 --- quit: nal (Ping timeout: 240 seconds) 21:48:57 --- quit: nisstyre (Read error: Connection reset by peer) 23:16:04 --- quit: proteusguy (Ping timeout: 260 seconds) 23:19:41 --- join: gravicappa (~gravicapp@h62-133-162-131.static.bashtel.ru) joined #forth 23:32:22 --- join: proteusguy (~proteusgu@180.183.141.52) joined #forth 23:32:22 --- mode: ChanServ set +v proteusguy 23:59:59 --- log: ended forth/16.07.19