|
github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today Set by moderator on 17 May 2018. |
|||
|
01:14
MasterDuke_ joined
01:57
ilbot3 joined
|
|||
| moderator | github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today | ||
|
02:09
zakharyas joined
05:07
harrow joined
06:09
shareable6 joined
06:18
domidumont joined
06:20
robertle joined
06:25
domidumont joined
07:29
shareable6 joined
08:13
lizmat joined
10:31
FROGGS joined
12:15
ggoebel joined
|
|||
| ggoebel | curious if there are implications for moarvm related to growing difference between the underlying hardware and assumptions baked into C... "C Is Not a Low-Level Language" (queue.acm.org/detail.cfm?id=3212479) | 12:27 | |
| lizmat | ggoebel: interesting article :-) | 12:39 | |
| perhaps jnthn / brrt have some insights that are worth more than mine :-) | 12:40 | ||
| FROGGS | I must admit that did not understand the article in the end | 12:51 | |
| lizmat | FROGGS o/ | 12:53 | |
| FROGGS | hi | ||
| lizmat | as a slang guru, do you have any idea why github.com/lizmat/P5__DATA__ doesn't work ? | ||
| FROGGS | let me see | 12:54 | |
|
12:55
shareable6 joined
12:58
AlexDaniel joined
|
|||
| lizmat | brb | 12:59 | |
|
13:08
robertle joined
|
|||
| lizmat | afk for a few hours& | 13:10 | |
| FROGGS | .tell lizmat This works in some way: github.com/FROGGS/P5__DATA__ | 13:46 | |
| yoleaux | FROGGS: I'll pass your message to lizmat. | ||
|
14:05
shareable6 joined
16:02
brrt joined
|
|||
| brrt | \\o | 16:02 | |
| jnthn and I discussed that article some days ago, actually :-) | |||
| my opinion on the matter is: | 16:05 | ||
| - the central thesis of the author is that CPUs have developed to the interface of a sequential machine with what is effectively an extremely complex parallel machine | 16:06 | ||
| - that C exposes a machine model that is similar to the *emulated* machine, but not one that is actually similar to the physical machine | |||
| - that the only way to unlock the capacity of modern chips (and by extension, to further computer science as a field / industry) is to embrace the parallel nature of those machines | 16:07 | ||
| i agree with all but the last premise, and of that, I'm not even sure I'm 100% in disagreement | 16:09 | ||
| geekosaur | I feel like there's another RISC (alpha) / VLIW (itanium) mistake hiding in that last part. to be more specific: there's truth in there but we still haven't the faintest idea how to leverage it | 16:13 | |
| which is precisely why we're still using the model we understand | |||
| brrt | that is pretty much how i feel about it as well | 16:26 | |
| the basic assumption is, though, that we need more FLOPS in order to progress | |||
| I'm not willing to dismiss that. I think that's true | 16:27 | ||
| but: | |||
| - it might only be true of relatively specialized domains, like machine learning | |||
| - on the other hand, a *lot* of money is being made by programs written in php, python, ruby, perl, etc, precisely because we *don't* always need more FLOPS to make progress | 16:28 | ||
| now that i think of it, there's really two conflicting worldviews at play | 16:29 | ||
| one is that CS progress involves ever better application of available computing power - I think that is the view of the author | |||
| the other is that CS progress involves ever better organization of complex (information) systems - that is the view that we can attribute to most system and language designers | 16:30 | ||
| i.e. what is perl but a better way to organize execution than C? (for a specific and rather large subset of problems) | |||
| now as to perl6: | 16:34 | ||
| - arguably, we're making the same mistakes, e.g. with autothreading, as the author attributes to C-machine-emulation in CPUs | |||
| - on the other hand we do have hybrid threads, so yay | 16:35 | ||
| - practically, we can maybe do more with vectorizing. samcv++ has been doing an pretty good job out of that | |||
| geekosaur | bleh, left. I would counter that they're the same problem but top down vs. bottom up | 16:42 | |
| and since we have no idea where the middle is, the only real option is to attack the sides where we have *some* clue. | |||
| and picking which side is the "best" is premature optimization | 16:43 | ||
|
17:11
Ven`` joined
17:31
domidumont joined
18:00
shareable6 joined
18:11
Kaiepi joined
18:24
MasterDuke_ joined
19:14
robertle joined
19:32
shareable6 joined
|
|||
| samcv | good * | 19:46 | |
| lizmat | samcv o/ | 19:47 | |
| yoleaux | 13:46Z <FROGGS> lizmat: This works in some way: github.com/FROGGS/P5__DATA__ | ||
| samcv | regarding queue.acm.org/detail.cfm?id=3212479 i thought the speculative execution affected assembly as well? it's the CPU that speculatively executes | 19:51 | |
| and not related to C or any other language. but the processor itself "doing things you didn't program it to do" | 19:52 | ||
| because it executes commands that are after a branch condition | |||
| to be fair i haven't finished the article yet | |||
| geekosaur | but if you're writing assembly code by hand you have more control; compilers don;t generally give you direct control over the code they produce, which can exacerbate it | 20:00 | |
| samcv | yes but you still then don't control the optimizations that are done | 20:01 | |
| a lot of the things they mention don't seem specific to C though. except for the part about how the C spec can cause restrictions for the compiler | 20:13 | ||
| but i suppose ideally we would have a *new* arch which would have *tags* whicdh would denote whether sections can be parallelized i.e. how variables are spatially related to each other and structurally | 20:14 | ||
| japhb | samcv: A truly new architecture is relatively unlikely unless/until someone comes up with one that is 1) LOTS faster than anything existing, and 2) Compiles C/C++/Java code. Because no one wants to rewrite trillions of lines of legacy code. | 20:21 | |
| There are a couple exceptions for purpose-built things like programming quantum computers, but that's pretty niche. | |||
| samcv | yeah. that necessitates a change so people don't have a choice... but for now we're sort of stuck with what we have | 20:22 | |
| japhb | And expect that someone will want to figure out how to compile some existing language down to it rather than rewriting in it. | ||
| Yup. So then we just have the continuous expansion of new ops and new execution units set into the existing architecture. | 20:23 | ||
| jnthn | Yeah, I figure we'll get new kinds of processing unit *alongside* the existing ones, much like GPUs have become used for rather more now than just graphics. | 20:35 | |
| MasterDuke | have you guys heard about "The Mill" cpu? | 20:40 | |
| i've watched a few of the video and they're way over my head, but i still found them interesting | |||
| en.wikipedia.org/wiki/Mill_architecture | 20:43 | ||
|
20:59
brrt joined
|
|||
| brrt | ohai | 20:59 | |
| sorry for leaving | |||
| samcv: yes, that's correct, so it's not really fair blaming C :-) | 21:00 | ||
| japhb: there already is a completely different architecture, its the GPU :-) | 21:02 | ||
| the bigger question is, are massively-parallel architectures ever really going to replace sequential architectures | 21:03 | ||
| jnthn | MasterDuke: Hm, I'd not heard of that. :-) Interesting. | 22:32 | |