We’re pleased to announce the new FarmHash family of hash functions for strings. FarmHash is a successor to CityHash, and includes many of the same tricks and techniques, several of them taken from Austin Appleby’s MurmurHash.
We’re heavily influenced by the types of CPUs that are common in Google’s datacenters, but FarmHash’s goals don’t end there. We want FarmHash to be fast and easy for developers to use in phones, tablets, and PCs too. So, yes, we’ve improved on CityHash64 and CityHash32 and so on. But we’re also catering to the case where you simply want a fast, robust hash function for hash tables, and it need not be the same on every platform. To that end, we provide sample code that has one interface harboring multiple platform-specific implementations.
Over time, we plan to expand FarmHash to include hash functions for integers, tuples, and other data. For now, it provides hash functions for strings, though some of the subroutines could be adapted to other uses.
Overall, we believe that FarmHash provides high-performance solutions to some classic problems. Please give it a try! Contributions and bug reports are most welcome.
By Geoff Pike, Software Engineer
Google Code-In 2013: RTEMS project report
Thursday, March 27, 2014
Today's post comes from RTEMS, an open source Real Time Operating System that supports a variety of open standard API’s. They have participated as a Google Code-in mentoring organization for the past 7 years.
Between November and early January, the RTEMS Project participated as one of ten mentoring organizations in the Google Code-in (GCI), a contest for pre-university students that encourages the involvement of students age 13-17 in open source communities.
During the seven week time-frame for GCI, RTEMS Project had 39 students complete 265 tasks under the tutelage of 15 mentors. That is an average of over five tasks per day! Many new students to RTEMS completed the Getting Started with RTEMS task, which provided both useful feedback about new users interested in working with RTEMS and prepared the students for hands-on programming work with our systems. We are proud of the efforts and accomplishments of all the students and grateful to the Google Open Source Programs Office, our mentors, organization administrators, and the open source community that helped support them along the way.
Below are descriptions of some of the more notable accomplishments that the students achieved in each of the five task categories: Code, Documentation/Training, Outreach/Research, Quality Assurance, and User Interface.
Code
Documentation / Training
Outreach / Research
Quality Assurance
Thanks again to everyone involved in making GCI 2013 a successful one for RTEMS Project.
By Gedare Bloom, RTEMS Project Org Admin
During the seven week time-frame for GCI, RTEMS Project had 39 students complete 265 tasks under the tutelage of 15 mentors. That is an average of over five tasks per day! Many new students to RTEMS completed the Getting Started with RTEMS task, which provided both useful feedback about new users interested in working with RTEMS and prepared the students for hands-on programming work with our systems. We are proud of the efforts and accomplishments of all the students and grateful to the Google Open Source Programs Office, our mentors, organization administrators, and the open source community that helped support them along the way.
Below are descriptions of some of the more notable accomplishments that the students achieved in each of the five task categories: Code, Documentation/Training, Outreach/Research, Quality Assurance, and User Interface.
Code
- C99 “restrict” keyword added to Newlib C Library for POSIX conformance.
- Ported the Rhealstone Benchmark to RTEMS, now available in testsuites/rhealstone.
- Refactored over a dozen BSPs to conform to guidelines determined by Vipul Nayyar’s GSoC 2013 project.
- Refactored portions of the monolithic sp09 test case into new, finer-grained tests.
- Created or fixed 9 POSIX timing tests.
Documentation / Training
- Determined guidance for doxygen use in BSPs and added doxygen comments to about 40 BSPs.
- Fixed documentation in the RTEMS POSIX user manual and in multiple test cases.
Outreach / Research
- Created 2 video tutorials for Getting Started with RTEMS.
- Updated the RTEMS wiki page up to date for the first time in six years (using references from Google Scholar).
Quality Assurance
- Investigated and/or fixed over 20 bugs in the RTEMS Bugzilla.
- User Interface
- Updated the rtems-graphics-toolkit repository and fixed some bugs.
Thanks again to everyone involved in making GCI 2013 a successful one for RTEMS Project.
By Gedare Bloom, RTEMS Project Org Admin
Steel Bank Common Lisp wrap-up post: new Google Summer of Code org in 2013
Monday, March 24, 2014
Christophe Rhodes from Steel Bank Common Lisp, a high performance Common Lisp compiler, is today’s guest writer on the Google Open Source Blog. SBCL participated as a mentoring organization for the first time in Google Summer of Code 2013 and will join us again in 2014.
Google's call for organization proposals in the 2013 Summer of Code program spurred Steel Bank Common Lisp (SBCL) developers to organize their thoughts and come up project suggestions that could be reasonably achieved in the course of two to three months. The construction of the list was already a positive outcome, but SBCL being accepted into the 2013 program was a huge bonus, and allowed us to work with two students on two successful projects. Read more about them below:
Modernizing register allocation (student: Alexandra Barchunova, mentor: Paul Khuong)
Alexandra proposed to improve the register allocator in SBCL by implementing a classic algorithm known to perform well on practical C and Fortran programs. Adapting that algorithm, on top of the pre-existing register allocation infrastructure, took the better part of the summer. It also helped fix bugs and suboptimalities in related support code.
Because register allocation is such a fiddly problem, the remainder of Alexandra’s project period was spent exploring various tweaks and parameterisation for the high level iterative colouring/spilling logic described by prior research.
The new allocator has been forward-ported and cleaned up, and it can hopefully be merged in the near future. Alexandra plans to keep working on the allocator, and we hope to see the result hit official SBCL by the end of the year. Her work is at https://github.com/abarch/sbcl.
Efficient interpretation (student: Matthias Benkard, mentor: Juho Snellman)
Matthias' project was to develop an efficient interpretation scheme for SBCL, starting from strategies such as Feeley's use of closures in code generation. The idea was to develop a fast compiler from Lisp code to an internal representation while performing minimal compilation on the way, as well as an efficient interpreter of this internal representation. Matthias successfully developed these two components, and in addition, integrated this evaluation strategy into other parts of the Lisp environment.
Matthias did manage to give his mentor Juho some stress and strain — most notably by informing him, a week before the `pens-down date', that a substantially different approach was likely to have some benefits, and that he was going to go for it. Fortunately, he got there in time, and it certainly did have additional benefits! Matthias' interpreter is benchmarked as being around 10 times faster than the simple s-expression interpreter, and all is looking promising for a merge into the mainline SBCL in the near future. His code is available at https://github.com/benkard/sbcl.
It was a good summer for the SBCL team as a whole. Participation in GSoC has been a good morale boost as well as good general publicity for our organization. And there's no shortage of challenging and fun projects left to tackle. We are also very excited to have been accepted as a mentoring organization for Google Summer of Code 2014!
By Christophe Rhodes, Org Admin for SBCL
Modernizing register allocation (student: Alexandra Barchunova, mentor: Paul Khuong)
Alexandra proposed to improve the register allocator in SBCL by implementing a classic algorithm known to perform well on practical C and Fortran programs. Adapting that algorithm, on top of the pre-existing register allocation infrastructure, took the better part of the summer. It also helped fix bugs and suboptimalities in related support code.
Because register allocation is such a fiddly problem, the remainder of Alexandra’s project period was spent exploring various tweaks and parameterisation for the high level iterative colouring/spilling logic described by prior research.
The new allocator has been forward-ported and cleaned up, and it can hopefully be merged in the near future. Alexandra plans to keep working on the allocator, and we hope to see the result hit official SBCL by the end of the year. Her work is at https://github.com/abarch/sbcl.
Efficient interpretation (student: Matthias Benkard, mentor: Juho Snellman)
Matthias' project was to develop an efficient interpretation scheme for SBCL, starting from strategies such as Feeley's use of closures in code generation. The idea was to develop a fast compiler from Lisp code to an internal representation while performing minimal compilation on the way, as well as an efficient interpreter of this internal representation. Matthias successfully developed these two components, and in addition, integrated this evaluation strategy into other parts of the Lisp environment.
Matthias did manage to give his mentor Juho some stress and strain — most notably by informing him, a week before the `pens-down date', that a substantially different approach was likely to have some benefits, and that he was going to go for it. Fortunately, he got there in time, and it certainly did have additional benefits! Matthias' interpreter is benchmarked as being around 10 times faster than the simple s-expression interpreter, and all is looking promising for a merge into the mainline SBCL in the near future. His code is available at https://github.com/benkard/sbcl.
It was a good summer for the SBCL team as a whole. Participation in GSoC has been a good morale boost as well as good general publicity for our organization. And there's no shortage of challenging and fun projects left to tackle. We are also very excited to have been accepted as a mentoring organization for Google Summer of Code 2014!
By Christophe Rhodes, Org Admin for SBCL