!CENmKDnMngVwJJrTry:matrix.org

Inko (lang)

15 Members
General purpose chat room about the Inko programming language.1 Servers

Load older messages


Timestamp Message
12 Nov 2019
21:49:12@yorickpeterse:matrix.orgyorickpeterseFor 1: basically the algorithm work by maintaining a "busy" counter, and when this reaches 0 the threads terminate
21:49:47@yorickpeterse:matrix.orgyorickpeterseBut if one thread spins super fast (incrementing it again at the start of a spin), other slower threads may never observe a value of 0
21:52:51@yorickpeterse:matrix.orgyorickpeterse

e.g. sometimes I see this:

marked: 40418 50310 53950 54237 55872 54761 56297 53995, out of 419840 in 4.511498ms

Here the first few columns are the number of objects marked per thread

21:53:05@yorickpeterse:matrix.orgyorickpeterse

but once in a while you'll get this:

marked: 52618 61574 66648 66500 67066 0 35251 70183, out of 419840 in 13.767362ms

13 Nov 2019
06:35:43@sarna:matrix.orgsarnabut one thread would be able to observe it, right? before incrementing it
06:36:07@sarna:matrix.orgsarna ah, but it could check, it’d be 1, and then some other thread could decrement
06:36:18@sarna:matrix.orgsarna * ah, but it could check, it’d be 1, and then some other thread could decrement
14:17:56@yorickpeterse:matrix.orgyorickpeterseThe issue here is that we may end up with threads terminating too soon
14:18:21@yorickpeterse:matrix.orgyorickpeterseThough there will at least always be one thread left to do the work, so the worst case it just takes much longer (instead of losing work)
19:12:00@sarna:matrix.orgsarnadoesn’t sound too bad
20:31:51@yorickpeterse:matrix.orgyorickpeterseI think I got the termination detection to work properly and not terminate prematurely, now to see if I can make sure all workers at least do some work
20:31:59@yorickpeterse:matrix.orgyorickpeterse instead of one or two sometimes not being able to do any work
17 Nov 2019
19:01:42@yorickpeterse:matrix.orgyorickpetersehttps://inko-lang.org/news/inko-0-6-0-has-been-released/
20:11:24@fsx:matrix.orgfsxπŸŽ‰
20:14:36@sarna:matrix.orgsarnavery nice πŸ‘
20 Nov 2019
22:29:18@yorickpeterse:matrix.orgyorickpeterseUgh, having quite some trouble with the new compiler's design. I want the compiler to compile modules in parallel, but this is tricky as those processes need access to type information. In my current approach I have a single process called the type database, owning all the structures. Other processes simply use type IDs (wrappers around integers), and message passing.
22:30:10@yorickpeterse:matrix.orgyorickpeterse Sadly this creates some design issues, such as how do we implement type checking? e.g. we could define the method type_compatible? on these type IDs, but then the implementation would have to be on the server side (since an ID doesn't really know what it actually points to), serialising most type operations
22:31:58@yorickpeterse:matrix.orgyorickpeterseOne approach I am currently considering is to have a different object for every kind of type ID (so a BlockId, MethodId, ObjectId, etc) instead of one general TypeId
22:32:19@yorickpeterse:matrix.orgyorickpeterseThen those Id types can implement the necessary functionality, meaning the types on the server side are just dumb data objects
22:32:57@yorickpeterse:matrix.orgyorickpeterse

So you get something like this:

# For the server
object ModuleType { ... }

# For the client
trait TypeId { ... }

object ModuleId { ... }

impl TypeId for ModuleId { ... }
22:34:03@yorickpeterse:matrix.orgyorickpeterseThis setup would (in a way) be somewhat similar to an Entity Component System
22:38:49@yorickpeterse:matrix.orgyorickpeterseAll of this would be easier if there was shared memory, but that would bring 99 new problems πŸ˜›
22:38:55@yorickpeterse:matrix.orgyorickpeterse * All of this would be easier if there was shared memory, but that would bring 99 new problems :P
22:39:13@yorickpeterse:matrix.orgyorickpeterse * All of this would be easier if there was shared memory, but that would bring 99 new problems πŸ˜›
23 Nov 2019
21:34:12@andrew_chou:matrix.orgAndrew Chou changed their display name from andrew_chou to Andrew Chou.
29 Nov 2019
15:13:44@yorickpeterse:matrix.orgyorickpeterseDecided to ditch the parallel type checking approach, as I could not make this work in a way that I did not hate. Instead, compilation will be broken up in stages and only some will be done in parallel
15:14:00@yorickpeterse:matrix.orgyorickpetersee.g. parsing will be done in parallel, but type defining and checking will be done sequentially
15:14:28@yorickpeterse:matrix.orgyorickpeterseOptimising will also be done sequentially because it needs type info, but I don't expect this to be very expensive as most optimisations will be pretty simple
15:14:42@yorickpeterse:matrix.orgyorickpeterseThen generating bytecode can be done in parallel again
6 Dec 2019
15:12:43@yorickpeterse:matrix.orgyorickpetersehttps://inko-lang.org/news/inko-progress-report-november-2019/

There are no newer messages yet.


Back to Room List