Инструментарий от Google

0

0

Google разместила исходные коды 4 инструментов: gflags, perftools, sparsehash и ctemplate на Google Code.

gflags: модуль на С++ для опций/флагов, задаваемых в командной строке. Появилась как замена для getopt(), как более простая и мощная альтернатива. Имеются реализации на C++ и Python.
Документация: http://google-gflags.googlecode.com/s...

perftools: быстрая и мультипоточная реализация malloc() и набор инструментов для анализа производительности. По словам разработчиков, это самый быстрый malloc(), который они когда-либо видели. Помимо реализации malloc(), perftools также содержит Heap Checker, Heap Profiler, и CPU Profiler.
http://code.google.com/p/google-perft...

sparsehash: крайне эффективная (в плане потребления памяти) реализация hash_map, включает несколько реализаций hash_map.
http://google-sparsehash.googlecode.c...

ctemplate: простой, но мощный язык шаблонов для С++.
http://google-ctemplate.googlecode.co...

>>> Подробности

Ссылка

←

KBforge

Dia 0.96

→

Сейчас посмотрю на perftools, заинтриговало.

~~eveel~~ ★★
(27.03.07 13:37:05 MSD)

Круто, пошёл смотреть...=)

pento ★★★★★
(27.03.07 13:47:21 MSD)

Ссылка

Ответ на: комментарий от eveel 27.03.07 13:37:05 MSD

Для того, чтобы использовать гугловский malloc() в своих прогах, достаточно слинковать программу с библиотекой tcmalloc. На своих программах пока всё это дело не проверял, но make check выдал следующее:

~~eveel~~ ★★
(27.03.07 13:48:31 MSD)

Ответ на: комментарий от eveel 27.03.07 13:48:31 MSD

Угу. Я разделил на ноль. O SHI...

anonymous
(27.03.07 13:49:57 MSD)

Ссылка

Ответ на: комментарий от eveel 27.03.07 13:48:31 MSD

$ sudo make check
make  heap-profiler_unittest_sh heap_checker_unittest_sh heap-checker-death_unittest profiler_unittest_sh pprof_unittest
make[1]: Entering directory `/usr/src/google-perftools-0.8'
./src/tests/heap-profiler_unittest.sh . ./src
HeapProfiler: Dumping heap profile to /tmp/heap_profile_info/test.0001.heap (0 MB in use)
HeapProfiler: Dumping heap profile to /tmp/heap_profile_info/test.0002.heap (0 MB in use)
HeapProfiler: Dumping heap profile to /tmp/heap_profile_info/test.0003.heap (0 MB in use)
HeapProfiler: Dumping heap profile to /tmp/heap_profile_info/test.0004.heap (0 MB in use)
...
HeapProfiler: Dumping heap profile to /tmp/heap_profile_info/test.0758.heap (37 MB in use)
HeapProfiler: Dumping heap profile to /tmp/heap_profile_info/test.0759.heap (37 MB in use)
HeapProfiler: Dumping heap profile to /tmp/heap_profile_info/test.0760.heap (38 MB in use)
HeapProfiler: Dumping heap profile to /tmp/heap_profile_info/test_13849.0001.heap (0 MB in use)
HeapProfiler: Dumping heap profile to /tmp/heap_profile_info/test_13849.0002.heap (0 MB in use)
HeapProfiler: Dumping heap profile to /tmp/heap_profile_info/test_13849.0003.heap (0 MB in use)
...
HeapProfiler: Dumping heap profile to /tmp/heap_profile_info/test_13849.0760.heap (38 MB in use)
HeapProfiler: Dumping heap profile to /tmp/heap_profile_info/test_13849.0761.heap (Exiting)
HeapProfiler: Dumping heap profile to /tmp/heap_profile_info/test.0761.heap (Exiting)

>>> Test failed for Allocate: didn't use 90% of cpu


>>> Test failed for Allocate: didn't use 90% of cpu

Tests finished with 2 failures
make[1]: *** [heap-profiler_unittest_sh] Ошибка 2
make[1]: Leaving directory `/usr/src/google-perftools-0.8'
make: *** [check-am] Ошибка 2

~~eveel~~ ★★
(27.03.07 13:50:16 MSD)

Ссылка

Имхо самое важное забыли упомянуть в новости. Под какой лицензией код?

Alan_Steel ★★
(27.03.07 13:54:01 MSD)

Что вообще значит открыла я вообще google-perfrools уже как год пользуюсь их никто и не закрывал вроде.

to аффтор : внимательнее пишите новости

anonymous
(27.03.07 13:56:48 MSD)

Ответ на: комментарий от Alan_Steel 27.03.07 13:54:01 MSD

Не оно? http://google-gflags.googlecode.com/svn/trunk/COPYING

YesSSS ★★★
(27.03.07 13:56:49 MSD)

Ссылка

Ответ на: комментарий от Alan_Steel 27.03.07 13:54:01 MSD

>Имхо самое важное забыли упомянуть в новости. Под какой лицензией код?

BSD (New BSD License)

dotcoder ★★★★★
(27.03.07 13:57:18 MSD) автор топика

Ссылка

рулез. заценю.

~~wieker~~ ★★
(27.03.07 13:58:54 MSD)

Ссылка

Как там насчет фрагментации кучи у этого гугловского аллокатора?

Relan ★★★★★
(27.03.07 14:01:41 MSD)

Ответ на: комментарий от anonymous 27.03.07 13:56:48 MSD

>Что вообще значит открыла я вообще google-perfrools уже как год пользуюсь их никто и не закрывал вроде.

>to аффтор : внимательнее пишите новости

Да, моя ошибка: скоро должны поменять текст новости.

dotcoder ★★★★★
(27.03.07 14:03:05 MSD) автор топика

Ссылка

--- cut ---
using std::string;

class FlagValue {
 public:
  FlagValue(void* valbuf, const char* type);
  ~FlagValue();

  bool ParseFrom(const char* spec);
  string ToString() const;
--- cut ---

мнда... действительно, осчастливили общество, спору нет... :-/

// wbr

~~klalafuda~~ ★☆☆
(27.03.07 14:13:24 MSD)

Ссылка

Ответ на: комментарий от Relan 27.03.07 14:01:41 MSD

> Как там насчет фрагментации кучи у этого гугловского аллокатора?

Если всё хорошо, тока к ФФ не помешало бы прикрутить ;-)

Bohtvaroh ★★★★
(27.03.07 14:46:18 MSD)

Про sparsehash -гармошка, уже давно открыты

pustota1
(27.03.07 14:50:52 MSD)

Ссылка

Ответ на: комментарий от Relan 27.03.07 14:01:41 MSD

>Как там насчет фрагментации кучи у этого гугловского аллокатора?

бугога! могу сказать на 100% что он НЕ ФРАГМЕНТИРУЕТ ни память ни адресное пространство. тому кто фрагментирует может помочь только сало в башке или дефрагментатор хипа если отсутствует первого.

aydef ★
(27.03.07 15:12:38 MSD)

Ссылка

Расскажите, что я делаю неправильно:
pell@<hostname>:~/tmp> svn export http://google-gflags.googlecode.com/svn/trunk
svn: REPORT request failed on '/svn/!svn/vcc/default'
svn: REPORT of '/svn/!svn/vcc/default': 400 Bad Request (http://google-gflags.googlecode.com)
pell@<hostname>:~/tmp> svn export svn://google-gflags.googlecode.com/svn/trunk
svn: Can't connect to host 'google-gflags.googlecode.com': Время ожидания соединения истекло

pell
(27.03.07 15:19:41 MSD)

malloc() многопоточный

shahid ★★★★★
(27.03.07 15:25:58 MSD)

ктонибудь tcmalloc на ембеде пробовал?

anonymous
(27.03.07 15:46:21 MSD)

Ссылка

Ответ на: комментарий от Bohtvaroh 27.03.07 14:46:18 MSD

>Если всё хорошо, тока к ФФ не помешало бы прикрутить ;-)

работает: LD_PRELOAD='/usr/local/lib/libtcmalloc.so:/lib/libpthread.so.0' firefox

pmap: .... b7e9b000 124K r-x-- /usr/local/lib/libtcmalloc.so.0.0.0 b7eba000 4K rw--- /usr/local/lib/libtcmalloc.so.0.0.0 ....

anonymous
(27.03.07 15:55:57 MSD)

Ответ на: комментарий от anonymous 27.03.07 15:55:57 MSD

>работает: LD_PRELOAD='/usr/local/lib/libtcmalloc.so:/lib/libpthread.so.0' firefox

А жрет меньше?

anonymous
(27.03.07 16:05:31 MSD)

Over the past two years, Google has released several infrastructure tools as open source software.

Today we're pleased to host them on Google Code project hosting.

anonymous
(27.03.07 16:09:19 MSD)

Ссылка

Ответ на: комментарий от shahid 27.03.07 15:25:58 MSD

>malloc() многопоточный

glibc'шный? Его free() работает с глобальным локом, так что это хотя и многопоточный вариант, но далеко не самый оптимальный.

>shahid (*) (27.03.2007 15:25:58)

rtc ★★
(27.03.07 16:10:41 MSD)

Ответ на: комментарий от anonymous 27.03.07 16:05:31 MSD

>работает: LD_PRELOAD='/usr/local/lib/libtcmalloc.so:/lib/libpthread.so.0' firefox

>А жрет меньше?

С этим экспериментировать ломает, а вот память, после закрытия табов, похоже не освобождает. Или я что то не так делаю.

anonymous
(27.03.07 16:16:27 MSD)

Ответ на: комментарий от anonymous 27.03.07 16:16:27 MSD

> С этим экспериментировать ломает, а вот память, после закрытия табов, похоже не освобождает. Или я что то не так делаю.

у меня тоже не освобождает. Хотя сам firefox вроде побыстрее с этим аллокатором работает. Но все равно, раз в неделю firefox закрывается и открывается вновь, как и прежде.

anonymous-III
(27.03.07 16:31:18 MSD)

Ответ на: комментарий от anonymous-III 27.03.07 16:31:18 MSD

>у меня тоже не освобождает. Хотя сам firefox вроде побыстрее с этим аллокатором работает. Но все равно, раз в неделю firefox закрывается и открывается вновь, как и прежде.

вот с этим у меня действительно быстрее работает: http://www.hoard.org/, заметно невооруженным взглядом.

anonymous
(27.03.07 16:40:08 MSD)

Ответ на: комментарий от anonymous 27.03.07 16:40:08 MSD

спасибо, попробую... а как он на унипроцессорах себя ведет?

anonymous-III
(27.03.07 16:59:27 MSD)

Ссылка

Ответ на: комментарий от anonymous 27.03.07 16:40:08 MSD

> вот с этим у меня действительно быстрее работает: http://www.hoard.org/, заметно невооруженным взглядом.

Видимо у меня совсем плохое зрение, но ускорения я не заметил:

# pmap 8515 | grep hoard
b7e95000 80K r-x-- /home/andrey/00000000/Programming/Libs/libhoard.so
b7ea9000 4K rw--- /home/andrey/00000000/Programming/Libs/libhoard.so

andreyu ★★★★★
(27.03.07 17:03:53 MSD)

Ссылка

Ответ на: комментарий от pell 27.03.07 15:19:41 MSD

> pell@<hostname>:~/tmp> svn export > http://google-gflags.googlecode.com/svn/trunk

> svn: REPORT request failed on '/svn/!svn/vcc/default'

Столкнулся с той же проблемой. Оказалось, причина в squid`е. Он не понимает WebDav запросы и не пропускает их.

Теперь надо думать, каким бы образом оставить работать принудительное проксирование, при этом пропустив WebDav запросы...

RoGer ★
(27.03.07 17:51:40 MSD)

Ответ на: комментарий от anonymous 27.03.07 16:16:27 MSD

> С этим экспериментировать ломает, а вот память, после закрытия табов, похоже не освобождает.

И не должен освобождать, в общем случае.

Firefox и mozilla работают с tcmalloc заметно быстрее, чем c ptmalloc (glibc) и openbsd-malloc. По скорости выпадения меню особенно заметно. У меня старая машина, поэтому разница заметна невооруженным глазом.

anonymous
(27.03.07 17:54:03 MSD)

Ссылка

Ждём ебилдов =))))

helicopter
(27.03.07 18:03:46 MSD)

Ссылка

Кажется, что Firefox и Thunderbird стали работать шустрее...

~~eveel~~ ★★
(27.03.07 18:14:52 MSD)

Ссылка

Когда уже исходники поисковика-то выложат? :)

eXtractor
(27.03.07 18:24:48 MSD)

Ответ на: комментарий от eXtractor 27.03.07 18:24:48 MSD

> Когда уже исходники поисковика-то выложат? :)

Заходишь оперой на www.google.com, жмёшь правой кнопкой мыши по пустому месту, и выбираешь: Source (Ctrl+F3).

Вуаля, вот тебе и исходники =)

~~eveel~~ ★★
(27.03.07 18:33:22 MSD)

Ссылка

Ответ на: комментарий от RoGer 27.03.07 17:51:40 MSD

> Столкнулся с той же проблемой. Оказалось, причина в squid`е. Он не понимает WebDav запросы и не пропускает их.

Извиняюсь за неверную информацию. Работает он и прекрасно все пропускает: http://subversion.tigris.org/faq.html#proxy

Так что вечером надо будет опробовать это.

RoGer ★
(27.03.07 18:46:15 MSD)

Ответ на: комментарий от RoGer 27.03.07 17:51:40 MSD

Спасибо за помощь. Буду думать дальше:)

pell
(27.03.07 18:59:35 MSD)

Ссылка

Ответ на: комментарий от RoGer 27.03.07 18:46:15 MSD

Читал, ничего не понял. Пошел читать svnbook, вдруг пойму:)

P.S. Я правильно понимаю, что без переконфигурации proxy (через который я хожу) все равно svn может не заработать?

pell
(27.03.07 19:03:13 MSD)

Ответ на: комментарий от pell 27.03.07 19:03:13 MSD

а попробуй svn через https гонять, мне помогало.

anonymous
(27.03.07 19:33:46 MSD)

Ответ на: комментарий от anonymous 27.03.07 15:55:57 MSD

>>Если всё хорошо, тока к ФФ не помешало бы прикрутить ;-)

>работает: >LD_PRELOAD='/usr/local/lib/libtcmalloc.so:/lib/libpthread.so.0' firefox

Вахъ! Реально быстрее =)

Bohtvaroh ★★★★
(27.03.07 20:40:44 MSD)

c++.... фуууу.... я лучше питон возьму....

DemonZLa ★
(27.03.07 21:31:23 MSD)

Ссылка

Ответ на: комментарий от rtc 27.03.07 16:10:41 MSD

>>malloc() многопоточный

>glibc'шный?

Я имел в виду гугловский, просто наверное не точно выразился. Хотел просто узнать, хорошо это или плохо. И как это сказывается на юнипроцессорных архитектурах?

shahid ★★★★★
(27.03.07 21:44:23 MSD)

Ответ на: комментарий от Bohtvaroh 27.03.07 20:40:44 MSD

> Вахъ! Реально быстрее =)

Кучи не сокращает, однако.

anonymous
(27.03.07 21:44:50 MSD)

Ссылка

Ответ на: комментарий от shahid 27.03.07 21:44:23 MSD

>Я имел в виду гугловский, просто наверное не точно выразился. Хотел просто узнать, хорошо это или плохо. И как это сказывается на юнипроцессорных архитектурах?

Google утверждает, что у них даже с одним потоком скорость malloc() в 2 раза выше при выделении памяти в районе 1 кб. Используют продвинутое кэширование в отличии от glibc malloc().

Но при малом объем оперативной памяти производительность должна быть хуже, т.к. google malloc() не возвращает закешированную память в систему, а следовательно система будет сильнее свопиться.

rtc ★★
(27.03.07 22:07:52 MSD)

Ответ на: комментарий от anonymous 27.03.07 19:33:46 MSD

> а попробуй svn через https гонять, мне помогало.

Помогло бы, но не в данном случае. Анонимный доступ открыт по http, а https для разработчиков и требуется авторизация.

RoGer ★
(27.03.07 22:21:36 MSD)

О ctemplate

Некоторое время назад писал (вместе с коллегой) аналогичную систему. Отличия носят идеологический характер:

+ Автогенерация C++ кода (заместо шаблонов) + Каждый такой шаблон в в runtime`e становится классом. У него есть set-теры для каждого поля. + Ошибки проверяются в процессе компиляции(!) + Было прикручено к VC7, выдавало список ошибок в его Output. Можно было кликать на ошибку и оказываться в файле ресурса в строке с ошибкой :-)

А. Яковлев

anonymous
(27.03.07 23:16:28 MSD)