(This post is a translation of my Japanese post)
I participated to 4th Tokyo Erlang Workshop in Aoyama Oracle Center Tokyo, Japan. I had a talk about Yatce in sessions and went to the party. The organizer was cooldaemon, who did a great contribution and prepare for the workshop and the party. All people there including me appreciated very much on his contribution. Also I appreciate Oracle Japan, Inc. for it's contribution of providing its great conference room and understanding on open-source communities.
Takeru Inoue's "(maybe) useful Algorithms for distributed storage" was first and the most difficult speech. He talked about 'Sinphonia', which took best paper in SOSP'07, overcoming the Amazon's famous Dynamo paper. This algorithm is very difficult but revolutionary because it shows a method that is much faster than 2-phase commit and much consistent than Vector clocks. He also introduced BDD and ZDD. ZDD is the only algorithm found by Japanese that is booked in Knuth's "the Art of Programming".
Higepon's talk about his implementation of Skipgraph Key-value-storage was also excellent. I've been very interested in his simple design of concurrent-join in SkipGraph ring. It admits three broken status in SkipList when reading and earns read-throughput. Moreover, he had created sample application of bulletin board, whose CSS design was cool. Stay tuned on mio!
My only question was mio's design for fault-tolerance and replication (and had forgotten asking). And what he said was "Good programmers never forget automation of unit-testing," ...
My talk on Yatce and general Erlang-C bindings was like this (partially Japanese, partially English):
I have a few additional topics: Linked-in driver may be best choice because ERTS's prim_file, prim_inet (which are the backend of file I/O and net I/O) are implemented with Linked-in driver. Usually for I/O intensive tasks linked-in driver is suitable and CPU intensive tasks NIF seems suitable. It will be the style. And my talk was Ust'ed.
@sleepy_yoshi's "Badly-educated guy seems in tutorial of Erlang" was a great laughter in hard-boiled workshop (which was organized by hard-algorithm, hard-software-design, hard-implementation). Of course he is far from badly-educated.
The pardy was great time because many great hackers around Erlang and other cool technologies such as linux-kernel, linux-distribution, OCaml and Python.
Matthew gave me replies with some objections. I'm posting to my blog both because failed posting a comment to the original blog post and because it's a bit long, late and not so cool.
After all totally you're right, matthew.
I do take objection to your comment in your blog post: “It’s a good example case that not expressing nor publishing in English leads products/opinions shall be ignored, and bad practice”. The simple fact is that I was not aware of yatce, and indeed, googling for “erlang tokyo cabinet” does not return any result for yatce until the 3rd page. If I had known about yatce in advance, then I would have tried to use it in preference to writing Toke: we have absolutely no desire to reinvent the wheel unnecessarily.Yes, I meant 'ignore' as not being aware, just because I'm not so good at English. I'm sorry.
I don’t however understand your question about 16 tables. I’ve not come across limits on Erlang drivers and ports but maybe there’s something I’ve missed?No, I had a memory of some limitation, seeing crypto module is using 16 drivers for more calculation speed. But again I search the erlang documents around and found no special statement about limitation of number of linkedin drivers.
If anything, it’s slightly slower than the current code (as well as being slightly more messy). It would seem the context switch is not hurting me at all. Even for tests which I would have thought would most expose control as being faster (eg lots of gets), it’s in fact no faster at all.Yes, I was wrong. I thought too simply that context switching makes erts slower but context switching breaks some optimization (I don't know details and what it is) of Erlang runtime schedulers. They're using spinlocks...
After all totally you're right, matthew.