a111: Logged on 2019-02-20 16:08 asciilifeform: various folx attempted something roughly like this, but succumbed to own idiocy -- e.g. the java people, who 1) wrapped their 'vm' around the nonsensical shape of their tardlang 2) stopped short of 'and no this doesn't run on your tard os, is IS the os, fuckyou' ;
Mocky: I was hopeful back in the day at java chip and java os, nothing worthwhile surfaced
a111: Logged on 2019-02-20 15:50 asciilifeform: really oughta have ~1~ compiler, and for a sane arch; and if yet cannot afford to actually siliconize the sane arch, then the sad iron oughta be booting straight in bios to a compact (asmistic) emulator of same
Mocky: I mostly agree. They did manage a coherent threading model / memory model which turns out to be the thing I miss when I'm writing in something else
Mocky: there are explicit and implicit semantics, but if you read the spec, you know what you'll get. multiple threads setting a value on the same variable never create garbage
Mocky: setting and getting
mircea_popescu: Mocky so if i declare a procedure which increments a global and a local counter, and then call it in a loop from multiple threads, at the end the globa lflag will contain the sum of the local flags ?
Mocky: can do multithreaded i++ and never get garbage, if you mark it volatile forces read and write to main memory
mircea_popescu: but the ensemble will not move at the speed of a single core will it ?
☟︎ Mocky: i'm not saying they solved threading once and for all, or that eliminated deadlock. any system that allows you to acquire locks in different order can be deadlocked. i'm just saying that there are concurrent primitives that can be understood and which have guaranttes that hold
mircea_popescu: Mocky just trying to evaluate if this thing worth digging up
Mocky: and yes can increment global and local counters in threads and have it add up, but requires locking or cas
Mocky: laugh if you will, yet still can't do it even *with* locking in standard c++, as far as I can tell
Mocky: so not optimal, maybe even laughable, but yet has a model and as spec that is not self contradictory
Mocky: it is on c machine after all
Mocky: yeah, early java lists were shit in that way but no more. now shit in diff ways
Mocky: I'm not defending java, I'm stating that in addition to pile of shit, theres a coherent memory model, thread model that is not agony to work with.
Mocky: i've seen dozens of those. look equally shit on every platform
Mocky: i wouldn't argue that explicit threading is good. but instead of concurrent i++, consider concurrent assignment to heap references, even without locking always have a valid reference, never a garbage pointer, no matter how many threads or cores
Mocky: anyway coherent != good
Mocky: also threads in infinite loops can always be stopped on every platform
Mocky: serious question asciilifeform, where do I look to see better threading that java. I honestly dont' know
Mocky: iirc that was after backus turned to shit in committee
Mocky: fortran threading I never looked at, but will. pretty sure threw away all my punch cards tho
Mocky: erlang I did look at briefly, but not the concurrency, seemed to me like a puzzle lang
a111: Logged on 2015-06-22 21:22 mircea_popescu: ascii_field this goes right into our discussion about how the only reason lisp is ok where c is shot is that the hordes haven't sat on lisp but on c, would have been the other way around if they had sat the other way.
a111: Logged on 2017-03-30 14:38 asciilifeform: mircea_popescu: i will also nitpick : 'erlang' does not belong in the list, it was a 1980s product that worked quite well in its industrial niche (large telco switches) but was later stolen and used as a totem by the folx from yesterday's thread (
http://btcbase.org/log/2017-03-29#1633873 )
a111: Logged on 2017-03-30 14:43 asciilifeform: anyway erlang is imho only worth discussing as part of a larger pattern -- industry after industry independently discovered that c -- and its entire approach to logic -- is poison
a111: Logged on 2017-03-30 14:50 asciilifeform: trinque: erlang wasn't simply about 'uptime', or even 'no pointer arithmetic', it also was the only case i know of where process migration actually worked
Mocky: sounds accurate enuf
Mocky: indeed. I've had my fill of java, but get paid for it so it's still in my immediate future
Mocky: but i don't have asciilifeform's mental model of a much better lang with which to compare. I have c c++ python javascript that I also get paid to work with occasionally, which ~entirely punt on threading
a111: Logged on 2019-02-20 15:02 mircea_popescu: trinque did you ever see the guy irl lately ? say this year or something ?
a111: Logged on 2019-02-21 02:06 asciilifeform: ... which means they're liable to all end up on 1 physical cpu, lol
a111: Logged on 2019-02-21 01:45 mircea_popescu: but the ensemble will not move at the speed of a single core will it ?
mircea_popescu: "This used to be the page for my fork of Fabrice Bellard's Tiny C Compiler, but I got sick of competing with a mostly dead CVS archive that nevertheless remained "official". Every time I worked on my fork it inspired new work in the old CVS archive, and every time I set my fork aside the old project ground to a halt. Even though the old tcc project repeatedly stagnated whenever I stopped working on my fork for a few months, n
mircea_popescu: obody wanted to work with me on my version because it wasn't "official"."
mircea_popescu: this is actually more substantially gnu than any tech/engineering/cs/anything. invidious wikitards rather than anything else.
mircea_popescu: "(People sent me bug reports about the 0.9.24 release. Yeah, that release contained a lot of code copied out of my tree into CVS, but the release was based on CVS, not on my tree.) By 2008 as CVS sank into obsolecense, TCC had clearly decided to go down with the ship. No matter how much work I put into my fork it would never eclipse the "official" tcc project (which could of course read my code to advance their tree)."
mircea_popescu: basically, the cunts were just taking dood's patches and dropping them in their toilet.
mircea_popescu: "hen I stopped work on my fork, the other project stopped, but when I started up again, so did they. All I was doing was keeping the CVS tree just active enough to exclipse mine, and I was tired of it."
mircea_popescu: anyway, has a shitty html blog, all the symptoms people go through in that quarter or two between when they get the republic illumination and when they become actually useful/productive.
mircea_popescu: but, if looking for more targets to practice your email curse...
mircea_popescu: Someday if I get back to this topic, I want to glue either sparse or the tcc front end to qemu's tcg back end and produce a new compiler that A)
mircea_popescu: supports all the targets qemu does, B) can build linux and busybox and uClibc and itself (thus providing a self-bootstrapping system; I'd upgrade busybox to have missing bits like "make"). << maybe HE could be doing the tcc work, at any rate.
bvt: not yet, but can give it a shot sometime next week
bvt: it seems to be quite a new item, iirc less than a year old. i'd expect it does not support arm. can't say anything about bugs without trying out.
bvt: i have seen reports of this, but never verified myself. my understanding is that there is a slow c++zation of gcc: i backported one gcc patch for my home system from 6 to 4.9, this involved removing c++ chunks.
bvt: but version 4.9 looked healthy (i.e. plain c, did not see any cpp code there). i had a look at a single file, though, so this is no guarantee.