| paulsherwood | is 'callback' a very well understood term? my only experience of it is callback-hell and callback-spaghetti when investigating other folks' asynchronous code | 07:43 |
|---|---|---|
| jmacs | Yes | 07:43 |
| paulsherwood | great. so in a non-asynchronous situation (say a single-threaded batch program) why would one consider using callbacks? | 07:44 |
| jmacs | One example is when you need to supply a method to a function rather than data | 07:45 |
| jmacs | Such as a sorting function where you need to pass in a method to compare the elements in your array | 07:45 |
| paulsherwood | ah, ok | 07:45 |
| jmacs | In a single threaded situation I can't think of any other reason. | 07:46 |
| paulsherwood | but in that case, for clarity, could/should i call the parameter 'comparison_callback' rather than 'comparison_method'? | 07:46 |
| jmacs | Personally I would find both of those equally understandable | 07:47 |
| paulsherwood | your example does help for the code i'm looking at... i think that's what the author is doing. but given i didn't grok 'callback' i was mystified what the purpose of the param was | 07:47 |
| paulsherwood | thanks jmacs - that's helped a lot | 07:47 |
| ratmice___ | yeah, I don't think there is any synchronous/asynchronous specificity to the term callback, in general it just means that the caller understands what needs to happen, while the called function specifies the API through which the caller can make it so | 07:48 |
| ratmice___ | e.g. the term is used regularly in unthreaded C, which is synchronous | 07:49 |
| paulsherwood | i get that now, thanks. in the example jmacs described i think i'd favour just calling the param 'comparison' rather than 'comparision_callback' though... | 07:49 |
| paulsherwood | otherwise it seems like drifting towards 'today_date' and 'flag_bool' and 'username_string' ? :) | 07:50 |
| ratmice___ | i like comparator | 07:51 |
| paulsherwood | even better :-) | 07:51 |
| ratmice___ | though often called 'ord' | 07:51 |
| paulsherwood | really? is that a common name? | 07:52 |
| jmacs | qsort just calls it "compar"; I would probably pay for the extra byte and say "compare" though. | 07:52 |
| paulsherwood | heh | 07:52 |
| ratmice___ | in some circles :), short for 'order' | 07:52 |
| paulsherwood | circles where every byte counted, once, and old habits die hard? :-) | 07:52 |
| ratmice___ | even i'm not interested enough in computational entymology to know the answer :) | 07:55 |
| paulsherwood | ack :) | 07:57 |
| ratmice___ | but even python seems to have it, https://docs.python.org/2/library/functions.html#ord | 07:58 |
| ratmice___ | in general, I think 'ord', is just a different perspective, rather than being a function you pass in to sorting, its an attribute of the objects passed in | 07:59 |
| paulsherwood | trying to build master definitions on an aws machine... broken at stage1-gcc - any idea what's going on here? http://sprunge.us/VQPc | 09:26 |
| paulsherwood | ah... c++ compiler missing or inoperational :/ | 09:31 |
| paulsherwood | 15-07-18 10:14:48 [2/240/240] [stage1-gcc] Elapsed time for build 00:01:35 | 10:15 |
| radiofree | That's fast! | 11:41 |
| paulsherwood | 15-07-18 11:43:19 [239/240/240] [TOTAL] Elapsed time 01:26:37(build-system-86_64) | 11:44 |
| paulsherwood | that's on AWS m4.10xlarge | 11:45 |
| radiofree | can we use that for mason? | 11:46 |
| paulsherwood | http://sprunge.us/HYGf | 11:47 |
| paulsherwood | it's not cheap :) | 11:47 |
| radiofree | is "15-07-18 10:39:17 [24/240/240] [gcc] Elapsed time for assembly 00:05:40" the build time + artifact creation time? | 11:49 |
| paulsherwood | yes in general but may include creating some dependencies, and includes time to clean up staging area | 11:50 |
| paulsherwood | there's a separate line for artifact creation time | 11:51 |
| radiofree | 3 minutes to build gcc! | 11:51 |
| paulsherwood | but it's not as fast as i hoped... this is max-jobs 60 on a 40 core system | 11:53 |
| radiofree | 3 minutes for gcc is pretty damn fast! | 11:55 |
| paulsherwood | yes, ok :) | 11:57 |
| paulsherwood | i'm now running a herd of 6 ybd max-jobs 10, to see if my pseudo distbuild actually has any merit | 11:58 |
| radiofree | then try building a QT system! | 12:02 |
| paulsherwood | ok will do | 12:02 |
| paulsherwood | (assuming the one in master actually builds) | 12:02 |
| * radiofree is reminded that we need to upgrade to qt 5.5 | 12:04 | |
| paulsherwood | 5 15-07-18 12:54:22 [72/240/240] [TOTAL] Elapsed time 01:04:29 | 12:55 |
| paulsherwood | counter is wrong, but the herd did it in 75% of the time :) | 12:56 |
| paulsherwood | http://sprunge.us/MjQX | 12:57 |
| persia | A herd of 6 did it in 75% of the time of a single build? | 13:24 |
| persia | What happens if you build something further from the base, where we might expect more parallelism to be extracted? | 13:24 |
| * paulsherwood curses that he deleted the artifacts | 13:25 | |
| persia | That's actually useful for this sort of testing. | 13:25 |
| persia | The part that I don't understand is whether there is *expected* parallelism in the given build artifacts. | 13:25 |
| paulsherwood | 6 instances max-jobs 10 completed in 75% of the time of 1 instance max-jobs 60 | 13:25 |
| persia | For build-essential, I expect almost no parallelism. | 13:26 |
| paulsherwood | yup | 13:26 |
| paulsherwood | there's no 'algorithm' here... all the herd instances build build-essential | 13:26 |
| paulsherwood | that could be improved by some locking, but at the cost of increased complexity | 13:27 |
| persia | Sure, but I don't care about the statistics if the thing being built contains almost no parallelism. | 13:27 |
| persia | If the end artifact has many leaves, then it becomes interesting. | 13:27 |
| paulsherwood | yup. i'm wondering if it's worth kicking off a build as soon as the cache-key is calculated, rather than waiting til they're all done... | 13:30 |
| persia | Could you expand that a little? | 13:30 |
| paulsherwood | this may be a speedup for new users at least, where up to an hour can be spent downloading git repos | 13:30 |
| persia | Probably better to allow some configuration. | 13:31 |
| persia | In some environments, it takes minutes to download and hours to build. In other environments, the converse is true. | 13:31 |
| persia | Or, if you have a way to stop jobs, you could have the download and build race. | 13:32 |
| persia | Although such a race would crush performance of IO-limited hardware. | 13:32 |
| paulsherwood | ack | 13:32 |
| * persia wonders if there is a way to estimate build time in a given environment | 13:33 | |
| paulsherwood | before running? some grepping of previous logs could provide a heuristic | 13:34 |
| persia | Since we can estimate download time based on size and the first few seconds of download speed, it might be interesting to have heuristics to determine whether it is better to download or to build. | 13:34 |
| persia | Since the build time depends on the processor speed, processor width, number of processors, IO speeds, etc. for *each* different source, I wonder what sort of data we'd need. | 13:35 |
| persia | Attempting to grep old logs strikes me as fragile. | 13:35 |
| persia | Especially if those logs were not from the identical environment (including factors like moving a laptop between different network access points) | 13:36 |
| paulsherwood | yup | 13:36 |
| paulsherwood | do we have any statistics for elapsed time saved using distbuild networks vs single machines? | 13:44 |
| persia | There's no such thing. | 13:51 |
| persia | It entirely depends on whether the task can be parallelised, and whether that parallelism is larger than can be done on a single machine. | 13:51 |
| ratmice___ | I suppose you could use something like avahi for moving between networks, but seems a bit excessive? | 13:53 |
| ratmice___ | anyhow, i've had some interest in adaptive scheduling as well | 13:55 |
| * paulsherwood is ashamed to admit he doesn't know what 'adaptive scheduling' is | 13:57 | |
| persia | ratmice___: For me, the interesting question is about elasticity: given software-defined infrastructure, how should workloads be deployed to reduce bottlenecks, and how does this answer change depending on the infrastructure in question. | 13:59 |
| ratmice___ | in general I think we can do a much better job with whole system build graphs, because e.g. for everything but generated headers you could in theory compile to .o files in parallel for every .o on the system, and just wait on the (unparallelizable linker) to complete | 14:00 |
| ratmice___ | paulsherwood: e.g. avoiding scheduling memory hungry compilations together | 14:01 |
| paulsherwood | ah, ok. | 14:02 |
| ratmice___ | I don't think we're going to get very far down this rabbit hole with make unfortunately :( | 14:03 |
| paulsherwood | this requires that a worker has some knowledge of what other workers are doing, or of available/unloaded system capacity | 14:03 |
| paulsherwood | ratmice___: replacing make is maybe a bit beyond our scope at this point, though? :) | 14:04 |
| ratmice___ | *nod* :) | 14:04 |
| paulsherwood | maybe later... :-) | 14:04 |
| persia | Part of the issue is the computational cost of building build graphs. One interesting aspect of ybd is that it doesn't even try. | 14:05 |
| paulsherwood | disappointingly one of this herd has failed to build glibc... http://sprunge.us/YbVS | 14:05 |
| persia | As it turns out, this works for some things, and doesn't work for others (and I don't think we know why yet). | 14:05 |
| ratmice___ | the problem though is starting to become more apparent, e.g. ./configure for many project represents a large portion of compile time | 14:06 |
| paulsherwood | true. and a surprising amount of time is being spent (at least on my machine) in clearing staging areas and creating artifacts | 14:06 |
| persia | How are the staging areas being cleared? An unlink operation should be fairly lightweight. | 14:07 |
| paulsherwood | shutil.remov | 14:07 |
| paulsherwood | is that unnecessary? can it just unlink? | 14:08 |
| paulsherwood | https://github.com/devcurmudgeon/ybd/blob/master/sandbox.py#L73 | 14:08 |
| persia | It depends on how careful you want to be. | 14:11 |
| persia | Obviously, it depends on your implementation, but the docs I find for shutil.rmtree() indicate that it deletes each file in turn, then deleting directories if they are empty, until the tree is gone. | 14:12 |
| paulsherwood | ideally i'd have a background task that deletes staging areas as their owners release them | 14:12 |
| persia | Just unlinking the top-level directory would be faster, but provide the filesystem less guidance on what is happening. | 14:12 |
| paulsherwood | could this result in the filesystem failing to release the space properly? | 14:13 |
| persia | Depends on the filesystem. | 14:13 |
| paulsherwood | ext4, btrfs? | 14:13 |
| persia | More importantly, for filesystems that do release things correctly in that circumstance, that often happens as a background gc job, so the impact on other operations is less clear. | 14:14 |
| paulsherwood | ok | 14:14 |
| persia | I only know that it depends on the filesystem. I don't know for specific filesystems. I think ext4 marks it as deleted in the journal, but doesn't actually clean up until the journal is resolved. I believe btrfs has a background gc, but I could be wrong in both cases. | 14:15 |
| paulsherwood | i think i'll leave it as-is for now, then | 14:15 |
| * paulsherwood decides that the counter is not wrong, for herds. it's useful info to know how many actual builds each worker did | 15:04 | |
| paulsherwood | so, i've tried creating a build-system-x86_64, from a cache where base-system-x86_64 artifacts are present | 15:09 |
| paulsherwood | single instance, max-jobs 60 http://sprunge.us/FPfJ | 15:10 |
| paulsherwood | 00:19:33 | 15:10 |
| paulsherwood | 6 instances, max-jobs 10 http://sprunge.us/RGgH | 15:11 |
| paulsherwood | 00:08:36 | 15:11 |
| * paulsherwood notices http://users.tinyonline.co.uk/gswithenbank/collnoun.htm | 15:24 | |
| paulsherwood | maybe gang would be a better metaphor than herd | 15:25 |
| ratmice___ | hah, a congress of baboons, seems apt | 15:27 |
| paulsherwood | actually... i notice that baboon 5 was the one that actually finished the build 5 15-07-18 14:42:16 [26/135/240] [TOTAL] Elapsed time 00:07:08 | 15:29 |
| paulsherwood | it took another minute and a half for the others to realize they'd missed the boat :-) | 15:30 |
| persia | The increased difference in speed for creating more leafy things makes sense, and is nice to see. Promising for being a means to increase the number of different systems being built simultaneously for candidate testing. | 15:40 |
| paulsherwood | i think so too :) | 15:40 |
| paulsherwood | it's possible to see how much racing/duplication of effort is going on by grepping the logs for 'Bah' | 15:41 |
| paulsherwood | i'm pretty sure there'll be some trick to reduce the racing | 15:43 |
| paulsherwood | fribidi fails to build http://sprunge.us/CPNA | 15:46 |
| *** zoli__ has joined #baserock | 17:23 | |
| *** zoli__ has quit IRC | 17:32 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!