<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Seb,</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">In your assembly code, I cannot find where the map that you packed is being unpacked. For completeness, I looked for all references to core_map_unpack in all of biosal:</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><div class="gmail_default">mininuevo:biosal gkt$ grep core_map_unpack $(find . -name '*.[hc]')</div><div class="gmail_default">./core/structures/map.c:int core_map_unpack(struct core_map *self, void *buffer)</div><div class="gmail_default">./core/structures/map.h:int core_map_unpack(struct core_map *self, void *buffer);</div><div class="gmail_default">./genomics/data/coverage_distribution.c:        core_map_unpack(&map, buffer);<br></div><div class="gmail_default">./tests/test_map.c:        core_map_unpack(&map2, buffer);</div><div class="gmail_default"><br></div><div class="gmail_default">I can always use the example in test_map.c, but I'm trying to understand how your Spate code is unpacking the coverage_distribution map (from assembly_graph_store.c, line 494). It would seemingly need to be unpacked somewhere. </div><div class="gmail_default"><br>George</div><div class="gmail_default"><br></div><div class="gmail_default"><br></div><div class="gmail_default"><br></div></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>George K. Thiruvathukal, PhD<br></div><div style="font-size:12.7272720336914px"><div style="font-size:12.7272720336914px"><i style="font-size:12.7272720336914px">Professor of Computer Science</i><span style="font-size:12.7272720336914px">, Loyola University Chicago</span><br></div><div style="font-size:12.7272720336914px"><span style="font-size:12.7272720336914px"><i>Director</i>, Center for Textual Studies and Digital Humanities</span></div><div style="font-size:12.7272720336914px"><span style="font-size:12.7272720336914px"><i>Guest Faculty</i>, Argonne National Laboratory, Math and Computer Science Division</span></div><div style="font-size:12.7272720336914px"><div style="font-size:12.7272720336914px">Editor in Chief, <a href="http://www.computer.org/portal/web/computingnow/cise" target="_blank">Computing in Science and Engineering</a> (IEEE CS/AIP)<br></div><div><span style="font-size:12.7272720336914px">(w) <a href="http://thiruvathukal.com" target="_blank">thiruvathukal.com</a> </span><span style="font-size:12.7272720336914px">(v) 773.829.4872</span><br></div><div><span style="font-size:12.7272720336914px"><br></span></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Wed, Nov 26, 2014 at 10:23 AM, Boisvert, Sebastien <span dir="ltr"><<a href="mailto:boisvert@anl.gov" target="_blank">boisvert@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> From: George K. Thiruvathukal [<a href="mailto:gkt@cs.luc.edu">gkt@cs.luc.edu</a>]<br>
</span>> Sent: Wednesday, November 26, 2014 10:11 AM<br>
<span class="">> To: Boisvert, Sebastien<br>
> Subject: Re: Causality and ACTION_STOP<br>
><br>
><br>
><br>
><br>
</span><span class="">> Hi Seb,<br>
><br>
><br>
> See below!<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> On Wed, Nov 26, 2014 at 10:03 AM, Boisvert, Sebastien<br>
> <<a href="mailto:boisvert@anl.gov">boisvert@anl.gov</a>> wrote:<br>
><br>
><br>
> > I am looking at spate_metagenome_assembler/spate.c but don't see any usage of core_map. I did see a usage of core_map in argonnite.c, but the map is not actually being sent in a message, AFAICT. :)<br>
><br>
> Spate uses the BioSAL actor library in genomics/<br>
><br>
> Check out genomics/assembly/assembly_graph_store.c line 494<br>
><br>
><br>
><br>
><br>
><br>
> ​This looks like the magic formula! I didn't look too closely at the inclusion list.<br>
><br>
><br>
<br>
</span>This is basically the same pattern used in thorium_actor_send_vector.<br>
<br>
So you can just take that as a starting point for thorium_actor_send_map.<br>
<span class=""><br>
><br>
>     new_count = core_map_pack_size(&concrete_self->coverage_distribution);<br>
>     new_buffer = thorium_actor_allocate(self, new_count);<br>
>     core_map_pack(&concrete_self->coverage_distribution, new_buffer);<br>
><br>
>     printf("SENDING %s/%d sends map to %d, %d bytes / %d entries\n",<br>
><br>
>                         thorium_actor_script_name(self),<br>
>                     thorium_actor_name(self),<br>
>                     customer, new_count,<br>
>                     (int)core_map_size(&concrete_self->coverage_distribution));<br>
><br>
>     thorium_message_init(&new_message, ACTION_PUSH_DATA, new_count, new_buffer);<br>
>     thorium_actor_send(self, customer, &new_message);<br>
><br>
><br>
>     thorium_message_destroy(&new_message);<br>
><br>
><br>
><br>
><br>
> :-) Thanks!<br>
><br>
><br>
><br>
><br>
> If we do thorium_message_destroy(), does it also free the underlying buffer?<br>
><br>
> ​<br>
><br>
<br>
</span>No.<br>
<br>
thorium_message_destroy() does not free any memory because<br>
thorium_message_init() does not allocate any memory neither.<br>
<br>
I guess this is just because I use to do more C++.<br>
<span class=""><br>
><br>
> ><br>
> ><br>
> > I'm planning to add these functions to make sending/receiving maps easy.<br>
><br>
> That a good idea. I like it.<br>
><br>
><br>
><br>
> ​Great! I will give myself this task. I'm going to end up figuring everything out as part of the new version of hello_acq.c.<br>
><br>
> I want maps primarily because I am mapping an actor name to its (boolean) status of having been greeted or not.<br>
<br>
</span>This makes sense.<br>
<br>
Also, for your information, core_map can never be full although it uses a hash table for the implementation.<br>
<br>
Here is the hierarchy:<br>
<br>
- core_set is implemented on top of core_map<br>
- core_map is implemented on top of core_dynamic_hash_table (dynamic hash table uses incremental resizing, so it can never be full and<br>
                all calls are still O(1) because of amortization.)<br>
- core_dynamic_hash_table is implemented on top of core_hash_table (hash_table uses double hashing / open addressing)<br>
- core_hash_table is implemented on top of core_hash_table_group (right now, there is 1 group per table, but this could be use to<br>
                implement a sparse container like in Google Sparse Hash Table based on Donald Knuth's algorithm for that).<br>
<span class=""><br>
><br>
> ​<br>
><br>
><br>
> > Similar to your view, I think lists and maps are among the most important collections.<br>
><br>
> There is the free_list structure, but it is only used in memory management right now.<br>
><br>
> > I once read a paper that most of the reuse in OOP comes from lists and associative structures.<br>
><br>
> When you say lists, does that include vector. Usually, vector means array and list means<br>
> linked list.<br>
><br>
><br>
><br>
> ​Yes, it does in an evolutionary sense. I tend to think of vector and lists as being connected. In modern programming libraries, you often see the interfaces conflated (i.e. lists have array-like interfaces and vice versa). Java Vector is kind of an interesting<br>
>  case study!<br>
<br>
</span>But a Java ArrayList<Integer> has O(1) random access but can trigger a resize of capacity on insertion which is O(n).<br>
<br>
A Java LinkedList<Integer> has O(n) random access but has O(1) insertion.<br>
<br>
Sure, both implement the List<Integer> interface, but each has a better use case anyway.<br>
<br>
<br>
><br>
><br>
> ​TTYL,<br>
> George<br>
><br>
><br>
><br>
</blockquote></div><br></div>