2014年9月21日日曜日

My talk at RubyKaigi 2014 - Diversity and Rails Girls

I gave a talk at RubyKaigi 2014: "Rails Girls: Not Only for Girls".

Female engineers account around 20% at tech companies in the US, but tech companies in Japan have only 10% from my past experiences.

As in my slides, this situation ties tightly to our culture and society, and cannot be changed in a day. We need to work both in short-term and long-term ways, like equality in hiring and bringing more teenagers to tech fields.

There are a lot of activities in various ways, and Rails Girls is one of them.

There are links to such activities at the Women Techmakers website by Google. Academic societies also working in this area, like ACM-W and IEEE Women in Engineering. I encourage you to take a look at these.

RubyKaigi 2014 was a great success, without any gender issues unlike last year. Kudos to all volunteers, speakers and attendees!

2014年3月17日月曜日

"What makes AWS invincible?" from JAWS Days 2014

I gave a presentation at JAWS Days 2014 and talked with a title of "What makes AWS invincible?"

A moderator of the session, @con_mame told me to speak about anything which might be missing from AWS or any suggestions to the service. I was afraid of speaking of "existing" features as they are adding a lot of features so often and I don't know all of them. It turned out that the topics I chose were accepted by the audience including a few AWS employees.

I talked about two things: "Latency" and "Test". Higher latency is always an issue of cloud computing and virtualized environment. It is always higher than non-virtual environment by nature. I am suggesting to give "hints" to AWS when launching EC2 instances. According to an AWS employee, if you run c3 instances with placement groups enabled, you will get much lower latency. I'd like to check this later.

"Test". The web console of AWS is very useful and has a lot of features, however it is against the philosophy of "Infrastructure as Code." You cannot reuse or review your changes with it. Many users of course try to automate things by using SDKs or a CLI interface, but something "easier to use" would be great. "Record and play" with the web console will be a great way to achieve this, isn't it?

Here is my slide at the presentation.

See also

2013年8月22日木曜日

/etc/hosts slows down as entries grow up

Everyone uses /etc/hosts to manage names of several servers. It doesn't involve DNS look-ups and doesn't have a single-point-of-failure. It becomes, however, not only very difficult to deploy new files on each server but very slow to look-up a host as the number of entries increases.

Here are some benchmark results comparing /etc/hosts and dnsmasq.

Environment:
  • OS: CentOS 6.4 64bit, Linux 3.10.2
  • CPU: Intel Core i7-2600 @ 3.4GHz
The tests were performed a simple name-looking program. /etc/hosts file was filled with random entries like

10.234.130.1 host1301
10.234.130.2 host1302
10.234.130.3 host1303

and two entries for localhost in IPv4 and IPv6.

Dnsmasq was deployed with the same file on the same host.

The following table and graph show elapsed times in seconds, per 100,000 queries:


#hostshostsdnsmasq
21.5164.8068
1022.65984.9224
2524.44744.9286
100213.23764.831


As the number of entries increases, looking an entry in /etc/hosts takes longer linearly. With more than 250 entries, dnsmasq is faster with the testing environment. If a host doesn't exist in /etc/hosts, it takes more time in addition to processing /etc/hosts.

This happens because /etc/hosts is processes by a userland library(libc) and it searches linearly using fopen(3) every time. Many cache servers including dnsmasq use hash tables for quick searches.

Each request takes only 0.05 microseconds for dnsmasq, and 0.14 microseconds even with 1,000 entries in hosts file. But it is worth remembering that sometimes DNS look-ups are faster than hosts file.

This test was performed with the following program:


2013年3月26日火曜日

Congrats, graduates from University of Tsukuba!

Congratulations, graduates from University of Tsukuba!
It was three years ago when I finished my master's course and started working. I moved to my current company 10 months ago. I am still learning a lot, yet far from "excellence."
Some of you may have found a job you've been looking for. Some may start working at a position which you don't believe the best. But anyway, keep on going. You will find the way to make your dream come true.

I will do my best as well :)

(This article is from Facebook)

2012年3月27日火曜日

Ackermann function and optimization

Have you heard of the Ackermann function?

This function is simple, but if you try to calculate it naively, soon the computational cost increases and it will never ends.

I've written the function naively, in x86 assembly language to demonstrate some optimization techniques. I could calculate up to ack(3, 11) and the stack overflowed beyond that point.

Optimizations

  • Use JMP instead of CALL for tail recursions
  • Use TEST + JE for macro fusion
  • Use ADD / SUB instead of INC / DEC to eliminate false dependency in flag register
  • Use MOV EDX, 1 instead of MOV EDX, 1 to reduce code size
    .code

ack PROC public

    ; RCX = m, RDX = n
    TEST    RCX, RCX
    JE      m_zero

    TEST    RDX, RDX
    JE      n_zero

    PUSH    RCX
    SUB     RDX, 1
    CALL    ack
    POP     RCX
    SUB     RCX, 1
    MOV     RDX, RAX
    JMP     ack

n_zero:
    MOV     EDX, 1
    SUB     RCX, 1
    JMP     ack

m_zero:
    MOV     RAX, RDX
    ADD     RAX, 1
    RET

    ack ENDP

factorial PROC public
    
    MOV     EAX, 1
    CMP     RCX, 1
    JLE     f_ret

f_loop:
    IMUL    RAX, RCX
    SUB     RCX, 1
    CMP     RCX, 1
    JNLE    f_loop

f_ret:

    RET

    factorial ENDP

    END

This program was faster than the C version below by 30%(C version was compiled with Visual C++ 2010 with /O2 option), on a Core 2 Duo processor. The factorial function was almost as fast as the C version.

int64_t factorial_c(int64_t n)
{
    int64_t r = 1;
    while(n > 1) r *= n--;
    return r;
}

int64_t ack_c(int64_t m, int64_t n)
{
    return m == 0 ? n + 1 : n == 0 ? ack_c(m - 1, 1) : ack_c(m - 1, ack_c(m, n - 1));
}

2012年3月26日月曜日

MySQL Backup Script

MySQL is one of the most popular RDBMS in the world, however, there is no out-of-box backup method. mysqldump is not sufficient when we mix InnoDB and MyISAM in one scheme.

I have written a PowerShell script to backup tables from MySQL databases, using either --single-transaction for InnoDB and --lock-tables for MyISAM tables.

Run the script from shell and you will get backup-DBNAME.sql files in your current directory for each database. This script will use table locks for MyISAM tables and transactions for InnoDB tables. Note if you are using READ-COMMITTED isolation level, backups might not be consistent between transactions. This should not matter when you are using READ-COMMITTED.

In the following example, MediaWiki is read with a table lock because it has one MyISAM table for indexing while the others are InnoDB.

I'm using this script to dump my database everyday and zipping them to store for a week. If you want to perform differential or incremental backups, you need to make use of binary logging feature of MySQL.

The following script is public-domain.

$innodb_dbs = @("bamboo","confluence","crowd","jira")
$myisam_dbs = @("mediawiki")
$backup_user = "backup"
$backup_password = "password"
$mysqldump = "C:\Program Files\MySQL\MySQL Server 5.5\bin\mysqldump.exe"
$password_option = "–password=" + $backup_password
foreach($db in $innodb_dbs){
&"$mysqldump" -u $backup_user $password_option –quick –opt –single-transaction $db > backup-$db.sql
}
foreach($db in $myisam_dbs){
&"$mysqldump" -u $backup_user $password_option –quick –opt –lock-tables $db > backup-$db.sql
}
&"$mysqldump" -u $backup_user $password_option –quick –opt –lock-tables –flush-privileges mysql > backup-mysql.sql

2012年3月15日木曜日

My new blog!

I'm starting a blog to share my interests.

Primary topics will be computers, programming, networking, and transport.

I live in Yokohama, Japan so I will also want to share things in Japan.