From sergey.aleynikov на gmail.com Sun Feb 1 02:23:30 2015 From: sergey.aleynikov на gmail.com (Sergey Aleynikov) Date: Sun, 1 Feb 2015 14:23:30 +0400 Subject: [Moscow.pm] =?utf-8?b?0JHQsNCzINCyIEpTT046OlhTPw==?= In-Reply-To: <69C5B3C1-CA95-4BDA-88E2-D526F67F7954@gmail.com> References: <69C5B3C1-CA95-4BDA-88E2-D526F67F7954@gmail.com> Message-ID: Добрый день, > При сериализации такого объекта скрипт падает с ошибкой "Segmentation fault" > или метод encode() возвращает undef. Версия с фиксом - http://search.cpan.org/~rurban/Cpanel-JSON-XS-3.0115/ Best regards, Sergey Aleynikov From khedin на gmail.com Sun Feb 1 03:08:58 2015 From: khedin на gmail.com (Konstantin S. Uvarin) Date: Sun, 1 Feb 2015 13:08:58 +0200 Subject: [Moscow.pm] =?utf-8?b?0JHQsNCzINCyIEpTT046OlhTPw==?= In-Reply-To: References: Message-ID: Приветствую. >Написал, Леман говорит, нефиг юзать в списочном конексте :) >Ну а как не юзать-то? Это ж хеш не проинициализировать, >аргументом функции не передать. Ну, можно scalar писать явно: %hash = ( foo => scalar bar (...) ), map { scalar CODE; } @array и т.д. Но это, конечно, штаны через голову и вовсе не повод не фиксить баг. 2014-11-27 1:12 GMT+02:00 Вадим Власов : > > 2014-11-27 0:33 GMT+03:00 Akzhan Abdulin : > >> Мне кажется, это надо писать автору, нет?) >> > Написал, Леман говорит, нефиг юзать в списочном конексте :) > Ну а как не юзать-то? Это ж хеш не проинициализировать, аргументом функции > не передать. Везде что ли в скаляр копировать предварительно? Ну хозяин - > барин, уж как решит. > > > -- > С уважением, > Вадим Власов > т.: +7 (916) 424-00-72 > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ponizovsky на gmail.com Sun Feb 1 04:00:14 2015 From: ponizovsky на gmail.com (Eugene Ponizovsky) Date: Sun, 1 Feb 2015 15:00:14 +0300 Subject: [Moscow.pm] =?koi8-r?b?4sHHINcgSlNPTjo6WFM/?= In-Reply-To: References: <69C5B3C1-CA95-4BDA-88E2-D526F67F7954@gmail.com> Message-ID: Круто. Спасибо. > 1 февр. 2015 г., в 13:23, Sergey Aleynikov написал(а): > > Добрый день, > >> При сериализации такого объекта скрипт падает с ошибкой "Segmentation fault" >> или метод encode() возвращает undef. > > Версия с фиксом - http://search.cpan.org/~rurban/Cpanel-JSON-XS-3.0115/ > > Best regards, > Sergey Aleynikov > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org From andy на shitov.ru Sun Feb 1 05:04:11 2015 From: andy на shitov.ru (Andrew Shitov) Date: Sun, 1 Feb 2015 14:04:11 +0100 Subject: [Moscow.pm] Perl 6 party Message-ID: <748EC27B-37E0-4BAE-934C-628C6AFBCFB4@shitov.ru> Ларри только что объявил, что Perl 6 будет готов к Рождеству 2015. Если получится и как получится :-) -- Andrew Shitov From dmitry на eremeev.ru Sun Feb 1 05:06:38 2015 From: dmitry на eremeev.ru (Dmitry Eremeev) Date: Sun, 1 Feb 2015 13:06:38 +0000 Subject: [Moscow.pm] Perl 6 party In-Reply-To: <748EC27B-37E0-4BAE-934C-628C6AFBCFB4@shitov.ru> References: <748EC27B-37E0-4BAE-934C-628C6AFBCFB4@shitov.ru> Message-ID: <1A79F050-C43F-4182-A0BC-D057B5677956@eremeev.ru> А реально пользоваться начнем ближе к пенсии...)) Yours Dmitry Eremeev CEO adPremium Russia / office: +7 499 703 32 07 UK / office: +44 870 295 24 46 Skype: eremeev.ru https://linkedin.com/in/dimkae https://facebook.com/dimkae > 1 февр. 2015 г., в 13:04, Andrew Shitov написал(а): > > Ларри только что объявил, что Perl 6 будет готов к Рождеству 2015. Если получится и как получится :-) > > -- > Andrew Shitov > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org From zhecka на gmail.com Tue Feb 3 10:35:31 2015 From: zhecka на gmail.com (zhecka) Date: Tue, 03 Feb 2015 21:35:31 +0300 Subject: [Moscow.pm] =?utf-8?b?0J/QsNGA0LTQvtC9INC30LDRgNCw0L3QtdC1?= Message-ID: <54D114F3.5000005@gmail.com> Доброе время суток Уважаемые! А есть аналогичный moscow-pm список рассылки по питону ? Что-то я с perl на python уполз. Многое нравится, но после perl это просто ад :) Привычка в перле делать что угодно десятком разных методов и 1-2 пути в питоне напрягают :( А уж twisted сотоварищи с отсутствием внятной документации вообще вынос мозга. From aml на rulezz.ru Tue Feb 3 11:52:09 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Tue, 03 Feb 2015 19:52:09 +0000 Subject: [Moscow.pm] =?utf-8?b?0J/QsNGA0LTQvtC9INC30LDRgNCw0L3QtdC1?= References: <54D114F3.5000005@gmail.com> Message-ID: Вот интересно мне. Зачем люди себя прибивают к одному языку? Вот уж если я начал писать на Питоне, то значит с перла я "уполз". Вместо " я могу писать на A, B и выбирать лучший язык под задачу" получается "все, что я раньше делал на A, я теперь делаю на B". On Tue, Feb 3, 2015, 19:35 zhecka wrote: > Доброе время суток Уважаемые! > > А есть аналогичный moscow-pm список рассылки по питону ? > Что-то я с perl на python уполз. Многое нравится, но после perl это > просто ад :) > Привычка в перле делать что угодно десятком разных методов и 1-2 пути в > питоне напрягают :( > А уж twisted сотоварищи с отсутствием внятной документации вообще вынос > мозга. > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From zhecka на gmail.com Tue Feb 3 12:06:03 2015 From: zhecka на gmail.com (Eugene Kaltashkin) Date: Tue, 3 Feb 2015 23:06:03 +0300 Subject: [Moscow.pm] =?utf-8?b?0J/QsNGA0LTQvtC9INC30LDRgNCw0L3QtdC1?= In-Reply-To: References: <54D114F3.5000005@gmail.com> Message-ID: да нет. просто скажем задачи асинхронного программирования турникета доступа прекрасно вписываются в модели libusb и twisted. perl я люблю и не брошу. просто подход разный к программированию. на perl async на железном уровне я бы убился писать. 03.02.2015 22:52 пользователь "Alexander Lourier" написал: > Вот интересно мне. Зачем люди себя прибивают к одному языку? Вот уж если я > начал писать на Питоне, то значит с перла я "уполз". Вместо " я могу писать > на A, B и выбирать лучший язык под задачу" получается "все, что я раньше > делал на A, я теперь делаю на B". > > On Tue, Feb 3, 2015, 19:35 zhecka wrote: > >> Доброе время суток Уважаемые! >> >> А есть аналогичный moscow-pm список рассылки по питону ? >> Что-то я с perl на python уполз. Многое нравится, но после perl это >> просто ад :) >> Привычка в перле делать что угодно десятком разных методов и 1-2 пути в >> питоне напрягают :( >> А уж twisted сотоварищи с отсутствием внятной документации вообще вынос >> мозга. >> >> -- >> Moscow.pm mailing list >> moscow-pm на pm.org | http://moscow.pm.org >> > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From aml на rulezz.ru Tue Feb 3 12:47:35 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Tue, 03 Feb 2015 20:47:35 +0000 Subject: [Moscow.pm] =?utf-8?b?0J/QsNGA0LTQvtC9INC30LDRgNCw0L3QtdC1?= References: <54D114F3.5000005@gmail.com> Message-ID: Кстати, если пишете асинхронщину на Python, посмотрите на Stackless. На нём можно писать асинхронный код в синхронном стиле - на корутинах. Ну или взять Go, где всё это от рождения заложено. On Tue Feb 03 2015 at 21:06:19 Eugene Kaltashkin wrote: > да нет. просто скажем задачи асинхронного программирования турникета > доступа прекрасно вписываются в модели libusb и twisted. perl я люблю и не > брошу. просто подход разный к программированию. на perl async на железном > уровне я бы убился писать. > 03.02.2015 22:52 пользователь "Alexander Lourier" написал: > > Вот интересно мне. Зачем люди себя прибивают к одному языку? Вот уж если я >> начал писать на Питоне, то значит с перла я "уполз". Вместо " я могу писать >> на A, B и выбирать лучший язык под задачу" получается "все, что я раньше >> делал на A, я теперь делаю на B". >> >> On Tue, Feb 3, 2015, 19:35 zhecka wrote: >> >>> Доброе время суток Уважаемые! >>> >>> А есть аналогичный moscow-pm список рассылки по питону ? >>> Что-то я с perl на python уполз. Многое нравится, но после perl это >>> просто ад :) >>> Привычка в перле делать что угодно десятком разных методов и 1-2 пути в >>> питоне напрягают :( >>> А уж twisted сотоварищи с отсутствием внятной документации вообще вынос >>> мозга. >>> >>> -- >>> Moscow.pm mailing list >>> moscow-pm на pm.org | http://moscow.pm.org >>> >> >> -- >> Moscow.pm mailing list >> moscow-pm на pm.org | http://moscow.pm.org >> >> -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From devrow на gmail.com Tue Feb 3 12:50:25 2015 From: devrow на gmail.com (devrow на gmail.com) Date: Tue, 03 Feb 2015 23:50:25 +0300 Subject: [Moscow.pm] =?windows-1251?b?z+Dw5O7tIOfg8ODt5eU=?= In-Reply-To: References: <54D114F3.5000005@gmail.com> Message-ID: <54D13491.2060402@gmail.com> On 03.02.2015 22:52, Alexander Lourier wrote: > Вот интересно мне. Зачем люди себя прибивают к одному языку? после с/с++ и perl любой язык - фигня вопрос. go, rust, python, даже (бип-бип-бип) javascript, несколько дней и ты там. если не теже яйца в профиль, то точно в анфас. фреймворки? *лять, они как братья близнецы. асинхронность? cpan install асинхронность. From devrow на gmail.com Tue Feb 3 13:12:25 2015 From: devrow на gmail.com (devrow на gmail.com) Date: Wed, 04 Feb 2015 00:12:25 +0300 Subject: [Moscow.pm] =?windows-1251?b?z+Dw5O7tIOfg8ODt5eU=?= In-Reply-To: References: <54D114F3.5000005@gmail.com> Message-ID: <54D139B9.8010405@gmail.com> On 03.02.2015 23:47, Alexander Lourier wrote: > можно писать асинхронный код в синхронном стиле - на корутинах. да, но нет. From i.petro.77.00 на gmail.com Tue Feb 3 14:30:38 2015 From: i.petro.77.00 на gmail.com (Ivan Petrov) Date: Wed, 4 Feb 2015 01:30:38 +0300 Subject: [Moscow.pm] =?utf-8?b?0J/QsNGA0LTQvtC9INC30LDRgNCw0L3QtdC1?= In-Reply-To: References: <54D114F3.5000005@gmail.com> Message-ID: <20150203223037.GC17407@vdsl.uvw.ru> > да нет. просто скажем задачи асинхронного программирования турникета доступа > прекрасно вписываются в модели libusb и twisted. perl я люблю и не брошу. > просто подход разный к программированию. на perl async на железном уровне я бы > убился писать. Марк Леман написал же, довольно хорошо получилось. From real.kyle на gmail.com Tue Feb 3 14:22:05 2015 From: real.kyle на gmail.com (=?UTF-8?B?0JDQvdC+0L3QuNC8INCQ0L3QvtC90LjQvNC+0LI=?=) Date: Wed, 4 Feb 2015 01:22:05 +0300 Subject: [Moscow.pm] =?utf-8?b?0J/QsNGA0LTQvtC9INC30LDRgNCw0L3QtdC1?= In-Reply-To: <20150203223037.GC17407@vdsl.uvw.ru> References: <54D114F3.5000005@gmail.com> <20150203223037.GC17407@vdsl.uvw.ru> Message-ID: На питон уполз, лал On Wednesday, February 4, 2015, Ivan Petrov wrote: > > да нет. просто скажем задачи асинхронного программирования турникета > доступа > > прекрасно вписываются в модели libusb и twisted. perl я люблю и не брошу. > > просто подход разный к программированию. на perl async на железном > уровне я бы > > убился писать. > > Марк Леман написал же, довольно хорошо получилось. > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nordicdyno на yandex.ru Wed Feb 4 02:01:13 2015 From: nordicdyno на yandex.ru (Orlovsky Alexander) Date: Wed, 04 Feb 2015 13:01:13 +0300 Subject: [Moscow.pm] =?koi8-r?b?8MHSxM/OINrB0sHOxcU=?= In-Reply-To: References: <54D114F3.5000005@gmail.com> <20150203223037.GC17407@vdsl.uvw.ru> Message-ID: <20338461423044073@web26o.yandex.ru> Вложение в формате HTML было извлечено… URL: From dzirtik на gmail.com Thu Feb 5 08:54:12 2015 From: dzirtik на gmail.com (=?UTF-8?B?0J/QsNCy0LXQuyDQqdC10YDQsdC40L3QuNC9?=) Date: Thu, 5 Feb 2015 20:54:12 +0400 Subject: [Moscow.pm] =?utf-8?b?0JLRgdGC0YDQtdGH0LAgTW9zY293LnBtIDUg0YQ=?= =?utf-8?b?0LXQstGA0LDQu9GPIDIwMTM=?= In-Reply-To: References: Message-ID: http://corp.mail.ru/stream/MoscowPM/ прямая трансляция нашей встречи 29 января 2015 г., 19:56 пользователь Павел Щербинин написал: > > - > > Perl-программисты из Moscow.pm снова собирают > единомышленников. За почти 8 лет существования Perl Mongers (от англ. > ?продавцы?) сменили формат посиделок в кафе и прочно обосновались в уютном > офисе Mail.Ru Group. В сообществе ? ветераны Moscow PM и новички, которые с > первого посещения рвутся в спикеры. Программисты приходят сюда, чтобы > поделиться действительно полезным опытом. Однажды запланированное на 40 > минут выступление о ядре Perl так увлекло участников, что дискуссия > растянулась на 3 часа, и все разошлись по домам только к полуночи. > > Предстоящая встреча заинтересует специалистов в e-commerce и тех, кто > не понаслышке знаком с очередями. А ленивым программистам и тем, кто не > любит делать лишнюю работу, будет полезен доклад о генерации кода. > > О работе с документами .xls, .xlsx, .rtf расскажет Наталья Савенкова, > ex-СТО SHOP2YOU.RU . В e-commerce файлы формата > Excel ? основной инструмент обмена данными. Они используются везде: для > документов покупателям и транспортным компаниям, для отчетов менеджерам, > для импорта и экспорта товаров в магазин, для обмена остатками между > поставщиками. Их нужно уметь читать и писать. Наталья объяснит, как это > делать с документами разной структуры, а также поговорит о сложностях и их > решениях. Доклад посвящен классическому формату Excel 1997-2003 (XLS) и > модулям: Spreadsheet::ParseExcel, Spreadsheet::WriteExcel и Excel::Template. > > ?FastQueue ? как мы сделали свою очередь на Perl и Redis? тема ? > выступления Ивана Соколова, teamlead REG.RU . Очередь > ? один из наиболее используемых механизмов в программировании. Например, > для интеграции с платежными системами или для обработки медиа-контента, > загруженного пользователем, необходимо наличие очередей. > > В REG.RU тоже не обходятся без очередей. Поэтому потребность найти > решение появилась достаточно давно. Учитывая специфику компании как > доменного регистратора большинство существующих решений не подходило, и > программисты решили ?написать свой велосипед?. Иван расскажет об > архитектуре их очереди, ее возможностях, и в каких задачах она используется. > > ?Пластилиновый код: как перестать кодить и начать жить? ? доклад Елены > Шишкиной, ведущего программиста Деньги Mail.Ru . > Она покажет практический пример лени как двигателя прогресса в отдельно > взятом веб-проекте: > > - Надоело писать код? Будем думать, как его не писать! > > - Боремся с однотипным кодом. Боремся с неоднотипным кодом. > > - Код, которого не существует, и код, который существует. > > - Следите за руками: программируем на конфигах! > > - Как жить дальше? > > > Что бы мы могли лучше организовать наше мероприятие, пожалуйста, > зарегистрируйтесь здесь > > > -- > С Уважением, > Щербинин Павел > -- С Уважением, Щербинин Павел ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vaneska.ru на gmail.com Thu Feb 5 20:34:25 2015 From: vaneska.ru на gmail.com (=?UTF-8?B?0JjQstCw0L0g0KHQvtC60L7Qu9C+0LI=?=) Date: Fri, 6 Feb 2015 08:34:25 +0400 Subject: [Moscow.pm] =?utf-8?b?0JLRgdGC0YDQtdGH0LAgTW9zY293LnBtIDUg0YQ=?= =?utf-8?b?0LXQstGA0LDQu9GPIDIwMTM=?= In-Reply-To: References: Message-ID: Я в начале конфы говорил про генератор статики. Вот ссылка http://preaction.github.io/Statocles/ Это аналог популярного Jekyll, который активно используется на гитхабе для отображения страничек проектов. Выглядит очень достойно, мне кажется. 5 февраля 2015 г., 19:54 пользователь Павел Щербинин написал: > http://corp.mail.ru/stream/MoscowPM/ > > прямая трансляция нашей встречи > > 29 января 2015 г., 19:56 пользователь Павел Щербинин > написал: > > >> - >> >> Perl-программисты из Moscow.pm снова собирают >> единомышленников. За почти 8 лет существования Perl Mongers (от англ. >> ?продавцы?) сменили формат посиделок в кафе и прочно обосновались в уютном >> офисе Mail.Ru Group. В сообществе ? ветераны Moscow PM и новички, которые с >> первого посещения рвутся в спикеры. Программисты приходят сюда, чтобы >> поделиться действительно полезным опытом. Однажды запланированное на 40 >> минут выступление о ядре Perl так увлекло участников, что дискуссия >> растянулась на 3 часа, и все разошлись по домам только к полуночи. >> >> Предстоящая встреча заинтересует специалистов в e-commerce и тех, кто >> не понаслышке знаком с очередями. А ленивым программистам и тем, кто не >> любит делать лишнюю работу, будет полезен доклад о генерации кода. >> >> О работе с документами .xls, .xlsx, .rtf расскажет Наталья Савенкова, >> ex-СТО SHOP2YOU.RU . В e-commerce файлы формата >> Excel ? основной инструмент обмена данными. Они используются везде: для >> документов покупателям и транспортным компаниям, для отчетов менеджерам, >> для импорта и экспорта товаров в магазин, для обмена остатками между >> поставщиками. Их нужно уметь читать и писать. Наталья объяснит, как это >> делать с документами разной структуры, а также поговорит о сложностях и их >> решениях. Доклад посвящен классическому формату Excel 1997-2003 (XLS) и >> модулям: Spreadsheet::ParseExcel, Spreadsheet::WriteExcel и Excel::Template. >> >> ?FastQueue ? как мы сделали свою очередь на Perl и Redis? тема ? >> выступления Ивана Соколова, teamlead REG.RU . Очередь >> ? один из наиболее используемых механизмов в программировании. Например, >> для интеграции с платежными системами или для обработки медиа-контента, >> загруженного пользователем, необходимо наличие очередей. >> >> В REG.RU тоже не обходятся без очередей. Поэтому потребность найти >> решение появилась достаточно давно. Учитывая специфику компании как >> доменного регистратора большинство существующих решений не подходило, и >> программисты решили ?написать свой велосипед?. Иван расскажет об >> архитектуре их очереди, ее возможностях, и в каких задачах она используется. >> >> ?Пластилиновый код: как перестать кодить и начать жить? ? доклад Елены >> Шишкиной, ведущего программиста Деньги Mail.Ru >> . Она покажет практический пример лени как >> двигателя прогресса в отдельно взятом веб-проекте: >> >> - Надоело писать код? Будем думать, как его не писать! >> >> - Боремся с однотипным кодом. Боремся с неоднотипным кодом. >> >> - Код, которого не существует, и код, который существует. >> >> - Следите за руками: программируем на конфигах! >> >> - Как жить дальше? >> >> >> Что бы мы могли лучше организовать наше мероприятие, пожалуйста, >> зарегистрируйтесь здесь >> >> >> -- >> С Уважением, >> Щербинин Павел >> > > > > -- > С Уважением, > Щербинин Павел > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > > -- С уважением, Иван ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From dzirtik на gmail.com Fri Feb 6 01:07:50 2015 From: dzirtik на gmail.com (=?UTF-8?B?0J/QsNCy0LXQuyDQqdC10YDQsdC40L3QuNC9?=) Date: Fri, 6 Feb 2015 12:07:50 +0300 Subject: [Moscow.pm] =?utf-8?b?0JLRgdGC0YDQtdGH0LAgTW9zY293LnBtIDUg0YQ=?= =?utf-8?b?0LXQstGA0LDQu9GPIDIwMTM=?= In-Reply-To: References: Message-ID: Видео в течение недели появится на нашем канале www.youtube.com/channel/UCXG2gjCfXDkvg9TfPmNXPIg/videos Презентации уже выложены www.slideshare.net/pavelscherbinin 6 февраля 2015 г., 7:34 пользователь Иван Соколов написал: > Я в начале конфы говорил про генератор статики. > Вот ссылка http://preaction.github.io/Statocles/ > Это аналог популярного Jekyll, который активно используется на гитхабе для > отображения страничек проектов. > Выглядит очень достойно, мне кажется. > > 5 февраля 2015 г., 19:54 пользователь Павел Щербинин > написал: > >> http://corp.mail.ru/stream/MoscowPM/ >> >> прямая трансляция нашей встречи >> >> 29 января 2015 г., 19:56 пользователь Павел Щербинин >> написал: >> >> >>> - >>> >>> Perl-программисты из Moscow.pm снова собирают >>> единомышленников. За почти 8 лет существования Perl Mongers (от англ. >>> ?продавцы?) сменили формат посиделок в кафе и прочно обосновались в уютном >>> офисе Mail.Ru Group. В сообществе ? ветераны Moscow PM и новички, которые с >>> первого посещения рвутся в спикеры. Программисты приходят сюда, чтобы >>> поделиться действительно полезным опытом. Однажды запланированное на 40 >>> минут выступление о ядре Perl так увлекло участников, что дискуссия >>> растянулась на 3 часа, и все разошлись по домам только к полуночи. >>> >>> Предстоящая встреча заинтересует специалистов в e-commerce и тех, >>> кто не понаслышке знаком с очередями. А ленивым программистам и тем, кто не >>> любит делать лишнюю работу, будет полезен доклад о генерации кода. >>> >>> О работе с документами .xls, .xlsx, .rtf расскажет Наталья Савенкова, >>> ex-СТО SHOP2YOU.RU . В e-commerce файлы формата >>> Excel ? основной инструмент обмена данными. Они используются везде: для >>> документов покупателям и транспортным компаниям, для отчетов менеджерам, >>> для импорта и экспорта товаров в магазин, для обмена остатками между >>> поставщиками. Их нужно уметь читать и писать. Наталья объяснит, как это >>> делать с документами разной структуры, а также поговорит о сложностях и их >>> решениях. Доклад посвящен классическому формату Excel 1997-2003 (XLS) и >>> модулям: Spreadsheet::ParseExcel, Spreadsheet::WriteExcel и Excel::Template. >>> >>> ?FastQueue ? как мы сделали свою очередь на Perl и Redis? тема ? >>> выступления Ивана Соколова, teamlead REG.RU . >>> Очередь ? один из наиболее используемых механизмов в >>> программировании. Например, для интеграции с платежными системами или для >>> обработки медиа-контента, загруженного пользователем, необходимо наличие >>> очередей. >>> >>> В REG.RU тоже не обходятся без очередей. Поэтому потребность найти >>> решение появилась достаточно давно. Учитывая специфику компании как >>> доменного регистратора большинство существующих решений не подходило, и >>> программисты решили ?написать свой велосипед?. Иван расскажет об >>> архитектуре их очереди, ее возможностях, и в каких задачах она используется. >>> >>> ?Пластилиновый код: как перестать кодить и начать жить? ? доклад Елены >>> Шишкиной, ведущего программиста Деньги Mail.Ru >>> . Она покажет практический пример лени как >>> двигателя прогресса в отдельно взятом веб-проекте: >>> >>> - Надоело писать код? Будем думать, как его не писать! >>> >>> - Боремся с однотипным кодом. Боремся с неоднотипным кодом. >>> >>> - Код, которого не существует, и код, который существует. >>> >>> - Следите за руками: программируем на конфигах! >>> >>> - Как жить дальше? >>> >>> >>> Что бы мы могли лучше организовать наше мероприятие, пожалуйста, >>> зарегистрируйтесь здесь >>> >>> >>> -- >>> С Уважением, >>> Щербинин Павел >>> >> >> >> >> -- >> С Уважением, >> Щербинин Павел >> >> -- >> Moscow.pm mailing list >> moscow-pm на pm.org | http://moscow.pm.org >> >> > > > -- > С уважением, > Иван > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > > -- С Уважением, Щербинин Павел ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From bobrovaksenia на gmail.com Fri Feb 6 01:57:07 2015 From: bobrovaksenia на gmail.com (=?UTF-8?B?0JrRgdC10L3QuNGPINCR0L7QsdGA0L7QstCw?=) Date: Fri, 6 Feb 2015 10:57:07 +0100 Subject: [Moscow.pm] =?utf-8?b?0JLRgdGC0YDQtdGH0LAgTW9zY293LnBtIDUg0YQ=?= =?utf-8?b?0LXQstGA0LDQu9GPIDIwMTM=?= In-Reply-To: References: Message-ID: А видео с предыдущих встреч?) 6 февраля 2015 г., 10:07 пользователь Павел Щербинин написал: > Видео в течение недели появится на нашем канале > www.youtube.com/channel/UCXG2gjCfXDkvg9TfPmNXPIg/videos > Презентации уже выложены www.slideshare.net/pavelscherbinin > > 6 февраля 2015 г., 7:34 пользователь Иван Соколов > написал: > > Я в начале конфы говорил про генератор статики. >> Вот ссылка http://preaction.github.io/Statocles/ >> Это аналог популярного Jekyll, который активно используется на гитхабе >> для отображения страничек проектов. >> Выглядит очень достойно, мне кажется. >> >> 5 февраля 2015 г., 19:54 пользователь Павел Щербинин >> написал: >> >>> http://corp.mail.ru/stream/MoscowPM/ >>> >>> прямая трансляция нашей встречи >>> >>> 29 января 2015 г., 19:56 пользователь Павел Щербинин >>> написал: >>> >>> >>>> - >>>> >>>> Perl-программисты из Moscow.pm снова собирают >>>> единомышленников. За почти 8 лет существования Perl Mongers (от англ. >>>> ?продавцы?) сменили формат посиделок в кафе и прочно обосновались в уютном >>>> офисе Mail.Ru Group. В сообществе ? ветераны Moscow PM и новички, которые с >>>> первого посещения рвутся в спикеры. Программисты приходят сюда, чтобы >>>> поделиться действительно полезным опытом. Однажды запланированное на 40 >>>> минут выступление о ядре Perl так увлекло участников, что дискуссия >>>> растянулась на 3 часа, и все разошлись по домам только к полуночи. >>>> >>>> Предстоящая встреча заинтересует специалистов в e-commerce и тех, >>>> кто не понаслышке знаком с очередями. А ленивым программистам и тем, кто не >>>> любит делать лишнюю работу, будет полезен доклад о генерации кода. >>>> >>>> О работе с документами .xls, .xlsx, .rtf расскажет Наталья Савенкова, >>>> ex-СТО SHOP2YOU.RU . В e-commerce файлы >>>> формата Excel ? основной инструмент обмена данными. Они используются везде: >>>> для документов покупателям и транспортным компаниям, для отчетов >>>> менеджерам, для импорта и экспорта товаров в магазин, для обмена остатками >>>> между поставщиками. Их нужно уметь читать и писать. Наталья объяснит, как >>>> это делать с документами разной структуры, а также поговорит о сложностях и >>>> их решениях. Доклад посвящен классическому формату Excel 1997-2003 (XLS) и >>>> модулям: Spreadsheet::ParseExcel, Spreadsheet::WriteExcel и Excel::Template. >>>> >>>> ?FastQueue ? как мы сделали свою очередь на Perl и Redis? тема ? >>>> выступления Ивана Соколова, teamlead REG.RU . >>>> Очередь ? один из наиболее используемых механизмов в >>>> программировании. Например, для интеграции с платежными системами или для >>>> обработки медиа-контента, загруженного пользователем, необходимо наличие >>>> очередей. >>>> >>>> В REG.RU тоже не обходятся без очередей. Поэтому потребность найти >>>> решение появилась достаточно давно. Учитывая специфику компании как >>>> доменного регистратора большинство существующих решений не подходило, и >>>> программисты решили ?написать свой велосипед?. Иван расскажет об >>>> архитектуре их очереди, ее возможностях, и в каких задачах она используется. >>>> >>>> ?Пластилиновый код: как перестать кодить и начать жить? ? доклад Елены >>>> Шишкиной, ведущего программиста Деньги Mail.Ru >>>> . Она покажет практический пример лени как >>>> двигателя прогресса в отдельно взятом веб-проекте: >>>> >>>> - Надоело писать код? Будем думать, как его не писать! >>>> >>>> - Боремся с однотипным кодом. Боремся с неоднотипным кодом. >>>> >>>> - Код, которого не существует, и код, который существует. >>>> >>>> - Следите за руками: программируем на конфигах! >>>> >>>> - Как жить дальше? >>>> >>>> >>>> Что бы мы могли лучше организовать наше мероприятие, пожалуйста, >>>> зарегистрируйтесь здесь >>>> >>>> >>>> -- >>>> С Уважением, >>>> Щербинин Павел >>>> >>> >>> >>> >>> -- >>> С Уважением, >>> Щербинин Павел >>> >>> -- >>> Moscow.pm mailing list >>> moscow-pm на pm.org | http://moscow.pm.org >>> >>> >> >> >> -- >> С уважением, >> Иван >> >> -- >> Moscow.pm mailing list >> moscow-pm на pm.org | http://moscow.pm.org >> >> > > > -- > С Уважением, > Щербинин Павел > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > > -- Ksenia Bobrova Senior Perl Developer ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From timur.nozadze на gmail.com Fri Feb 6 03:10:50 2015 From: timur.nozadze на gmail.com (=?UTF-8?B?0KLQuNC80YPRgCDQndC+0LfQsNC00LfQtQ==?=) Date: Fri, 6 Feb 2015 15:10:50 +0400 Subject: [Moscow.pm] =?utf-8?b?0JLRgdGC0YDQtdGH0LAgTW9zY293LnBtIDUg0YQ=?= =?utf-8?b?0LXQstGA0LDQu9GPIDIwMTM=?= In-Reply-To: References: Message-ID: Perl 6 ? к Рождеству, а видео с Moscow.pm ? к концу недели. ;) Паша, очень ждём! 6 февраля 2015 г., 12:57 пользователь Ксения Боброва < bobrovaksenia на gmail.com> написал: > А видео с предыдущих встреч?) > > 6 февраля 2015 г., 10:07 пользователь Павел Щербинин > написал: > > Видео в течение недели появится на нашем канале >> www.youtube.com/channel/UCXG2gjCfXDkvg9TfPmNXPIg/videos >> Презентации уже выложены www.slideshare.net/pavelscherbinin >> >> 6 февраля 2015 г., 7:34 пользователь Иван Соколов >> написал: >> >> Я в начале конфы говорил про генератор статики. >>> Вот ссылка http://preaction.github.io/Statocles/ >>> Это аналог популярного Jekyll, который активно используется на гитхабе >>> для отображения страничек проектов. >>> Выглядит очень достойно, мне кажется. >>> >>> 5 февраля 2015 г., 19:54 пользователь Павел Щербинин >>> написал: >>> >>>> http://corp.mail.ru/stream/MoscowPM/ >>>> >>>> прямая трансляция нашей встречи >>>> >>>> 29 января 2015 г., 19:56 пользователь Павел Щербинин >>> > написал: >>>> >>>> >>>>> - >>>>> >>>>> Perl-программисты из Moscow.pm снова собирают >>>>> единомышленников. За почти 8 лет существования Perl Mongers (от англ. >>>>> ?продавцы?) сменили формат посиделок в кафе и прочно обосновались в уютном >>>>> офисе Mail.Ru Group. В сообществе ? ветераны Moscow PM и новички, которые с >>>>> первого посещения рвутся в спикеры. Программисты приходят сюда, чтобы >>>>> поделиться действительно полезным опытом. Однажды запланированное на 40 >>>>> минут выступление о ядре Perl так увлекло участников, что дискуссия >>>>> растянулась на 3 часа, и все разошлись по домам только к полуночи. >>>>> >>>>> Предстоящая встреча заинтересует специалистов в e-commerce и тех, >>>>> кто не понаслышке знаком с очередями. А ленивым программистам и тем, кто не >>>>> любит делать лишнюю работу, будет полезен доклад о генерации кода. >>>>> >>>>> О работе с документами .xls, .xlsx, .rtf расскажет Наталья >>>>> Савенкова, ex-СТО SHOP2YOU.RU . В e-commerce >>>>> файлы формата Excel ? основной инструмент обмена данными. Они используются >>>>> везде: для документов покупателям и транспортным компаниям, для отчетов >>>>> менеджерам, для импорта и экспорта товаров в магазин, для обмена остатками >>>>> между поставщиками. Их нужно уметь читать и писать. Наталья объяснит, как >>>>> это делать с документами разной структуры, а также поговорит о сложностях и >>>>> их решениях. Доклад посвящен классическому формату Excel 1997-2003 (XLS) и >>>>> модулям: Spreadsheet::ParseExcel, Spreadsheet::WriteExcel и Excel::Template. >>>>> >>>>> ?FastQueue ? как мы сделали свою очередь на Perl и Redis? тема ? >>>>> выступления Ивана Соколова, teamlead REG.RU . >>>>> Очередь ? один из наиболее используемых механизмов в >>>>> программировании. Например, для интеграции с платежными системами или для >>>>> обработки медиа-контента, загруженного пользователем, необходимо наличие >>>>> очередей. >>>>> >>>>> В REG.RU тоже не обходятся без очередей. Поэтому потребность найти >>>>> решение появилась достаточно давно. Учитывая специфику компании как >>>>> доменного регистратора большинство существующих решений не подходило, и >>>>> программисты решили ?написать свой велосипед?. Иван расскажет об >>>>> архитектуре их очереди, ее возможностях, и в каких задачах она используется. >>>>> >>>>> ?Пластилиновый код: как перестать кодить и начать жить? ? доклад Елены >>>>> Шишкиной, ведущего программиста Деньги Mail.Ru >>>>> . Она покажет практический пример лени как >>>>> двигателя прогресса в отдельно взятом веб-проекте: >>>>> >>>>> - Надоело писать код? Будем думать, как его не писать! >>>>> >>>>> - Боремся с однотипным кодом. Боремся с неоднотипным кодом. >>>>> >>>>> - Код, которого не существует, и код, который существует. >>>>> >>>>> - Следите за руками: программируем на конфигах! >>>>> >>>>> - Как жить дальше? >>>>> >>>>> >>>>> Что бы мы могли лучше организовать наше мероприятие, пожалуйста, >>>>> зарегистрируйтесь здесь >>>>> >>>>> >>>>> -- >>>>> С Уважением, >>>>> Щербинин Павел >>>>> >>>> >>>> >>>> >>>> -- >>>> С Уважением, >>>> Щербинин Павел >>>> >>>> -- >>>> Moscow.pm mailing list >>>> moscow-pm на pm.org | http://moscow.pm.org >>>> >>>> >>> >>> >>> -- >>> С уважением, >>> Иван >>> >>> -- >>> Moscow.pm mailing list >>> moscow-pm на pm.org | http://moscow.pm.org >>> >>> >> >> >> -- >> С Уважением, >> Щербинин Павел >> >> -- >> Moscow.pm mailing list >> moscow-pm на pm.org | http://moscow.pm.org >> >> > > > -- > Ksenia Bobrova > Senior Perl Developer > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > > -- С уважением, Тимур Нозадзе ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mons на cpan.org Fri Feb 6 18:07:43 2015 From: mons на cpan.org (Mons Anderson) Date: Sat, 7 Feb 2015 06:07:43 +0400 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= Message-ID: По итогам обсуждения с коллегами по цеху, пришли к мнению, что у сообщества вполне могут быть вопросы, на которые я мог бы ответить в форме докладов. Готов сделать доклад на интересную сообществу тему. Напишите, плиз, про что было-бы интересно послушать. -- Best wishes, Vladimir V. Perepelitsa aka Mons Anderson , http://github.com/Mons From pushtaev.vm на gmail.com Sat Feb 7 00:41:14 2015 From: pushtaev.vm на gmail.com (Vadim Pushtaev) Date: Sat, 07 Feb 2015 11:41:14 +0300 Subject: [Moscow.pm] =?koi8-r?b?9MXN2SDEzNEgxM/LzMHEz9c=?= In-Reply-To: References: Message-ID: <269181423298474@web7o.yandex.ru> An HTML attachment was scrubbed... URL: From theathlet на yandex.ru Sat Feb 7 08:37:27 2015 From: theathlet на yandex.ru (TheAthlete) Date: Sat, 07 Feb 2015 19:37:27 +0300 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: References: Message-ID: Думаю, что-нибудь про асинхронщину (AnyEvent, EV) - как дебажить, как профайлить, как искать утечки, какие-нибудь хаки, нестандартные решения. Mons Anderson писал(а) в своём письме Sat, 07 Feb 2015 05:07:43 +0300: > По итогам обсуждения с коллегами по цеху, пришли к мнению, что у > сообщества вполне могут быть вопросы, на которые я мог бы ответить в > форме докладов. > > Готов сделать доклад на интересную сообществу тему. > Напишите, плиз, про что было-бы интересно послушать. > -- Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/ From name2rnd на gmail.com Sat Feb 7 08:55:45 2015 From: name2rnd на gmail.com (Natalya Savenkova) Date: Sat, 7 Feb 2015 19:55:45 +0300 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: References: Message-ID: Мне было бы интересно послушать "почему perl плохой" (не жгите меня=). О недостатках, в общем. 7 февраля 2015 г., 19:37 пользователь TheAthlete написал: > Думаю, что-нибудь про асинхронщину (AnyEvent, EV) - как дебажить, как > профайлить, как искать утечки, какие-нибудь хаки, нестандартные решения. > > Mons Anderson писал(а) в своём письме Sat, 07 Feb 2015 > 05:07:43 +0300: > > По итогам обсуждения с коллегами по цеху, пришли к мнению, что у >> сообщества вполне могут быть вопросы, на которые я мог бы ответить в >> форме докладов. >> >> Готов сделать доклад на интересную сообществу тему. >> Напишите, плиз, про что было-бы интересно послушать. >> >> > > -- > Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/ > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From onokonem на gmail.com Sat Feb 7 09:24:52 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Sat, 7 Feb 2015 21:24:52 +0400 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: References: Message-ID: > Мне было бы интересно послушать "почему perl плохой" на самом деле - "для каких задач перл подходит плохо" From name2rnd на gmail.com Sat Feb 7 09:27:16 2015 From: name2rnd на gmail.com (Natalya Savenkova) Date: Sat, 7 Feb 2015 20:27:16 +0300 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: References: Message-ID: Окей, пусть будет такая формулировка =) 7 февраля 2015 г., 20:24 пользователь Daniel Podolsky написал: > > Мне было бы интересно послушать "почему perl плохой" > на самом деле - "для каких задач перл подходит плохо" > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From bobrovaksenia на gmail.com Sat Feb 7 10:02:15 2015 From: bobrovaksenia на gmail.com (=?UTF-8?B?0JrRgdC10L3QuNGPINCR0L7QsdGA0L7QstCw?=) Date: Sat, 7 Feb 2015 19:02:15 +0100 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: References: Message-ID: Поддерживаю насчет AnyEvent. Еще хотелось бы про AnyEvent::Handle - более подробно про преимущества перед AnyEvent->io, производительность и вот это все. И про внутренности побольше. Еще нереально интересно было бы послушать про то как правильно организовывать код мало-мальски сложного асинхронного приложения. А то примеры хеллоуворлда на AnyEvent подзадолбали уже. 7 февраля 2015 г., 18:27 пользователь Natalya Savenkova написал: > Окей, пусть будет такая формулировка =) > > 7 февраля 2015 г., 20:24 пользователь Daniel Podolsky > написал: > > > Мне было бы интересно послушать "почему perl плохой" >> на самом деле - "для каких задач перл подходит плохо" >> -- >> Moscow.pm mailing list >> moscow-pm на pm.org | http://moscow.pm.org >> > > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > > -- Ksenia Bobrova Senior Perl Developer ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From foxcool333 на gmail.com Sat Feb 7 10:07:41 2015 From: foxcool333 на gmail.com (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCk0L7QutGB0LrRg9C7?=) Date: Sat, 7 Feb 2015 22:07:41 +0400 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: References: Message-ID: Такие емкие вещи, как информация об эниэвенте таки лучше всего в вики формате бы пригодилась. 07.02.2015 21:02 пользователь "Ксения Боброва" написал: > Поддерживаю насчет AnyEvent. Еще хотелось бы про AnyEvent::Handle - более > подробно про преимущества перед AnyEvent->io, производительность и вот это > все. И про внутренности побольше. > Еще нереально интересно было бы послушать про то как правильно > организовывать код мало-мальски сложного асинхронного приложения. А то > примеры хеллоуворлда на AnyEvent подзадолбали уже. > > 7 февраля 2015 г., 18:27 пользователь Natalya Savenkova < > name2rnd на gmail.com> написал: > >> Окей, пусть будет такая формулировка =) >> >> 7 февраля 2015 г., 20:24 пользователь Daniel Podolsky > > написал: >> >> > Мне было бы интересно послушать "почему perl плохой" >>> на самом деле - "для каких задач перл подходит плохо" >>> -- >>> Moscow.pm mailing list >>> moscow-pm на pm.org | http://moscow.pm.org >>> >> >> >> -- >> Moscow.pm mailing list >> moscow-pm на pm.org | http://moscow.pm.org >> >> > > > -- > Ksenia Bobrova > Senior Perl Developer > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mironorange на gmail.com Sat Feb 7 10:36:29 2015 From: mironorange на gmail.com (=?UTF-8?B?0JjQstCw0L0g0JzQuNGA0L7QvdC+0LI=?=) Date: Sat, 7 Feb 2015 22:36:29 +0400 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: References: Message-ID: Добрый день! Выскажу свое небольшое мнение: - Очень хотелось бы послушать как другие программисты оптимизируют свою работу, какие инструменты используют, как организуют работу в команде; - Послушать про высокие нагрузки. Способы диагностики, оптимизации; - И наверное, самое удивительное, на состоявшемся выступлении очень понравилось выступление Наталь?и? Савенковой, я думаю, было бы очень приятно послушать её еще раз! ? 7 февраля 2015 г., 21:07 пользователь Александр Фокскул < foxcool333 на gmail.com> написал: > Такие емкие вещи, как информация об эниэвенте таки лучше всего в вики > формате бы пригодилась. > 07.02.2015 21:02 пользователь "Ксения Боброва" > написал: > > Поддерживаю насчет AnyEvent. Еще хотелось бы про AnyEvent::Handle - более >> подробно про преимущества перед AnyEvent->io, производительность и вот это >> все. И про внутренности побольше. >> Еще нереально интересно было бы послушать про то как правильно >> организовывать код мало-мальски сложного асинхронного приложения. А то >> примеры хеллоуворлда на AnyEvent подзадолбали уже. >> >> 7 февраля 2015 г., 18:27 пользователь Natalya Savenkova < >> name2rnd на gmail.com> написал: >> >>> Окей, пусть будет такая формулировка =) >>> >>> 7 февраля 2015 г., 20:24 пользователь Daniel Podolsky < >>> onokonem на gmail.com> написал: >>> >>> > Мне было бы интересно послушать "почему perl плохой" >>>> на самом деле - "для каких задач перл подходит плохо" >>>> -- >>>> Moscow.pm mailing list >>>> moscow-pm на pm.org | http://moscow.pm.org >>>> >>> >>> >>> -- >>> Moscow.pm mailing list >>> moscow-pm на pm.org | http://moscow.pm.org >>> >>> >> >> >> -- >> Ksenia Bobrova >> Senior Perl Developer >> >> -- >> Moscow.pm mailing list >> moscow-pm на pm.org | http://moscow.pm.org >> >> > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > > -- С уважением, Миронов Иван! ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From name2rnd на gmail.com Sat Feb 7 10:55:54 2015 From: name2rnd на gmail.com (Natalya Savenkova) Date: Sat, 7 Feb 2015 21:55:54 +0300 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: References: Message-ID: "как другие программисты оптимизируют свою работу" - тему я эту люблю и уверена, смогу рассказать полезное. Вообще, мы с Пашей уже обсуждали один вариант доклада на март. Хотя тайм-менеджмент тема просто невероятно интересная. Вот пусть сам выбирает теперь. 7 февраля 2015 г., 21:36 пользователь Иван Миронов написал: > Добрый день! > > Выскажу свое небольшое мнение: > > - Очень хотелось бы послушать как другие программисты оптимизируют свою > работу, какие инструменты используют, как организуют работу в команде; > > - Послушать про высокие нагрузки. Способы диагностики, оптимизации; > > - И наверное, самое удивительное, на состоявшемся выступлении очень > понравилось выступление Наталь?и? Савенковой, я думаю, было бы очень > приятно послушать её еще раз! > > ? > 7 февраля 2015 г., 21:07 пользователь Александр Фокскул < > foxcool333 на gmail.com> написал: > >> Такие емкие вещи, как информация об эниэвенте таки лучше всего в вики >> формате бы пригодилась. >> 07.02.2015 21:02 пользователь "Ксения Боброва" >> написал: >> >> Поддерживаю насчет AnyEvent. Еще хотелось бы про AnyEvent::Handle - более >>> подробно про преимущества перед AnyEvent->io, производительность и вот это >>> все. И про внутренности побольше. >>> Еще нереально интересно было бы послушать про то как правильно >>> организовывать код мало-мальски сложного асинхронного приложения. А то >>> примеры хеллоуворлда на AnyEvent подзадолбали уже. >>> >>> 7 февраля 2015 г., 18:27 пользователь Natalya Savenkova < >>> name2rnd на gmail.com> написал: >>> >>>> Окей, пусть будет такая формулировка =) >>>> >>>> 7 февраля 2015 г., 20:24 пользователь Daniel Podolsky < >>>> onokonem на gmail.com> написал: >>>> >>>> > Мне было бы интересно послушать "почему perl плохой" >>>>> на самом деле - "для каких задач перл подходит плохо" >>>>> -- >>>>> Moscow.pm mailing list >>>>> moscow-pm на pm.org | http://moscow.pm.org >>>>> >>>> >>>> >>>> -- >>>> Moscow.pm mailing list >>>> moscow-pm на pm.org | http://moscow.pm.org >>>> >>>> >>> >>> >>> -- >>> Ksenia Bobrova >>> Senior Perl Developer >>> >>> -- >>> Moscow.pm mailing list >>> moscow-pm на pm.org | http://moscow.pm.org >>> >>> >> -- >> Moscow.pm mailing list >> moscow-pm на pm.org | http://moscow.pm.org >> >> > > > -- > > С уважением, Миронов Иван! > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From onokonem на gmail.com Sat Feb 7 11:47:14 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Sat, 7 Feb 2015 23:47:14 +0400 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: References: Message-ID: > Окей, пусть будет такая формулировка =) >> > Мне было бы интересно послушать "почему perl плохой" >> на самом деле - "для каких задач перл подходит плохо" Дело в том, что как раз на эту тему я готов докладываться со вкусом. Стараюсь в этой связи придерживаться формулировок покорректнее.... From postmaster на softsearch.ru Sun Feb 8 02:10:28 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sun, 8 Feb 2015 13:10:28 +0300 Subject: [Moscow.pm] =?koi8-r?b?9MXN2SDEzNEgxM/LzMHEz9c=?= In-Reply-To: References: Message-ID: <19923524.20150208131028@softsearch.ru> Здравствуйте, Ксения. > Еще нереально интересно было бы послушать про то как правильно > организовывать код мало-мальски сложного асинхронного приложения. А > то примеры хеллоуворлда на AnyEvent подзадолбали уже. Есть мнение, что более-менее сложное на колбэках писать можно, но неудобно (долго писать, сложно сопровождать и отлаживать, требует высокой квалификации и умения переключаться на "мыслить колбэками"), а потому надо подыскивать альтернативы колбэкам, которые, кстати существую. -- С уважением, Михаил mailto:postmaster на softsearch.ru From postmaster на softsearch.ru Sun Feb 8 02:01:31 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sun, 8 Feb 2015 13:01:31 +0300 Subject: [Moscow.pm] =?koi8-r?b?9MXN2SDEzNEgxM/LzMHEz9c=?= In-Reply-To: References: Message-ID: <364786326.20150208130131@softsearch.ru> Здравствуйте, TheAthlete. > Думаю, что-нибудь про асинхронщину (AnyEvent, EV) - как дебажить, > как профайлить, как искать утечки, какие-нибудь хаки, нестандартные > решения. Открыл для себя универсальный профайлер: Intel Vtune. Он правда денег стоит и из-за санкций его сложно скачать, но зато показывает тормоза в любом коде. Не знаю, показывает ли он соответствие между ассемблерным кодом и перловым, но с Go дружит отлично. Из огромных плюсов: он может указать на возможные способы ускорения в тех местах, где казалось бы всё уже и так оптимизировано. Пример: из-за случайного доступа к элементам массива эта память не попадает в кэш процессора, из-за кучи условных переходов не работает анализатор ветвлении, инструкции сильно связаны друг с другом и потому не возможно их параллельное выполнение и т.п. Есть и пара минусов: он может сильно глючить, да так, что помогает только ребут. И после просмотра ассемблерного кода хочется всё переписать на нём, а не на языке высокого уровня. :-) -- С уважением, Михаил mailto:postmaster на softsearch.ru From bobrovaksenia на gmail.com Sun Feb 8 03:06:55 2015 From: bobrovaksenia на gmail.com (=?UTF-8?B?0JrRgdC10L3QuNGPINCR0L7QsdGA0L7QstCw?=) Date: Sun, 8 Feb 2015 12:06:55 +0100 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: <19923524.20150208131028@softsearch.ru> References: <19923524.20150208131028@softsearch.ru> Message-ID: Что в вашем понимании "сложное"? Мы писали небольшой прокси на AnyEvent, несколько сотен строк кода. Что касается альтернатив колбэкам, хотелось бы услышать поподробнее, что вы имеете в виду. В нашем случае я не видела каких-то альтернатив. Квалификация, разумеется, требуется. Но почему это должно стать препятствием? 8 февраля 2015 г., 11:10 пользователь Михаил Монашёв < postmaster на softsearch.ru> написал: > Здравствуйте, Ксения. > > > Еще нереально интересно было бы послушать про то как правильно > > организовывать код мало-мальски сложного асинхронного приложения. А > > то примеры хеллоуворлда на AnyEvent подзадолбали уже. > > Есть мнение, что более-менее сложное на колбэках писать можно, но > неудобно (долго писать, сложно сопровождать и отлаживать, требует > высокой квалификации и умения переключаться на "мыслить колбэками"), а > потому надо подыскивать альтернативы колбэкам, которые, кстати > существую. > > -- > С уважением, > Михаил mailto:postmaster на softsearch.ru > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > -- Ksenia Bobrova Senior Perl Developer ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From timur.nozadze на gmail.com Sun Feb 8 04:52:34 2015 From: timur.nozadze на gmail.com (=?UTF-8?B?0KLQuNC80YPRgCDQndC+0LfQsNC00LfQtQ==?=) Date: Sun, 8 Feb 2015 16:52:34 +0400 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: References: <19923524.20150208131028@softsearch.ru> Message-ID: > > Поддерживаю насчет AnyEvent. Еще хотелось бы про AnyEvent::Handle - более > подробно про преимущества перед AnyEvent->io, производительность и вот это > все. И про внутренности побольше. > Еще нереально интересно было бы послушать про то как правильно > организовывать код мало-мальски сложного асинхронного приложения. А то > примеры хеллоуворлда на AnyEvent подзадолбали уже. > Поддерживаю категорически! Особенно про внутренности всей этой асинхронщины давно хочется послушать. 8 февраля 2015 г., 14:06 пользователь Ксения Боброва < bobrovaksenia на gmail.com> написал: > Что в вашем понимании "сложное"? Мы писали небольшой прокси на AnyEvent, > несколько сотен строк кода. > Что касается альтернатив колбэкам, хотелось бы услышать поподробнее, что > вы имеете в виду. В нашем случае я не видела каких-то альтернатив. > Квалификация, разумеется, требуется. Но почему это должно стать > препятствием? > > 8 февраля 2015 г., 11:10 пользователь Михаил Монашёв < > postmaster на softsearch.ru> написал: > > Здравствуйте, Ксения. >> >> > Еще нереально интересно было бы послушать про то как правильно >> > организовывать код мало-мальски сложного асинхронного приложения. А >> > то примеры хеллоуворлда на AnyEvent подзадолбали уже. >> >> Есть мнение, что более-менее сложное на колбэках писать можно, но >> неудобно (долго писать, сложно сопровождать и отлаживать, требует >> высокой квалификации и умения переключаться на "мыслить колбэками"), а >> потому надо подыскивать альтернативы колбэкам, которые, кстати >> существую. >> >> -- >> С уважением, >> Михаил mailto:postmaster на softsearch.ru >> >> -- >> Moscow.pm mailing list >> moscow-pm на pm.org | http://moscow.pm.org >> > > > > -- > Ksenia Bobrova > Senior Perl Developer > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > > -- С уважением, Тимур Нозадзе ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From postmaster на softsearch.ru Sun Feb 8 07:51:26 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sun, 8 Feb 2015 18:51:26 +0300 Subject: [Moscow.pm] =?koi8-r?b?9MXN2SDEzNEgxM/LzMHEz9c=?= In-Reply-To: References: <19923524.20150208131028@softsearch.ru> Message-ID: <236366112.20150208185126@softsearch.ru> Здравствуйте, Ксения. > Что в вашем понимании "сложное"? Мы писали небольшой прокси на > AnyEvent, несколько сотен строк кода. У меня лично хорошо писалось на Node.js пока всё помещалось в моей голове. Потом я забросил код и через год было очень сложно разобраться и продолжить его писать. Даже удивился, неужели я написал всю эту чушь. :-) Пока проект маленький и простой, всё очевидно нет проблем с его развитием. А как он вырастает, то требуется или очень хороший архитектор, который заранее правильно распишет все модули их функционал и прочее или легко завязнуть, когда развитие станет оооочень медленным. > Что касается альтернатив колбэкам, хотелось бы услышать поподробнее, > что вы имеете в виду. В нашем случае я не видела каких-то > альтернатив. Go с его дешёвыми горутинами и каналами. Код выходит более линейный, а потому более привычный для обычного программиста. Соглашусь с Александром Лурье, что язык стоит выбирать под задачу. Какой больше подходит, на том и писать. Только Вот что Вам дают колбэки кроме иллюзии параллельности. Латентность понижать можно и без них. P.S. Читаю и лист и удивляюсь как многие тут зациклились на перле. Это древний язык, хотя и не умирающий пока. Но многое изменилось в мире и он уже не поспевает за изменениями. Это сразу бросается в глаза, когда пробуешь новые языки. -- С уважением, Михаил mailto:postmaster на softsearch.ru From pef-secure на yandex.ru Sun Feb 8 09:28:00 2015 From: pef-secure на yandex.ru (PEF Secure) Date: Sun, 08 Feb 2015 18:28 +0100 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: <236366112.20150208185126@softsearch.ru> References: <236366112.20150208185126@softsearch.ru> Message-ID: <8435987.X7MCR7P5hL@rawen> On Sunday, February 08, 2015 18:51:26 Михаил Монашёв wrote: (1) > У меня лично хорошо писалось на Node.js пока всё помещалось в моей > голове. Потом я забросил код и через год было очень сложно разобраться > и продолжить его писать. Даже удивился, неужели я написал всю эту > чушь. :-) Пока проект маленький и простой, всё очевидно нет проблем с > его развитием. А как он вырастает, то требуется или очень хороший > архитектор, который заранее правильно распишет все модули их > функционал и прочее или легко завязнуть, когда развитие станет > оооочень медленным. (2) > Читаю и лист и удивляюсь как многие тут зациклились на перле. Это > древний язык, хотя и не умирающий пока. Но многое изменилось в мире и > он уже не поспевает за изменениями. Это сразу бросается в глаза, когда > пробуешь новые языки. Человек, который не может через полгода разобраться в своём же коде (1), способен многому удивиться (2). -- PEF Developer From pef-secure на yandex.ru Sun Feb 8 09:30:33 2015 From: pef-secure на yandex.ru (PEF Secure) Date: Sun, 08 Feb 2015 18:30:33 +0100 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: References: Message-ID: <3554242.MnZySGtjuc@rawen> On Sunday, February 08, 2015 16:52:34 Тимур Нозадзе wrote: > > Поддерживаю категорически! Особенно про внутренности всей этой асинхронщины > давно хочется послушать. Не понимаю. Исходные коды AnyEvent/Coro лежат на CPAN, смотреть внутренности можно лично, без пересказов. -- PEF Developer From victor на vsespb.ru Sun Feb 8 09:33:34 2015 From: victor на vsespb.ru (Victor Efimov) Date: Sun, 8 Feb 2015 21:33:34 +0400 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: <3554242.MnZySGtjuc@rawen> References: <3554242.MnZySGtjuc@rawen> Message-ID: 8 февраля 2015 г., 20:30 пользователь PEF Secure написал: > On Sunday, February 08, 2015 16:52:34 Тимур Нозадзе wrote: >> >> Поддерживаю категорически! Особенно про внутренности всей этой асинхронщины >> давно хочется послушать. > > Не понимаю. Исходные коды AnyEvent/Coro лежат на CPAN, смотреть внутренности > можно лично, без пересказов. Тогда никакие доклады не нужны. Всё на CPAN есть. > -- > PEF Developer > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org From pef-secure на yandex.ru Sun Feb 8 09:36:15 2015 From: pef-secure на yandex.ru (PEF Secure) Date: Sun, 08 Feb 2015 18:36:15 +0100 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: References: <19923524.20150208131028@softsearch.ru> Message-ID: <1448301.L8bfyLT0Ar@rawen> On Sunday, February 08, 2015 12:06:55 Ксения Боброва wrote: > Что в вашем понимании "сложное"? Мы писали небольшой прокси на AnyEvent, > несколько сотен строк кода. > Что касается альтернатив колбэкам, хотелось бы услышать поподробнее, что вы > имеете в виду. В нашем случае я не видела каких-то альтернатив. > Квалификация, разумеется, требуется. Но почему это должно стать > препятствием? Альтернатива коллбекам была бы треды, если б в Perl они были нормальные и вообще рабочие. В этом плане, надежда только на Perl6. -- PEF Developer From foxcool333 на gmail.com Sun Feb 8 09:38:38 2015 From: foxcool333 на gmail.com (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCk0L7QutGB0LrRg9C7?=) Date: Sun, 8 Feb 2015 21:38:38 +0400 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: <3554242.MnZySGtjuc@rawen> References: <3554242.MnZySGtjuc@rawen> Message-ID: Код - не самая исчерпывающая штука. Но сам считаю, что презентации и доклады слабо подходят для обсуждения технических тонкостей. Лучше обсуждать более общие темы, но при этом писать вики документации по всяким таким вещам. Текст лучше гуглится и правится - людям, столкнувшимся с конкретной проблемой будет проще найти ответы на вопросы в таких доках. Сам на докладах часто замечаю, что они зачастую являются просто способом засветиться или потешить задротское чсв докладчику. В несколько минут доклада не помещается реально полезное, а большинство слушателей не в теме на момент этого доклада. 08.02.2015 20:30 пользователь "PEF Secure" написал: > > On Sunday, February 08, 2015 16:52:34 Тимур Нозадзе wrote: > > > > Поддерживаю категорически! Особенно про внутренности всей этой асинхронщины > > давно хочется послушать. > > Не понимаю. Исходные коды AnyEvent/Coro лежат на CPAN, смотреть внутренности > можно лично, без пересказов. > -- > PEF Developer > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From onokonem на gmail.com Sun Feb 8 09:38:58 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Sun, 8 Feb 2015 21:38:58 +0400 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: <3554242.MnZySGtjuc@rawen> References: <3554242.MnZySGtjuc@rawen> Message-ID: > Не понимаю. Исходные коды AnyEvent/Coro лежат на CPAN, смотреть внутренности > можно лично, без пересказов. Есть люди, которые успешно пользуются AnyEvent/Coro/etc есть другие люди, которые думают, что это круто - успешно пользоваться AnyEvent/Coro/etc, и хотят научиться. и думают, что этому их могут научить те, первые люди. а есть третьи люди, вроде меня, которые об AnyEvent постучались лбом, и думают, что это круто, но пользоваться этим не надо. правда, хотите доклад на тему "перл - гоязык ограниченной применимости"? я прочту, хоть в питере, хоть в москве :) From bobrovaksenia на gmail.com Sun Feb 8 09:41:38 2015 From: bobrovaksenia на gmail.com (=?UTF-8?B?0JrRgdC10L3QuNGPINCR0L7QsdGA0L7QstCw?=) Date: Sun, 8 Feb 2015 18:41:38 +0100 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: <1448301.L8bfyLT0Ar@rawen> References: <19923524.20150208131028@softsearch.ru> <1448301.L8bfyLT0Ar@rawen> Message-ID: О том и речь, что в перле особо альтернатив нет)) Была бы джава, можно было бы не заморачиваться. А что касается "используйте подходящую под задачу языки" - полностью согласна, конечно, но только сначала надо найти проект, где вам разрешат использовать зоопарк инструментов на ваше усмотрение. Есть еще такое понятие как "исторически сложилось" и "у нас все знают хорошо только перл". Обычно добавление в проект не то что нового языка, но новых либ, может быть расценено как "разработчики опять хотят развлекаться вместо работы". 8 февраля 2015 г., 18:36 пользователь PEF Secure написал: > On Sunday, February 08, 2015 12:06:55 Ксения Боброва wrote: > > Что в вашем понимании "сложное"? Мы писали небольшой прокси на AnyEvent, > > несколько сотен строк кода. > > Что касается альтернатив колбэкам, хотелось бы услышать поподробнее, что > вы > > имеете в виду. В нашем случае я не видела каких-то альтернатив. > > Квалификация, разумеется, требуется. Но почему это должно стать > > препятствием? > > Альтернатива коллбекам была бы треды, если б в Perl они были нормальные и > вообще рабочие. В этом плане, надежда только на Perl6. > > -- > PEF Developer > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > -- Ksenia Bobrova Senior Perl Developer ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From foxcool333 на gmail.com Sun Feb 8 09:42:26 2015 From: foxcool333 на gmail.com (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCk0L7QutGB0LrRg9C7?=) Date: Sun, 8 Feb 2015 21:42:26 +0400 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: References: <3554242.MnZySGtjuc@rawen> Message-ID: Тред в рассылке той же был бы более полезным. 08.02.2015 20:40 пользователь "Daniel Podolsky" написал: > > Не понимаю. Исходные коды AnyEvent/Coro лежат на CPAN, смотреть > внутренности > > можно лично, без пересказов. > Есть люди, которые успешно пользуются AnyEvent/Coro/etc > > есть другие люди, которые думают, что это круто - успешно пользоваться > AnyEvent/Coro/etc, и хотят научиться. и думают, что этому их могут > научить те, первые люди. > > а есть третьи люди, вроде меня, которые об AnyEvent постучались лбом, > и думают, что это круто, но пользоваться этим не надо. > > правда, хотите доклад на тему "перл - гоязык > ограниченной применимости"? > > я прочту, хоть в питере, хоть в москве :) > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From onokonem на gmail.com Sun Feb 8 09:47:54 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Sun, 8 Feb 2015 21:47:54 +0400 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: References: <3554242.MnZySGtjuc@rawen> Message-ID: > Тред в рассылке той же был бы более полезным. перед аудиторией выступать интереснее :) From bobrovaksenia на gmail.com Sun Feb 8 09:48:46 2015 From: bobrovaksenia на gmail.com (=?UTF-8?B?0JrRgdC10L3QuNGPINCR0L7QsdGA0L7QstCw?=) Date: Sun, 8 Feb 2015 18:48:46 +0100 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: References: <3554242.MnZySGtjuc@rawen> Message-ID: Доклад вполне подходит для изложения технических тонкостей. Просто все привыкли ходить на митапы развлекаться, слушать что-нибудь в стиле капитана очевидность и холиварить. 8 февраля 2015 г., 18:42 пользователь Александр Фокскул < foxcool333 на gmail.com> написал: > Тред в рассылке той же был бы более полезным. > 08.02.2015 20:40 пользователь "Daniel Podolsky" > написал: > > > Не понимаю. Исходные коды AnyEvent/Coro лежат на CPAN, смотреть >> внутренности >> > можно лично, без пересказов. >> Есть люди, которые успешно пользуются AnyEvent/Coro/etc >> >> есть другие люди, которые думают, что это круто - успешно пользоваться >> AnyEvent/Coro/etc, и хотят научиться. и думают, что этому их могут >> научить те, первые люди. >> >> а есть третьи люди, вроде меня, которые об AnyEvent постучались лбом, >> и думают, что это круто, но пользоваться этим не надо. >> >> правда, хотите доклад на тему "перл - гоязык >> ограниченной применимости"? >> >> я прочту, хоть в питере, хоть в москве :) >> -- >> Moscow.pm mailing list >> moscow-pm на pm.org | http://moscow.pm.org >> > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > > -- Ksenia Bobrova Senior Perl Developer ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From akovbovich на gmail.com Sun Feb 8 09:49:36 2015 From: akovbovich на gmail.com (Andrey Kovbovich) Date: Sun, 8 Feb 2015 21:49:36 +0400 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: References: <3554242.MnZySGtjuc@rawen> Message-ID: А я бы послушал доклад на тему "как перестать писать асинхронный недетерминированный код и начать жить". воскресенье, 8 февраля 2015 г. пользователь Александр Фокскул написал: > Тред в рассылке той же был бы более полезным. > 08.02.2015 20:40 пользователь "Daniel Podolsky" > написал: > >> > Не понимаю. Исходные коды AnyEvent/Coro лежат на CPAN, смотреть >> внутренности >> > можно лично, без пересказов. >> Есть люди, которые успешно пользуются AnyEvent/Coro/etc >> >> есть другие люди, которые думают, что это круто - успешно пользоваться >> AnyEvent/Coro/etc, и хотят научиться. и думают, что этому их могут >> научить те, первые люди. >> >> а есть третьи люди, вроде меня, которые об AnyEvent постучались лбом, >> и думают, что это круто, но пользоваться этим не надо. >> >> правда, хотите доклад на тему "перл - гоязык >> ограниченной применимости"? >> >> я прочту, хоть в питере, хоть в москве :) >> -- >> Moscow.pm mailing list >> moscow-pm на pm.org | >> http://moscow.pm.org >> > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From aml на rulezz.ru Sun Feb 8 09:57:15 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Sun, 08 Feb 2015 17:57:15 +0000 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= References: <3554242.MnZySGtjuc@rawen> Message-ID: Так мир же недетерминированный. Пакеты по сети приходят, когда хотят. Иначе будет: "У нас тут детерминированный код, и пусть весь мир подождёт". On Sun Feb 08 2015 at 18:49:48 Andrey Kovbovich wrote: > А я бы послушал доклад на тему "как перестать писать асинхронный > недетерминированный код и начать жить". > > воскресенье, 8 февраля 2015 г. пользователь Александр Фокскул написал: > >> Тред в рассылке той же был бы более полезным. >> 08.02.2015 20:40 пользователь "Daniel Podolsky" >> написал: >> >>> > Не понимаю. Исходные коды AnyEvent/Coro лежат на CPAN, смотреть >>> внутренности >>> > можно лично, без пересказов. >>> Есть люди, которые успешно пользуются AnyEvent/Coro/etc >>> >>> есть другие люди, которые думают, что это круто - успешно пользоваться >>> AnyEvent/Coro/etc, и хотят научиться. и думают, что этому их могут >>> научить те, первые люди. >>> >>> а есть третьи люди, вроде меня, которые об AnyEvent постучались лбом, >>> и думают, что это круто, но пользоваться этим не надо. >>> >>> правда, хотите доклад на тему "перл - гоязык >>> ограниченной применимости"? >>> >>> я прочту, хоть в питере, хоть в москве :) >>> -- >>> Moscow.pm mailing list >>> moscow-pm на pm.org | http://moscow.pm.org >>> >> -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From foxcool333 на gmail.com Sun Feb 8 09:58:18 2015 From: foxcool333 на gmail.com (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCk0L7QutGB0LrRg9C7?=) Date: Sun, 8 Feb 2015 21:58:18 +0400 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: References: <3554242.MnZySGtjuc@rawen> Message-ID: Для того они по сути и нужны - удовлетворить желание пообщаться вживую с представителями своей профессии. Конструктивное общение априори текстовое - проще асинхронно обсуждать, приводить какие-то тезисы, получать контраргументы и т.д. В режиме доклада так не сделаешь - будет шум, поэтому докладчика перебивать нельзя или уточнять. Если кому-то хочется звука,можно загнать текст в генератор голоса и слушать: "Перл - говно азазазаза!" Это я все к тому, что доклады сильно односторонние. Почти как включить первый канал с петром простым и там идет доклад и обсуждение. Несут херню, а ответить телевизору - глупо. Хавай, что дают. В том же цикле вики-статей ошибки можно быстро править, субъективный мусор выбрасывать и т.д. 08.02.2015 20:49 пользователь "Ксения Боброва" написал: > > Доклад вполне подходит для изложения технических тонкостей. Просто все привыкли ходить на митапы развлекаться, слушать что-нибудь в стиле капитана очевидность и холиварить. > > 8 февраля 2015 г., 18:42 пользователь Александр Фокскул < foxcool333 на gmail.com> написал: > >> Тред в рассылке той же был бы более полезным. >> >> 08.02.2015 20:40 пользователь "Daniel Podolsky" написал: >> >>> > Не понимаю. Исходные коды AnyEvent/Coro лежат на CPAN, смотреть внутренности >>> > можно лично, без пересказов. >>> Есть люди, которые успешно пользуются AnyEvent/Coro/etc >>> >>> есть другие люди, которые думают, что это круто - успешно пользоваться >>> AnyEvent/Coro/etc, и хотят научиться. и думают, что этому их могут >>> научить те, первые люди. >>> >>> а есть третьи люди, вроде меня, которые об AnyEvent постучались лбом, >>> и думают, что это круто, но пользоваться этим не надо. >>> >>> правда, хотите доклад на тему "перл - гоязык >>> ограниченной применимости"? >>> >>> я прочту, хоть в питере, хоть в москве :) >>> -- >>> Moscow.pm mailing list >>> moscow-pm на pm.org | http://moscow.pm.org >> >> >> -- >> Moscow.pm mailing list >> moscow-pm на pm.org | http://moscow.pm.org >> > > > > -- > Ksenia Bobrova > Senior Perl Developer > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From foxcool333 на gmail.com Sun Feb 8 09:59:33 2015 From: foxcool333 на gmail.com (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCk0L7QutGB0LrRg9C7?=) Date: Sun, 8 Feb 2015 21:59:33 +0400 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: References: <3554242.MnZySGtjuc@rawen> Message-ID: Ага. В этом смысле асинхронный подход ближе к реальности. 08.02.2015 20:57 пользователь "Alexander Lourier" написал: > > Так мир же недетерминированный. Пакеты по сети приходят, когда хотят. Иначе будет: "У нас тут детерминированный код, и пусть весь мир подождёт". > > On Sun Feb 08 2015 at 18:49:48 Andrey Kovbovich wrote: >> >> А я бы послушал доклад на тему "как перестать писать асинхронный недетерминированный код и начать жить". >> >> воскресенье, 8 февраля 2015 г. пользователь Александр Фокскул написал: >>> >>> Тред в рассылке той же был бы более полезным. >>> >>> 08.02.2015 20:40 пользователь "Daniel Podolsky" написал: >>>> >>>> > Не понимаю. Исходные коды AnyEvent/Coro лежат на CPAN, смотреть внутренности >>>> > можно лично, без пересказов. >>>> Есть люди, которые успешно пользуются AnyEvent/Coro/etc >>>> >>>> есть другие люди, которые думают, что это круто - успешно пользоваться >>>> AnyEvent/Coro/etc, и хотят научиться. и думают, что этому их могут >>>> научить те, первые люди. >>>> >>>> а есть третьи люди, вроде меня, которые об AnyEvent постучались лбом, >>>> и думают, что это круто, но пользоваться этим не надо. >>>> >>>> правда, хотите доклад на тему "перл - гоязык >>>> ограниченной применимости"? >>>> >>>> я прочту, хоть в питере, хоть в москве :) >>>> -- >>>> Moscow.pm mailing list >>>> moscow-pm на pm.org | http://moscow.pm.org >> >> -- >> Moscow.pm mailing list >> moscow-pm на pm.org | http://moscow.pm.org > > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From onokonem на gmail.com Sun Feb 8 10:06:16 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Sun, 8 Feb 2015 22:06:16 +0400 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: References: <3554242.MnZySGtjuc@rawen> Message-ID: > Ага. В этом смысле асинхронный подход ближе к реальности. вам ближе к реальности или деньги зарабатывать? From bobrovaksenia на gmail.com Sun Feb 8 10:08:10 2015 From: bobrovaksenia на gmail.com (=?UTF-8?B?0JrRgdC10L3QuNGPINCR0L7QsdGA0L7QstCw?=) Date: Sun, 8 Feb 2015 19:08:10 +0100 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: References: <3554242.MnZySGtjuc@rawen> Message-ID: Человеку бывает гораздо проще сделать именно доклад и для ЧСВ полезнее. Писать тонны текста тупо лень - ради чего человек будет это делать? Пусть те кому надо потом переработают доклад в формат, который удобнее. Нормальные технические доклады - это хорошо. 8 февраля 2015 г., 18:58 пользователь Александр Фокскул < foxcool333 на gmail.com> написал: > Для того они по сути и нужны - удовлетворить желание пообщаться вживую с > представителями своей профессии. Конструктивное общение априори текстовое - > проще асинхронно обсуждать, приводить какие-то тезисы, получать > контраргументы и т.д. В режиме доклада так не сделаешь - будет шум, поэтому > докладчика перебивать нельзя или уточнять. Если кому-то хочется звука,можно > загнать текст в генератор голоса и слушать: "Перл - говно азазазаза!" Это я > все к тому, что доклады сильно односторонние. Почти как включить первый > канал с петром простым и там идет доклад и обсуждение. Несут херню, а > ответить телевизору - глупо. Хавай, что дают. В том же цикле вики-статей > ошибки можно быстро править, субъективный мусор выбрасывать и т.д. > 08.02.2015 20:49 пользователь "Ксения Боброва" > написал: > > > > > Доклад вполне подходит для изложения технических тонкостей. Просто все > привыкли ходить на митапы развлекаться, слушать что-нибудь в стиле капитана > очевидность и холиварить. > > > > 8 февраля 2015 г., 18:42 пользователь Александр Фокскул < > foxcool333 на gmail.com> написал: > > > >> Тред в рассылке той же был бы более полезным. > >> > >> 08.02.2015 20:40 пользователь "Daniel Podolsky" > написал: > >> > >>> > Не понимаю. Исходные коды AnyEvent/Coro лежат на CPAN, смотреть > внутренности > >>> > можно лично, без пересказов. > >>> Есть люди, которые успешно пользуются AnyEvent/Coro/etc > >>> > >>> есть другие люди, которые думают, что это круто - успешно пользоваться > >>> AnyEvent/Coro/etc, и хотят научиться. и думают, что этому их могут > >>> научить те, первые люди. > >>> > >>> а есть третьи люди, вроде меня, которые об AnyEvent постучались лбом, > >>> и думают, что это круто, но пользоваться этим не надо. > >>> > >>> правда, хотите доклад на тему "перл - гоязык > >>> ограниченной применимости"? > >>> > >>> я прочту, хоть в питере, хоть в москве :) > >>> -- > >>> Moscow.pm mailing list > >>> moscow-pm на pm.org | http://moscow.pm.org > >> > >> > >> -- > >> Moscow.pm mailing list > >> moscow-pm на pm.org | http://moscow.pm.org > >> > > > > > > > > -- > > Ksenia Bobrova > > Senior Perl Developer > > > > -- > > Moscow.pm mailing list > > moscow-pm на pm.org | http://moscow.pm.org > > > > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > > -- Ksenia Bobrova Senior Perl Developer ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From aml на rulezz.ru Sun Feb 8 10:24:31 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Sun, 08 Feb 2015 18:24:31 +0000 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= References: <3554242.MnZySGtjuc@rawen> Message-ID: > > > Ага. В этом смысле асинхронный подход ближе к реальности. > вам ближе к реальности или деньги зарабатывать? > Смотря чем зарабатывать. Есть много задач, где асинхронный код позволяет сильно сэкономить ресурсы серверов. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From onokonem на gmail.com Sun Feb 8 10:35:20 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Sun, 8 Feb 2015 22:35:20 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= Message-ID: о! собеседник! >> > Ага. В этом смысле асинхронный подход ближе к реальности. >> вам ближе к реальности или деньги зарабатывать? > Смотря чем зарабатывать. Есть много задач, где асинхронный код позволяет > сильно сэкономить ресурсы серверов. а вот давайте разберемся, какие именно ресурсы серверов позволяет сэкономить асинхронный код, и справедливо ли это утверждение для асинхронного кода на перле. изложите, пожалуйста, тезис об экономии подробнее. а то я так много об этом думал, что мгновенно начинаю с демонами в своей голове разговаривать, как об асинхронном перле речь заходит :( From postmaster на softsearch.ru Sun Feb 8 10:39:24 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sun, 8 Feb 2015 21:39:24 +0300 Subject: [Moscow.pm] =?koi8-r?b?0NLPINrPz9DB0ssg1MXIzs/Mz8fJyg==?= Message-ID: <807709452.20150208213924@softsearch.ru> Здравствуйте, Ксения. > А что касается "используйте подходящую под задачу языки" - полностью > согласна, конечно, но только сначала надо найти проект, где вам > разрешат использовать зоопарк инструментов на ваше усмотрение. Есть > еще такое понятие как "исторически сложилось" и "у нас все знают > хорошо только перл". Обычно добавление в проект не то что нового > языка, но новых либ, может быть расценено как "разработчики опять > хотят развлекаться вместо работы". Я у себя в фирме тоже всячески душил в зародыше попытки привнести что-то нестандартное. Ведь потом с этим будут только проблемы: разбирающийся в нестандартном, например, сменит работу, а вылезет какая-нить бага, и чтобы её исправить, придётся кучу новой информации быстро впитать, что не всегда получается. Например, писали модули под nginx, и так я с ними намучился: новые версии nginx-а выходят часто, модули требуют патчинга nginx-а, достаточной компетенции люди были не всегда доступны, а решение своими силами - куча времени на ветер. С другой стороны подход сильного сужения списка доступных технологий ущербен по описанным причинам. Не знаю даже, есть ли какой-то промежуточный вариант... У нас, например, все писали и на перле, а также с разной степенью отвращения на HTML, CSS, JavaScript, плюс запросы к MySQL. ИМХО, из JavaScript вполне легко вытекает для серверного программирования Node.js, например, чтобы писать какие-нить простые прототипы нового функционала. При необходимости можно и ещё что-нибудь притянуть: С, Lua, Go. Но есть ли такие люди, которые нормально пишут на куче языков? Или может ограничиться двумя-тремя... С БД и всем тем, что на них похоже, та же засада... -- С уважением, Михаил mailto:postmaster на softsearch.ru From chesnokov.ilya на gmail.com Sun Feb 8 10:40:49 2015 From: chesnokov.ilya на gmail.com (Ilya Chesnokov) Date: Sun, 8 Feb 2015 22:40:49 +0400 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: References: <19923524.20150208131028@softsearch.ru> Message-ID: 8 февраля 2015 г., 15:52 пользователь Тимур Нозадзе написал: >> Поддерживаю насчет AnyEvent. Еще хотелось бы про AnyEvent::Handle - более >> подробно про преимущества перед AnyEvent->io, производительность и вот это >> все. И про внутренности побольше. >> Еще нереально интересно было бы послушать про то как правильно >> организовывать код мало-мальски сложного асинхронного приложения. А то >> примеры хеллоуворлда на AnyEvent подзадолбали уже. > > Поддерживаю категорически! Особенно про внутренности всей этой асинхронщины > давно хочется послушать. Да ну нафиг)) Почитай код AnyEvent - там все написано) > 8 февраля 2015 г., 14:06 пользователь Ксения Боброва > написал: > >> Что в вашем понимании "сложное"? Мы писали небольшой прокси на AnyEvent, >> несколько сотен строк кода. >> Что касается альтернатив колбэкам, хотелось бы услышать поподробнее, что >> вы имеете в виду. В нашем случае я не видела каких-то альтернатив. >> Квалификация, разумеется, требуется. Но почему это должно стать >> препятствием? >> >> 8 февраля 2015 г., 11:10 пользователь Михаил Монашёв >> написал: >> >>> Здравствуйте, Ксения. >>> >>> > Еще нереально интересно было бы послушать про то как правильно >>> > организовывать код мало-мальски сложного асинхронного приложения. А >>> > то примеры хеллоуворлда на AnyEvent подзадолбали уже. >>> >>> Есть мнение, что более-менее сложное на колбэках писать можно, но >>> неудобно (долго писать, сложно сопровождать и отлаживать, требует >>> высокой квалификации и умения переключаться на "мыслить колбэками"), а >>> потому надо подыскивать альтернативы колбэкам, которые, кстати >>> существую. >>> >>> -- >>> С уважением, >>> Михаил mailto:postmaster на softsearch.ru >>> >>> -- >>> Moscow.pm mailing list >>> moscow-pm на pm.org | http://moscow.pm.org >> >> >> >> >> -- >> Ksenia Bobrova >> Senior Perl Developer >> >> -- >> Moscow.pm mailing list >> moscow-pm на pm.org | http://moscow.pm.org >> > > > > -- > С уважением, Тимур Нозадзе > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > -- Best regards, Ilya Chesnokov From bobrovaksenia на gmail.com Sun Feb 8 10:43:16 2015 From: bobrovaksenia на gmail.com (=?UTF-8?B?0JrRgdC10L3QuNGPINCR0L7QsdGA0L7QstCw?=) Date: Sun, 8 Feb 2015 19:43:16 +0100 Subject: [Moscow.pm] =?utf-8?b?0L/RgNC+INC30L7QvtC/0LDRgNC6INGC0LXRhdC9?= =?utf-8?b?0L7Qu9C+0LPQuNC5?= In-Reply-To: <807709452.20150208213924@softsearch.ru> References: <807709452.20150208213924@softsearch.ru> Message-ID: Мне кажется, нужно просто взять нормальный современный язык с хорошим комьюнити и без недостатка спецов (ту же Java) и не парить себе мозг. 8 февраля 2015 г., 19:39 пользователь Михаил Монашёв < postmaster на softsearch.ru> написал: > Здравствуйте, Ксения. > > > А что касается "используйте подходящую под задачу языки" - полностью > > согласна, конечно, но только сначала надо найти проект, где вам > > разрешат использовать зоопарк инструментов на ваше усмотрение. Есть > > еще такое понятие как "исторически сложилось" и "у нас все знают > > хорошо только перл". Обычно добавление в проект не то что нового > > языка, но новых либ, может быть расценено как "разработчики опять > > хотят развлекаться вместо работы". > > Я у себя в фирме тоже всячески душил в зародыше попытки привнести > что-то нестандартное. Ведь потом с этим будут только проблемы: > разбирающийся в нестандартном, например, сменит работу, а вылезет > какая-нить бага, и чтобы её исправить, придётся кучу новой информации > быстро впитать, что не всегда получается. Например, писали модули под > nginx, и так я с ними намучился: новые версии nginx-а выходят часто, > модули требуют патчинга nginx-а, достаточной компетенции люди были не > всегда доступны, а решение своими силами - куча времени на ветер. > > С другой стороны подход сильного сужения списка доступных технологий > ущербен по описанным причинам. Не знаю даже, есть ли какой-то > промежуточный вариант... > > У нас, например, все писали и на перле, а также с разной степенью > отвращения на HTML, CSS, JavaScript, плюс запросы к MySQL. ИМХО, из > JavaScript вполне легко вытекает для серверного программирования > Node.js, например, чтобы писать какие-нить простые прототипы нового > функционала. > > При необходимости можно и ещё что-нибудь притянуть: С, Lua, Go. Но > есть ли такие люди, которые нормально пишут на куче языков? Или может > ограничиться двумя-тремя... > > С БД и всем тем, что на них похоже, та же засада... > > -- > С уважением, > Михаил mailto:postmaster на softsearch.ru > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > -- Ksenia Bobrova Senior Perl Developer ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From pef-secure на yandex.ru Sun Feb 8 10:00:25 2015 From: pef-secure на yandex.ru (PEF Secure) Date: Sun, 08 Feb 2015 19:00:25 +0100 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: References: Message-ID: <8854513.V95ACoDWLW@rawen> On Sunday, February 08, 2015 21:49:36 Andrey Kovbovich wrote: > А я бы послушал доклад на тему "как перестать писать асинхронный > недетерминированный код и начать жить". Перейдите на яву. До версии 1.4 там даже неблокирующихся сокетов не было. -- PEF Developer From pef-secure на yandex.ru Sun Feb 8 09:56:56 2015 From: pef-secure на yandex.ru (PEF Secure) Date: Sun, 08 Feb 2015 18:56:56 +0100 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: References: <1448301.L8bfyLT0Ar@rawen> Message-ID: <2339251.8xmhKciQ2T@rawen> On Sunday, February 08, 2015 18:41:38 Ксения Боброва wrote: > О том и речь, что в перле особо альтернатив нет)) Была бы джава, можно было > бы не заморачиваться. Есть пре-форки. А бывает что пре-форк и в каждом процессе асинхронщина. Закат солнышка вручную, но это проще, чем всё переписывать на си... > А что касается "используйте подходящую под задачу языки" - полностью > согласна, конечно, но только сначала надо найти проект, где вам разрешат > использовать зоопарк инструментов на ваше усмотрение. Есть еще такое > понятие как "исторически сложилось" и "у нас все знают хорошо только перл". > Обычно добавление в проект не то что нового языка, но новых либ, может быть > расценено как "разработчики опять хотят развлекаться вместо работы". Из знания перла легко сделать знание любого другого языка. Вопрос: какого? Несколько раз думал про питон, затем про руби. В итоге, не вижу смысла пока. Если Perl6 запустят, то это вполне путь... -- PEF Developer From pef-secure на yandex.ru Sun Feb 8 09:52:02 2015 From: pef-secure на yandex.ru (PEF Secure) Date: Sun, 08 Feb 2015 18:52:02 +0100 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: References: <3554242.MnZySGtjuc@rawen> Message-ID: <1647639.T0zLtVilkl@rawen> On Sunday, February 08, 2015 21:38:58 Daniel Podolsky wrote: > правда, хотите доклад на тему "перл - гоязык > ограниченной применимости"? > > я прочту, хоть в питере, хоть в москве :) Любой инструмент имеет ограниченное применение, хоть микроскоп, хоть молоток. Если Вы расшибли лоб об AE, я хотел бы услышать, что именно не получилось. Так сказать, историю неуспеха. Сам я, вобщем, пре-форки предпочитаю, но у меня нет супер-пупер-хайлоада. Префорки решают вопросы с блокировками DBI... -- PEF Developer From pef-secure на yandex.ru Sun Feb 8 09:43:22 2015 From: pef-secure на yandex.ru (PEF Secure) Date: Sun, 08 Feb 2015 18:43:22 +0100 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: <19923524.20150208131028@softsearch.ru> References: <19923524.20150208131028@softsearch.ru> Message-ID: <2568912.XdEKZjtt8b@rawen> On Sunday, February 08, 2015 13:10:28 Михаил Монашёв wrote: > Есть мнение, что более-менее сложное на колбэках писать можно, но > неудобно (долго писать, сложно сопровождать и отлаживать, требует > высокой квалификации и умения переключаться на "мыслить колбэками"), а > потому надо подыскивать альтернативы колбэкам, которые, кстати > существую. В AnyEvent о многом уже подумали и _многие_ вещи можно писать почти линейно, оно само будет саспендить потоки в ожидании данных, переключаясь на другие нитки. Многие, но не все. Но это уже заметный шаг вперёд. На счёт альтернативы колбекам -- это, как я Вас понимаю, другой язык программирования, типа Go, да? Это как бы мимо темы списка, что ли... -- PEF Developer From pef-secure на yandex.ru Sun Feb 8 09:42:09 2015 From: pef-secure на yandex.ru (PEF Secure) Date: Sun, 08 Feb 2015 18:42:09 +0100 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: References: <3554242.MnZySGtjuc@rawen> Message-ID: <2960438.OHaXg9QB78@rawen> On Sunday, February 08, 2015 21:33:34 Victor Efimov wrote: > Тогда никакие доклады не нужны. Всё на CPAN есть. Не всё. Доклады могут быть полезными, когда раскрывают какие-то практические и/или философские моменты. А существующий код -- ну задайте по нему вопрос, если что-то не ясно. -- PEF Developer From chesnokov.ilya на gmail.com Sun Feb 8 10:46:37 2015 From: chesnokov.ilya на gmail.com (Ilya Chesnokov) Date: Sun, 8 Feb 2015 22:46:37 +0400 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: References: <19923524.20150208131028@softsearch.ru> <1448301.L8bfyLT0Ar@rawen> Message-ID: 8 февраля 2015 г., 20:41 пользователь Ксения Боброва написал: > О том и речь, что в перле особо альтернатив нет)) Была бы джава, можно было > бы не заморачиваться. > > А что касается "используйте подходящую под задачу языки" - полностью > согласна, конечно, но только сначала надо найти проект, где вам разрешат > использовать зоопарк инструментов на ваше усмотрение. Есть еще такое понятие > как "исторически сложилось" и "у нас все знают хорошо только перл". Кстати, имхо, последнее зачастую - одна из основных причин выбора того или иного языка для реализации проекта. > Обычно > добавление в проект не то что нового языка, но новых либ, может быть > расценено как "разработчики опять хотят развлекаться вместо работы". О да.... )))) Бизнес диктует свои суровые условия, мать его. > 8 февраля 2015 г., 18:36 пользователь PEF Secure > написал: > >> On Sunday, February 08, 2015 12:06:55 Ксения Боброва wrote: >> > Что в вашем понимании "сложное"? Мы писали небольшой прокси на AnyEvent, >> > несколько сотен строк кода. >> > Что касается альтернатив колбэкам, хотелось бы услышать поподробнее, что >> > вы >> > имеете в виду. В нашем случае я не видела каких-то альтернатив. >> > Квалификация, разумеется, требуется. Но почему это должно стать >> > препятствием? >> >> Альтернатива коллбекам была бы треды, если б в Perl они были нормальные и >> вообще рабочие. В этом плане, надежда только на Perl6. >> >> -- >> PEF Developer >> -- >> Moscow.pm mailing list >> moscow-pm на pm.org | http://moscow.pm.org > > > > > -- > Ksenia Bobrova > Senior Perl Developer > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > -- Best regards, Ilya Chesnokov From postmaster на softsearch.ru Sun Feb 8 10:47:21 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sun, 8 Feb 2015 21:47:21 +0300 Subject: [Moscow.pm] =?koi8-r?b?wdPJzsjSz87O2cogy8/EINDP2tfPzNHF1CDTyczY?= =?koi8-r?b?zs8g09zLz87PzcnU2CDSxdPV0tPZINPF0tfF0s/X?= In-Reply-To: References: Message-ID: <936264802.20150208214721@softsearch.ru> Здравствуйте, Daniel. >>> > Ага. В этом смысле асинхронный подход ближе к реальности. >>> вам ближе к реальности или деньги зарабатывать? >> Смотря чем зарабатывать. Есть много задач, где асинхронный код >> позволяет сильно сэкономить ресурсы серверов. > а вот давайте разберемся, какие именно ресурсы серверов позволяет > сэкономить асинхронный код, и справедливо ли это утверждение для > асинхронного кода на перле. Там один ресурс, который экономится: чем быстрее обрабатывается запрос, тем быстрее от освободит занимаемую под обработку память. Поэтому всё, что можно запустить параллельно, запускается параллельно. Но современные серверы имеют несколько ядер и хорошо было бы на эти ядра использовать параллельно, чтобы быстрее закончить обработку запроса, раскидав на разные ядра параллельно выполняемые обработчики частей запроса. Перл этого не нормально умеет. Node.js тоже нормально не умеет. Go умеет из коробки. -- С уважением, Михаил mailto:postmaster на softsearch.ru From chesnokov.ilya на gmail.com Sun Feb 8 10:50:00 2015 From: chesnokov.ilya на gmail.com (Ilya Chesnokov) Date: Sun, 8 Feb 2015 22:50:00 +0400 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: References: <3554242.MnZySGtjuc@rawen> Message-ID: 8 февраля 2015 г., 20:38 пользователь Daniel Podolsky написал: >> Не понимаю. Исходные коды AnyEvent/Coro лежат на CPAN, смотреть внутренности >> можно лично, без пересказов. > Есть люди, которые успешно пользуются AnyEvent/Coro/etc > > есть другие люди, которые думают, что это круто - успешно пользоваться > AnyEvent/Coro/etc, и хотят научиться. и думают, что этому их могут > научить те, первые люди. > > а есть третьи люди, вроде меня, которые об AnyEvent постучались лбом, > и думают, что это круто, но пользоваться этим не надо. > > правда, хотите доклад на тему "перл - гоязык > ограниченной применимости"? > > я прочту, хоть в питере, хоть в москве :) Тема провокационная, мне было бы интересно. -- Best regards, Ilya Chesnokov From chesnokov.ilya на gmail.com Sun Feb 8 10:50:57 2015 From: chesnokov.ilya на gmail.com (Ilya Chesnokov) Date: Sun, 8 Feb 2015 22:50:57 +0400 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: References: <3554242.MnZySGtjuc@rawen> Message-ID: 8 февраля 2015 г., 20:33 пользователь Victor Efimov написал: > 8 февраля 2015 г., 20:30 пользователь PEF Secure написал: >> On Sunday, February 08, 2015 16:52:34 Тимур Нозадзе wrote: >>> >>> Поддерживаю категорически! Особенно про внутренности всей этой асинхронщины >>> давно хочется послушать. >> >> Не понимаю. Исходные коды AnyEvent/Coro лежат на CPAN, смотреть внутренности >> можно лично, без пересказов. > > Тогда никакие доклады не нужны. Всё на CPAN есть. Тем не менее, подобный доклад смахивает на зачитывание манов вслух перед аудиторией. -- Best regards, Ilya Chesnokov From pef-secure на yandex.ru Sun Feb 8 10:56:10 2015 From: pef-secure на yandex.ru (PEF Secure) Date: Sun, 08 Feb 2015 19:56:10 +0100 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: References: Message-ID: <4313772.nGeHKfApF6@rawen> On Sunday, February 08, 2015 22:35:20 Daniel Podolsky wrote: > изложите, пожалуйста, тезис об экономии подробнее. а то я так много об > этом думал, что мгновенно начинаю с демонами в своей голове > разговаривать, как об асинхронном перле речь заходит :( Треды, вобщем, тоже можно сказать "асинхронная модель", просто реализуется на уровне ОС, а не приложения. Реализация асинхронной модели приложением позволяет использовать более эффективную в плане ресурсов процессора и памяти кооперативную многозадачность. Со всеми вопросами кооперации, конечно. Если хватает одного процесса, то ещё и вопросов о совместном доступе к ресурсам меньше. -- PEF Developer From onokonem на gmail.com Sun Feb 8 11:05:10 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Sun, 8 Feb 2015 23:05:10 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: <936264802.20150208214721@softsearch.ru> References: <936264802.20150208214721@softsearch.ru> Message-ID: 2015-02-08 21:47 GMT+03:00 Михаил Монашёв : > Там один ресурс, который экономится: чем быстрее обрабатывается > запрос, тем быстрее от освободит занимаемую под обработку память. > Поэтому всё, что можно запустить параллельно, запускается параллельно. Имею возразить и попросить уточнений :) 1) синхронная модель предполагает вытесняющую многозадачность, которая, в свою очередь, предполагает накладные расходы на переключение контекста. так что процессор тоже должен, типа, экономиться. ну или не тоже. 2) действительно ли кобек-ориентированное программирование позволяет обрабатывать запросы быстрее? а каким образом? From akovbovich на gmail.com Sun Feb 8 11:05:10 2015 From: akovbovich на gmail.com (Andrey Kovbovich) Date: Sun, 8 Feb 2015 23:05:10 +0400 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: <8854513.V95ACoDWLW@rawen> References: <8854513.V95ACoDWLW@rawen> Message-ID: Видимо придется самому готовить подобный доклад :) воскресенье, 8 февраля 2015 г. пользователь PEF Secure написал: > On Sunday, February 08, 2015 21:49:36 Andrey Kovbovich wrote: > > А я бы послушал доклад на тему "как перестать писать асинхронный > > недетерминированный код и начать жить". > > Перейдите на яву. До версии 1.4 там даже неблокирующихся сокетов не было. > -- > PEF Developer > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From onokonem на gmail.com Sun Feb 8 11:08:12 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Sun, 8 Feb 2015 23:08:12 +0400 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: <8854513.V95ACoDWLW@rawen> References: <8854513.V95ACoDWLW@rawen> Message-ID: > Перейдите на яву. До версии 1.4 там даже неблокирующихся сокетов не было. а они там и сегодня не нужны. From aml на rulezz.ru Sun Feb 8 11:11:55 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Sun, 08 Feb 2015 19:11:55 +0000 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= References: Message-ID: Экономится память, в первую очередь. Например фронтенд на каждый запрос ходит к медленному бэкенду и ждёт от него ответа. Вопрос, как организовать работу фронтенда. Если каждый запрос будет обрабатываться отдельным однопоточным не асинхронным процессом, то когда число одновременных запросов превысит число процессов, запросы начнут выстраиваться в очередь, что для пользователей означает тормоза. Решение в лоб - добавить число процессов. Но каждый из них потребляет память, которая не резиновая. Альтернативы - потоки, асинхронный код, либо и то и другое вместе. Потоки лучше, чем асинхронный код, потому что они будут выполняться на разных ядрах. Асинхронный код лучше тем, что не надо сохранять состояние процессора при переключении. В многопоточном коде надо заботиться о блокировках общих ресурсов, сложно разделять данные между потоками (общие пулы соединений к базе, общие кэши и т.д.) Самое эффективное - это и то, и то вместе, если оно правильно реализовано в самом языке. Иначе - это кромешный ад, с которым лучше не связываться. В Perl - именно такой случай. Асинхронный код - это имхо лучшее, чего можно добиться от перла. On Sun Feb 08 2015 at 19:35:28 Daniel Podolsky wrote: > о! собеседник! > > >> > Ага. В этом смысле асинхронный подход ближе к реальности. > >> вам ближе к реальности или деньги зарабатывать? > > Смотря чем зарабатывать. Есть много задач, где асинхронный код позволяет > > сильно сэкономить ресурсы серверов. > а вот давайте разберемся, какие именно ресурсы серверов позволяет > сэкономить асинхронный код, и справедливо ли это утверждение для > асинхронного кода на перле. > > изложите, пожалуйста, тезис об экономии подробнее. а то я так много об > этом думал, что мгновенно начинаю с демонами в своей голове > разговаривать, как об асинхронном перле речь заходит :( > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From onokonem на gmail.com Sun Feb 8 11:13:10 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Sun, 8 Feb 2015 23:13:10 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: <4313772.nGeHKfApF6@rawen> References: <4313772.nGeHKfApF6@rawen> Message-ID: > Реализация асинхронной модели приложением > позволяет использовать более эффективную в плане ресурсов процессора и памяти > кооперативную многозадачность. вот как раз этот тезис я и прошу развернуть! большая эффективность в плане ресурсов процессора - это только то самое переключение контекста? или что-то еще? большая эффективность в плане ресурсов памяти - откуда она берется? From eugene.toropov на gmail.com Sun Feb 8 11:15:26 2015 From: eugene.toropov на gmail.com (Eugene Toropov) Date: Sun, 8 Feb 2015 22:15:26 +0300 Subject: [Moscow.pm] =?windows-1251?b?4PHo7fXw7u3t++kg6u7kIO/u5+Lu6//l8iDx?= =?windows-1251?b?6Ov87e4g8f3q7u3u7Ojy/CDw5fHz8PH7IPHl8OLl8O7i?= In-Reply-To: References: <936264802.20150208214721@softsearch.ru> Message-ID: <39967E84-8DCC-49E3-9121-85FDDBA25078@gmail.com> Да ни фига там не быстрее, просто экономится память (и больше ничего, насколько я знаю), а в результате у nginx ?На 10 000 неактивных HTTP keep-alive соединений расходуется около 2.5M памяти? On 08 Feb 2015, at 22:05, Daniel Podolsky wrote: > 2015-02-08 21:47 GMT+03:00 Михаил Монашёв : >> Там один ресурс, который экономится: чем быстрее обрабатывается >> запрос, тем быстрее от освободит занимаемую под обработку память. >> Поэтому всё, что можно запустить параллельно, запускается параллельно. > Имею возразить и попросить уточнений :) > > 1) синхронная модель предполагает вытесняющую многозадачность, > которая, в свою очередь, предполагает накладные расходы на > переключение контекста. так что процессор тоже должен, типа, > экономиться. ну или не тоже. > > 2) действительно ли кобек-ориентированное программирование позволяет > обрабатывать запросы быстрее? а каким образом? > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org From aml на rulezz.ru Sun Feb 8 11:15:48 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Sun, 08 Feb 2015 19:15:48 +0000 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= References: <936264802.20150208214721@softsearch.ru> Message-ID: > > 1) синхронная модель предполагает вытесняющую многозадачность, > которая, в свою очередь, предполагает накладные расходы на > переключение контекста. так что процессор тоже должен, типа, > экономиться. ну или не тоже. > Не понял мысль. Вытесняющая многозадачность да - требует переключения контекста, это медленно. Чему вы возражаете? > 2) действительно ли кобек-ориентированное программирование позволяет > обрабатывать запросы быстрее? а каким образом? Новые приходящие клиенты не встают в очередь, если все процессы заняты обработкой других запросов, а начинают обрабатываться "немедленно". ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From onokonem на gmail.com Sun Feb 8 11:23:29 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Sun, 8 Feb 2015 23:23:29 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: References: <936264802.20150208214721@softsearch.ru> Message-ID: > Не понял мысль. Вытесняющая многозадачность да - требует переключения > контекста, это медленно. Чему вы возражаете? Михаил написал, что только память и экономится, а я возразил. > Новые приходящие клиенты не встают в очередь, если все процессы заняты > обработкой других запросов, а начинают обрабатываться "немедленно". конечно они встают в очередь, в event loop! From aml на rulezz.ru Sun Feb 8 11:24:42 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Sun, 08 Feb 2015 19:24:42 +0000 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= References: <936264802.20150208214721@softsearch.ru> <39967E84-8DCC-49E3-9121-85FDDBA25078@gmail.com> Message-ID: > > Да ни фига там не быстрее, просто экономится память (и больше ничего, > насколько я знаю), а в результате у nginx ?На 10 000 неактивных HTTP > keep-alive соединений расходуется около 2.5M памяти? > Есть ещё latency. Если у вас обработчик входящих запросов не CPU-bound, а (как обычно в веб-приложениях) только и делает, что ходит в memcached, базу и к другим сервисам, а потом формирует ответ и возвращает клиенту, то большую часть времени процесс валяет дурака и ждёт ответа. Он может в это время взять следующий запрос в обработку, что уменьшит общее время реакции системы. Если у вас синхронное приложение, то количество одновременно выполняемых запросов будет ограничено числом процессов, которое поместится в память. Пока новые запросы находят себе свободный процесс, они обрабатываются так же быстро (нет никакого преимущества у асинхронного кода). Но как только свободные процессы исчерпались, "синхронная" система резко начнёт тормозить, а асинхронная станет лишь чуть-чуть медленнее. Сорри за много буков. Вкратце, при равных затратах памяти асинхронное приложение под нагрузкой будет более быстрым. > > On 08 Feb 2015, at 22:05, Daniel Podolsky wrote: > > > 2015-02-08 21:47 GMT+03:00 Михаил Монашёв : > >> Там один ресурс, который экономится: чем быстрее обрабатывается > >> запрос, тем быстрее от освободит занимаемую под обработку память. > >> Поэтому всё, что можно запустить параллельно, запускается параллельно. > > Имею возразить и попросить уточнений :) > > > > 1) синхронная модель предполагает вытесняющую многозадачность, > > которая, в свою очередь, предполагает накладные расходы на > > переключение контекста. так что процессор тоже должен, типа, > > экономиться. ну или не тоже. > > > > 2) действительно ли кобек-ориентированное программирование позволяет > > обрабатывать запросы быстрее? а каким образом? > > -- > > Moscow.pm mailing list > > moscow-pm на pm.org | http://moscow.pm.org > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From onokonem на gmail.com Sun Feb 8 11:26:14 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Sun, 8 Feb 2015 23:26:14 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: <39967E84-8DCC-49E3-9121-85FDDBA25078@gmail.com> References: <936264802.20150208214721@softsearch.ru> <39967E84-8DCC-49E3-9121-85FDDBA25078@gmail.com> Message-ID: > Да ни фига там не быстрее, просто экономится память (и больше ничего, насколько я знаю), а в результате у nginx ?На 10 000 неактивных HTTP keep-alive соединений расходуется около 2.5M памяти? nginx - это очень для нашего разговора плохой пример. nginx это программа, которая ничего не делает! фактически, только передает указатели на буфера между системными вызовами... если нам нужна еще одна такая программа - да, асинхронное программирование рулит. если нет - нет. From aml на rulezz.ru Sun Feb 8 11:27:22 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Sun, 08 Feb 2015 19:27:22 +0000 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= References: <936264802.20150208214721@softsearch.ru> Message-ID: > > > Новые приходящие клиенты не встают в очередь, если все процессы заняты > > обработкой других запросов, а начинают обрабатываться "немедленно". > конечно они встают в очередь, в event loop! > Угу. Поэтому "немедленно" было в кавычках :) Конечно, встают в очередь. Только event loop запустится сразу после того, как закончится текущий небольшой блок работы (декодирование ответа, формирование запроса или формирование ответа) - и это намного быстрее, чем очередь синхронного процесса (которая будет разгребаться только когда будет полностью закончена обработка предыдущего запроса и будет снова вызван accept). ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From postmaster на softsearch.ru Sun Feb 8 11:31:13 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sun, 8 Feb 2015 22:31:13 +0300 Subject: [Moscow.pm] =?koi8-r?b?wdPJzsjSz87O2cogy8/EINDP2tfPzNHF1CDTyczY?= =?koi8-r?b?zs8g09zLz87PzcnU2CDSxdPV0tPZINPF0tfF0s/X?= In-Reply-To: References: <936264802.20150208214721@softsearch.ru> Message-ID: <1808037181.20150208223113@softsearch.ru> Здравствуйте, Daniel. >> Там один ресурс, который экономится: чем быстрее обрабатывается >> запрос, тем быстрее от освободит занимаемую под обработку память. >> Поэтому всё, что можно запустить параллельно, запускается >> параллельно. > Имею возразить и попросить уточнений :) > 1) синхронная модель предполагает вытесняющую многозадачность, > которая, в свою очередь, предполагает накладные расходы на > переключение контекста. так что процессор тоже должен, типа, > экономиться. ну или не тоже. Что такое переключение контекста? Если я правильно понимаю, то это значит засунуть все регистры процессора в оперативку, прочитать из памяти другие значения регистров и совершить переход на следующую задачу. Возможно оно чуть сложнее, точно не скажу. В любом случае это несравненно меньше по времени, чем выполнение даже небольшого кода на языке высокого уровня. И я удивлюсь, если кто-то в перле упёрся именно в это. Обычная проблема большинства кода - это очень неэффективное использование памяти: много выделяется того, чего не нужно, память не используется повторно, память используется хаотично и в большем количестве, чем реально необходимо и т.д. > 2) действительно ли кобек-ориентированное программирование позволяет > обрабатывать запросы быстрее? а каким образом? Пришёл запрос на выдачу странички. Надо сделать 30 запросов к мемкешеду, 20 к базе. С огромной вероятностью их не надо делать последовательно. Хотя в синхронном программировании все они делаются один за другим. В асинхронном мы имеем возможность запустить выполнение нескольких (не обязательно всех) запросов одновременно и обрабатывать их результаты по мере их прихода. Например, до того, как юзер прошёл авторизацию можно достать из мемкешеда список его френдов. Ведь скорее всего он пройдёт авторизацию и этот список нам понадобится. -- С уважением, Михаил mailto:postmaster на softsearch.ru From onokonem на gmail.com Sun Feb 8 11:31:35 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Sun, 8 Feb 2015 23:31:35 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: References: Message-ID: > Экономится память, в первую очередь. Но есть нюанс > Решение в > лоб - добавить число процессов. Но каждый из них потребляет память, которая > не резиновая. Если мы правильно написали программу - у нас на fork происходит CoW. в результате - свои у каждого процесса только буфера, которые все равно свои на каждое соединение. From eugene.toropov на gmail.com Sun Feb 8 11:34:04 2015 From: eugene.toropov на gmail.com (Eugene Toropov) Date: Sun, 8 Feb 2015 22:34:04 +0300 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC90L4=?= =?utf-8?b?0LzQuNGC0Ywg0YDQtdGB0YPRgNGB0Ysg0YHQtdGA0LLQtdGA0L7Qsg==?= In-Reply-To: References: <936264802.20150208214721@softsearch.ru> <39967E84-8DCC-49E3-9121-85FDDBA25078@gmail.com> Message-ID: <6A76C1C0-12AC-4E28-8F29-A26967AC9FDE@gmail.com> Согласен, просто хотел привести красивый пример :) Чем больше IO - тем больше выигрыш On 08 Feb 2015, at 22:26, Daniel Podolsky wrote: >> Да ни фига там не быстрее, просто экономится память (и больше ничего, насколько я знаю), а в результате у nginx ?На 10 000 неактивных HTTP keep-alive соединений расходуется около 2.5M памяти? > nginx - это очень для нашего разговора плохой пример. > > nginx это программа, которая ничего не делает! фактически, только > передает указатели на буфера между системными вызовами... > > если нам нужна еще одна такая программа - да, асинхронное > программирование рулит. если нет - нет. > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org From postmaster на softsearch.ru Sun Feb 8 11:35:55 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Sun, 8 Feb 2015 22:35:55 +0300 Subject: [Moscow.pm] =?koi8-r?b?wdPJzsjSz87O2cogy8/EINDP2tfPzNHF1CDTyczY?= =?koi8-r?b?zs8g09zLz87PzcnU2CDSxdPV0tPZINPF0tfF0s/X?= In-Reply-To: References: Message-ID: <562220220.20150208223555@softsearch.ru> Здравствуйте, Daniel. >> Решение в >> лоб - добавить число процессов. Но каждый из них потребляет память, которая >> не резиновая. > Если мы правильно написали программу - у нас на fork происходит CoW. в > результате - свои у каждого процесса только буфера, которые все равно > свои на каждое соединение. Расскажи это какому-нить Garbage Collector-у, который ведёт учёт количества ссылок :-) Он моментом убьёт весь выйгрыш от Copy on Write. -- С уважением, Михаил mailto:postmaster на softsearch.ru From onokonem на gmail.com Sun Feb 8 11:38:55 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Sun, 8 Feb 2015 23:38:55 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: <1808037181.20150208223113@softsearch.ru> References: <936264802.20150208214721@softsearch.ru> <1808037181.20150208223113@softsearch.ru> Message-ID: > Что такое переключение контекста? Это вероятный сброс кеша. Самое дорогое, что только бывает на современных процессорах... > И я удивлюсь, если кто-то в перле упёрся именно > в это. нет, у перла проблемы другие :) > Хотя в синхронном программировании все они делаются > один за другим. в современном синхронном программировании они все параллельно уходят на thread pool From aml на rulezz.ru Sun Feb 8 11:39:35 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Sun, 08 Feb 2015 19:39:35 +0000 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= References: Message-ID: > > > Решение в > > лоб - добавить число процессов. Но каждый из них потребляет память, > которая > > не резиновая. > Если мы правильно написали программу - у нас на fork происходит CoW. в > результате - свои у каждого процесса только буфера, которые все равно > свои на каждое соединение. > Тогда на каждый запрос надо устанавливать новое соединение с базой, с memcached, со всеми бэкендами. Практически полное отсутствие разделения ресурсов между процессами (например, каких-нибудь внутренних кэшей). ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From onokonem на gmail.com Sun Feb 8 11:40:27 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Sun, 8 Feb 2015 23:40:27 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: <562220220.20150208223555@softsearch.ru> References: <562220220.20150208223555@softsearch.ru> Message-ID: 2015-02-08 22:35 GMT+03:00 Михаил Монашёв : > Расскажи это какому-нить Garbage Collector-у, который ведёт учёт > количества ссылок :-) Он моментом убьёт весь выйгрыш от Copy on Write. если мы неправильно написали программу - так и будет... From aml на rulezz.ru Sun Feb 8 11:44:23 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Sun, 08 Feb 2015 19:44:23 +0000 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= References: <562220220.20150208223555@softsearch.ru> Message-ID: > > > Расскажи это какому-нить Garbage Collector-у, который ведёт учёт > > количества ссылок :-) Он моментом убьёт весь выйгрыш от Copy on Write. > если мы неправильно написали программу - так и будет... Хм, а как можно правильно написать на перле? Обращение к любой переменной любого модуля (даже read-only) насилует её счётчик ссылок, что приводит к немедленному копированию страницы. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From onokonem на gmail.com Sun Feb 8 11:44:55 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Sun, 8 Feb 2015 23:44:55 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: References: Message-ID: > Тогда на каждый запрос надо устанавливать новое соединение с базой, с > memcached, со всеми бэкендами. Практически полное отсутствие разделения > ресурсов между процессами (например, каких-нибудь внутренних кэшей). типа того, да но мы договорились, что не в памяти дело? From aml на rulezz.ru Sun Feb 8 11:53:48 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Sun, 08 Feb 2015 19:53:48 +0000 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= References: Message-ID: > > > Тогда на каждый запрос надо устанавливать новое соединение с базой, с > > memcached, со всеми бэкендами. Практически полное отсутствие разделения > > ресурсов между процессами (например, каких-нибудь внутренних кэшей). > типа того, да > > но мы договорились, что не в памяти дело? Угу, договорились, память сэкономили. Но слишком дорогой ценой по нагрузке на процессор и по latency. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From onokonem на gmail.com Sun Feb 8 11:55:10 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Sun, 8 Feb 2015 23:55:10 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: References: <562220220.20150208223555@softsearch.ru> Message-ID: > Хм, а как можно правильно написать на перле? Никак, конечно. правильно такие программы пишутся только на C но давайте вернемся к обсуждению тезиса "Есть много задач, где асинхронный код позволяет сильно сэкономить ресурсы серверов" по моему опыту - сильно не позволяет, и задач таких не много. From onokonem на gmail.com Sun Feb 8 11:59:45 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Sun, 8 Feb 2015 23:59:45 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: References: Message-ID: > Угу, договорились, память сэкономили. Но слишком дорогой ценой по нагрузке > на процессор и по latency. эту фразу я не понял если наша программа делает хоть что-нибудь, кроме пересовывания байтов между сокетами - и нагрузка на процессор и latency будут определяться совсем не моделью многозадачности. From aml на rulezz.ru Sun Feb 8 12:03:07 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Sun, 08 Feb 2015 20:03:07 +0000 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= References: <562220220.20150208223555@softsearch.ru> Message-ID: > > но давайте вернемся к обсуждению тезиса "Есть много задач, где > асинхронный код позволяет сильно сэкономить ресурсы серверов" > > по моему опыту - сильно не позволяет, и задач таких не много. > Давайте. А вы какие задачи решаете? Типичный веб (форумы, блоги, магазины) или что-то сильно другое? Я про онлайн-игры могу много рассказать. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From bobrovaksenia на gmail.com Sun Feb 8 12:07:41 2015 From: bobrovaksenia на gmail.com (=?UTF-8?B?0JrRgdC10L3QuNGPINCR0L7QsdGA0L7QstCw?=) Date: Sun, 8 Feb 2015 21:07:41 +0100 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: References: Message-ID: >>по моему опыту - сильно не позволяет, и задач таких не много. ну смешно же. любой демон, работающий с внешней средой. Повис при обращении к внешнему ресурсу и привет, а в очереди еще 1000 сообщений, требующих обработки. Поэтому нужно расплодить тысячу демонов, которые жрут оперативу. Асинхронный демон при этом продолжит обрабатывать очередь, работая в одном экземпляре. 8 февраля 2015 г., 20:59 пользователь Daniel Podolsky написал: > > Угу, договорились, память сэкономили. Но слишком дорогой ценой по > нагрузке > > на процессор и по latency. > эту фразу я не понял > > если наша программа делает хоть что-нибудь, кроме пересовывания байтов > между сокетами - и нагрузка на процессор и latency будут определяться > совсем не моделью многозадачности. > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > -- Ksenia Bobrova Senior Perl Developer ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From onokonem на gmail.com Sun Feb 8 12:09:38 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Mon, 9 Feb 2015 00:09:38 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: References: <562220220.20150208223555@softsearch.ru> Message-ID: > Давайте. А вы какие задачи решаете? Типичный веб (форумы, блоги, магазины) > или что-то сильно другое? Я про онлайн-игры могу много рассказать. Сейчас я, слава Богу, к этому всему отношения не имею. но весь прошлый год провел в тесном общении с rtb ssp на асинхронном перле. много клиентов, жесткие требования к latency. From aml на rulezz.ru Sun Feb 8 12:12:24 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Sun, 08 Feb 2015 20:12:24 +0000 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= References: Message-ID: > > > Угу, договорились, память сэкономили. Но слишком дорогой ценой по > нагрузке > > на процессор и по latency. > эту фразу я не понял > > если наша программа делает хоть что-нибудь, кроме пересовывания байтов > между сокетами - и нагрузка на процессор и latency будут определяться > совсем не моделью многозадачности. > Мы говорим про решение fork на каждый запрос, так? Это создаёт дополнительную нагрузку на CPU за счёт большого количества CoW в перле. С этим мы уже решили, что не перлом единым, и на C можно написать лучше. Дополнительная latency проистекает из факта, что на каждый запрос нам надо устанавливать новое соединение с базой данных, с memcached, с бэкендами. Это несколько RTT до каждого из них. Программа при этом может вполне делать что-то вычислительное, только оно может занимать например одну миллисекунду, а установить несколько соединений с бэкендами займёт 100 миллисекунд. Лучше, чтобы перейти на конкретные цифры, какую-нибудь конкретную задачу взять. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From onokonem на gmail.com Sun Feb 8 12:13:37 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Mon, 9 Feb 2015 00:13:37 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: References: Message-ID: 2015-02-08 23:07 GMT+03:00 Ксения Боброва : > ну смешно же. любой демон, работающий с внешней средой. ну, то есть, прокси. одну задачу придумали. а еще? отдельно, конечно, непонятно, зачем мы написали этот прокси на перле, но тут уж причины могут быть очень разные... From bobrovaksenia на gmail.com Sun Feb 8 12:20:25 2015 From: bobrovaksenia на gmail.com (=?UTF-8?B?0JrRgdC10L3QuNGPINCR0L7QsdGA0L7QstCw?=) Date: Sun, 8 Feb 2015 21:20:25 +0100 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: References: Message-ID: это не прокси, это демон обработки очереди. я говорю о том, с чем я работала. задача очень распространенная и у нее много применений. лучше скажите в каких задачах асинхронный подход по-вашему не работает, так будет конструктивнее. >>отдельно, конечно, непонятно, зачем мы написали этот прокси на перле, но тут уж причины могут быть очень разные... причины уже обсудили в другом треде. нельзя просто так взять и использовать тот язык, который тебе хочется. 8 февраля 2015 г., 21:13 пользователь Daniel Podolsky написал: > 2015-02-08 23:07 GMT+03:00 Ксения Боброва : > > ну смешно же. любой демон, работающий с внешней средой. > ну, то есть, прокси. одну задачу придумали. а еще? > > отдельно, конечно, непонятно, зачем мы написали этот прокси на перле, > но тут уж причины могут быть очень разные... > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > -- Ksenia Bobrova Senior Perl Developer ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From onokonem на gmail.com Sun Feb 8 12:21:28 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Mon, 9 Feb 2015 00:21:28 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: References: Message-ID: 2015-02-08 23:12 GMT+03:00 Alexander Lourier : > Лучше, чтобы перейти на конкретные цифры, какую-нибудь конкретную задачу > взять. а давайте! только вам прийдется эту задачу придумать - я на этом месте не очень в курсе производственных потребностей. я как раз golang собрался поизучать. я написал бы на nginx+apache+mod_perl, nginx+lua, groovy и golang (как раз собрался поизучать его) если задача не слишком сложная окажется, конечно... From aml на rulezz.ru Sun Feb 8 12:22:19 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Sun, 08 Feb 2015 20:22:19 +0000 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= References: Message-ID: > > > ну смешно же. любой демон, работающий с внешней средой. > ну, то есть, прокси. одну задачу придумали. а еще? > Почему обязательно прокси? Практически любое веб-приложение требует на каждый запрос аутентифицировать сессию, запросить данные у бэкендов (memcached, база, какие-то другие серверы), собрать шаблон, отправить обратно. Вычислительной нагрузки - кот наплакал (сформировать запросы, распарсить ответы, отрендерить шаблон, сформировать ответ). Но это не прокси, это полноценное приложение, которых большинство. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From aml на rulezz.ru Sun Feb 8 12:34:32 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Sun, 08 Feb 2015 20:34:32 +0000 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= References: <562220220.20150208223555@softsearch.ru> Message-ID: > > > Давайте. А вы какие задачи решаете? Типичный веб (форумы, блоги, > магазины) > > или что-то сильно другое? Я про онлайн-игры могу много рассказать. > Сейчас я, слава Богу, к этому всему отношения не имею. > > но весь прошлый год провел в тесном общении с rtb ssp на асинхронном > перле. много клиентов, жесткие требования к latency. > Это и правда весьма специфичная задача, для которой общие данные для всех соединений жизненно необходимы. Мне кажется (могу быть неправ), что вы наелись неудобного синтаксиса асинхронщины на перле (он и правда несъедобный), и поэтому и обходитесь без неё там, где это возможно, чтобы не переусложнять код. С чем я могу только согласиться. Дело в другом. Асинхронный код на большинстве задач даёт экономию ресурсов. И если язык позволяет записывать его ясно и лаконично (Stackless Python, Go, может ещё Perl Coro?), то надо эту возможность использовать. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From aml на rulezz.ru Sun Feb 8 12:36:37 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Sun, 08 Feb 2015 20:36:37 +0000 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= References: Message-ID: > > 2015-02-08 23:12 GMT+03:00 Alexander Lourier : > > Лучше, чтобы перейти на конкретные цифры, какую-нибудь конкретную задачу > > взять. > а давайте! только вам прийдется эту задачу придумать - я на этом месте > не очень в курсе производственных потребностей. > > я как раз golang собрался поизучать. я написал бы на > nginx+apache+mod_perl, nginx+lua, groovy и golang (как раз собрался > поизучать его) > > если задача не слишком сложная окажется, конечно... > Баннерная крутилка? Первое, что в голову пришло. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From postmaster на softsearch.ru Sun Feb 8 13:07:05 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Mon, 9 Feb 2015 00:07:05 +0300 Subject: [Moscow.pm] =?koi8-r?b?wdPJzsjSz87O2cogy8/EINDP2tfPzNHF1CDTyczY?= =?koi8-r?b?zs8g09zLz87PzcnU2CDSxdPV0tPZINPF0tfF0s/X?= In-Reply-To: References: Message-ID: <1365378031.20150209000705@softsearch.ru> Здравствуйте, Ксения. > лучше скажите в каких задачах асинхронный подход по-вашему не работает, так будет конструктивнее. Я придумал! Программу Hello world эффективнее писать синхронной. :-) Вообще, мне очень сильно кажется, что Daniel Podolsky - тролль, который не смотря на завтрашний понедельник, подналёг на пивко. :-)))) -- С уважением, Михаил mailto:postmaster на softsearch.ru From onokonem на gmail.com Sun Feb 8 13:30:23 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Mon, 9 Feb 2015 01:30:23 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: References: <562220220.20150208223555@softsearch.ru> Message-ID: 2015-02-08 23:34 GMT+03:00 Alexander Lourier : > Мне кажется (могу быть неправ), что вы наелись неудобного синтаксиса > асинхронщины на перле я на самом деле сисадмин, и на все на это гляжу с точки зрения эксплуатации. наелся я совсем не синтаксиса. наелся я того, как хреново это все работает, и как еще хуже отлаживается. From onokonem на gmail.com Sun Feb 8 13:31:59 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Mon, 9 Feb 2015 01:31:59 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: <1365378031.20150209000705@softsearch.ru> References: <1365378031.20150209000705@softsearch.ru> Message-ID: > Я придумал! Программу Hello world эффективнее писать синхронной. :-) Ну и кто тут троль? > Вообще, мне очень сильно кажется, что Daniel Podolsky - тролль, > который не смотря на завтрашний понедельник, подналёг на пивко. :-)))) это неделя гриппа с температурой 38 так проявляется. From aml на rulezz.ru Sun Feb 8 13:35:21 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Sun, 08 Feb 2015 21:35:21 +0000 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= References: <562220220.20150208223555@softsearch.ru> Message-ID: > > наелся я совсем не синтаксиса. наелся я того, как хреново это все > работает, и как еще хуже отлаживается. > Поделитесь? ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From onokonem на gmail.com Sun Feb 8 13:42:42 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Mon, 9 Feb 2015 01:42:42 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: References: Message-ID: 2015-02-08 23:20 GMT+03:00 Ксения Боброва : > лучше скажите в каких задачах асинхронный подход по-вашему не работает, так > будет конструктивнее. мой тезис, который я не хотел выдавать без обсуждения, потому что не хотел спорить опять сам с собой, состоит вот в чем: выигрыш, который нам якобы дает перловая асинхронщина, сильно преувеличен. есть задача(чи?) класса "прокси", условно говоря. тут, действительно, асинхронный подход дает значительную экономию. беда в том, что в таком раскладе нам эта экономия не нужна - ресурсов и так завались. то есть - все то же самое можно написать на mod_perl, и он съест существенно больше ресурсов, но все равно упрется не в ресурсы сервера, а в скорость других модулей системы. например - в сеть. там же, где начинается реальный хардкор и борьба за такты и биты - надо сразу уходить на другую vm, потому как на перловой даже профайлера годного нет. особенно для AnyEvent его нет... примерно так. From onokonem на gmail.com Sun Feb 8 13:43:36 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Mon, 9 Feb 2015 01:43:36 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: References: <562220220.20150208223555@softsearch.ru> Message-ID: >> наелся я совсем не синтаксиса. наелся я того, как хреново это все >> работает, и как еще хуже отлаживается. > Поделитесь? с удовольствием :) From victor на vsespb.ru Sun Feb 8 13:43:38 2015 From: victor на vsespb.ru (Victor Efimov) Date: Mon, 9 Feb 2015 01:43:38 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: References: Message-ID: 8 февраля 2015 г., 23:22 пользователь Alexander Lourier написал: >> > ну смешно же. любой демон, работающий с внешней средой. >> ну, то есть, прокси. одну задачу придумали. а еще? > > > Почему обязательно прокси? > > Практически любое веб-приложение требует на каждый запрос аутентифицировать > сессию, запросить данные у бэкендов (memcached, база, какие-то другие > серверы), собрать шаблон, отправить обратно. Вычислительной нагрузки - кот > наплакал (сформировать запросы, распарсить ответы, отрендерить шаблон, > сформировать ответ). Но это не прокси, это полноценное приложение, которых > большинство. Да, вот именно что большинство. Но не согласен, что в перечисленном выше списке вычислительной нагрузки - кот наплакал. Её много. Нельзя сделать такое приложение только асинхронным. Пока в каком-нибудь одном воркере будут вычисления, все остальные будут тупить. Соответственно придётся делать и fork, а внутри каждого unix процесса - асинхронный код. Что похоже на двойную работу ради экономии памяти. Имхо вообще асинхронные приложения мало где оправданы - это должно быть приложение либо блокирующеесся только вводом-выводом, либо то где хайлоад/много воркеров и разработка fork+AE+риск что Марк найдёт свой автобус хоть как-то выгоднее содержания дополнительных компов/памяти памяти (для "большинства задач" речь о выделении о покупке одной планки памяти в следующий апгрейд). Для остальных применений вижу AE лишним, и переоцененным. > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > From aml на rulezz.ru Sun Feb 8 14:14:00 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Sun, 08 Feb 2015 22:14:00 +0000 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= References: Message-ID: > > 8 февраля 2015 г., 23:22 пользователь Alexander Lourier > написал: > >> > ну смешно же. любой демон, работающий с внешней средой. > >> ну, то есть, прокси. одну задачу придумали. а еще? > > > > > > Почему обязательно прокси? > > > > Практически любое веб-приложение требует на каждый запрос > аутентифицировать > > сессию, запросить данные у бэкендов (memcached, база, какие-то другие > > серверы), собрать шаблон, отправить обратно. Вычислительной нагрузки - > кот > > наплакал (сформировать запросы, распарсить ответы, отрендерить шаблон, > > сформировать ответ). Но это не прокси, это полноценное приложение, > которых > > большинство. > > Да, вот именно что большинство. Но не согласен, что в перечисленном > выше списке вычислительной нагрузки - кот наплакал. Её много. > Нельзя сделать такое приложение только асинхронным. Пока в > каком-нибудь одном воркере будут вычисления, все остальные будут > тупить. > В перле - да. В общем случае - необязательно. В Go свободный тред из пула подхватит горутину и продолжит её выполнять. > Соответственно придётся делать и fork, а внутри каждого unix процесса > - асинхронный код. Что похоже на двойную работу ради экономии памяти. > Fork или threads - обязательно, чтобы загрузить все ядра процессора. Асинхронный код, чтобы использовать их более эффективно. > Имхо вообще асинхронные приложения мало где оправданы - это должно > быть приложение либо блокирующеесся только вводом-выводом, либо то где > хайлоад/много воркеров и разработка fork+AE+риск что Марк найдёт свой > автобус хоть как-то выгоднее содержания дополнительных компов/памяти > памяти (для "большинства задач" речь о выделении о покупке одной > планки памяти в следующий апгрейд). > Они оправданны, если имеет смысл экономить ресурсы. Если же эффект от экономии не оправдывает затрат времени разработчика, то конечно не надо. Планка в один сервер стоит дёшево. Если серверов 10, и планка нужна в каждый, это уже дороже. Если это арендованные серверы или облако, то намного дороже и каждый месяц. Если усилия разработчиков на разработку и поддержку асинхронного кода меньше, чем выгода от его внедрения, то ну его нафиг, конечно. Собственно, суть в том, что на перле писать и поддерживать асинхронный код - это боль. Поэтому нужна очень серьёзная экономия, чтобы этим заниматься. На Go (или даже Stackless Python) это совершенно естественно и бесплатно. Поэтому там даже вопрос так не стоит - конечно надо писать асинхронно. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From postmaster на softsearch.ru Sun Feb 8 14:46:10 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Mon, 9 Feb 2015 01:46:10 +0300 Subject: [Moscow.pm] =?koi8-r?b?wdPJzsjSz87O2cogy8/EINDP2tfPzNHF1CDTyczY?= =?koi8-r?b?zs8g09zLz87PzcnU2CDSxdPV0tPZINPF0tfF0s/X?= In-Reply-To: References: Message-ID: <903678147.20150209014610@softsearch.ru> Здравствуйте, Alexander. > Собственно, суть в том, что на перле писать и поддерживать > асинхронный код - это боль. Поэтому нужна очень серьёзная экономия, > чтобы этим заниматься. > > На Go (или даже Stackless Python) это совершенно естественно и > бесплатно. Поэтому там даже вопрос так не стоит - конечно надо > писать асинхронно. И надо заметить, что писать там асинхронно не сложно и не нужно ничего специально изучать. Просто пару буковок перед вызовом функции добавил и она запустится в горутине. :-) Вот тоже ссылочка грустная для Go, кстати: http://www.techempower.com/benchmarks/ -- С уважением, Михаил mailto:postmaster на softsearch.ru From aml на rulezz.ru Sun Feb 8 14:53:20 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Sun, 08 Feb 2015 22:53:20 +0000 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= References: <903678147.20150209014610@softsearch.ru> Message-ID: > > Вот тоже ссылочка грустная для Go, кстати: http://www.techempower.com/ > benchmarks/ Ну будет у тебя сериализация JSON делаться не 1% времени обработки запроса, а 2. Надо на реальных приложениях смотреть. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From onokonem на gmail.com Sun Feb 8 15:00:25 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Mon, 9 Feb 2015 03:00:25 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: <903678147.20150209014610@softsearch.ru> References: <903678147.20150209014610@softsearch.ru> Message-ID: 2015-02-09 1:46 GMT+03:00 Михаил Монашёв : > И надо заметить, что писать там асинхронно не сложно и не нужно ничего > специально изучать. Просто пару буковок перед вызовом функции добавил > и она запустится в горутине. :-) коллеги, а что вы называете "асинхронно"? запуск подпрограмм на тредпуле - это разве асинхронность? то есть - можно асинхронность здесь устроить, да. но не нужно - выигрыша не даст... From mons на cpan.org Sun Feb 8 17:11:48 2015 From: mons на cpan.org (Mons Anderson) Date: Mon, 9 Feb 2015 05:11:48 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: References: <903678147.20150209014610@softsearch.ru> Message-ID: Народ, я не осилил дочитать это всё до конца. А давайте-ка соберёмся и померяемся. Не в плане теории, а в плане конкретных чисел сравним разные языки, подходы и т.п. А то этот тредик уже попахивает. 2015-02-09 2:00 GMT+03:00 Daniel Podolsky : > 2015-02-09 1:46 GMT+03:00 Михаил Монашёв : >> И надо заметить, что писать там асинхронно не сложно и не нужно ничего >> специально изучать. Просто пару буковок перед вызовом функции добавил >> и она запустится в горутине. :-) > коллеги, а что вы называете "асинхронно"? > > запуск подпрограмм на тредпуле - это разве асинхронность? то есть - > можно асинхронность здесь устроить, да. но не нужно - выигрыша не > даст... > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org -- Best wishes, Vladimir V. Perepelitsa aka Mons Anderson , http://github.com/Mons From onokonem на gmail.com Sun Feb 8 17:31:27 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Mon, 9 Feb 2015 05:31:27 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: References: <903678147.20150209014610@softsearch.ru> Message-ID: > А давайте-ка соберёмся и померяемся. > Не в плане теории, а в плане конкретных чисел > сравним разные языки, подходы и т.п. я за From aml на rulezz.ru Sun Feb 8 22:34:23 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Mon, 09 Feb 2015 06:34:23 +0000 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= Message-ID: коллеги, а что вы называете "асинхронно"? запуск подпрограмм на тредпуле - это разве асинхронность? то есть - можно асинхронность здесь устроить, да. но не нужно - выигрыша не даст... В Go тредпул не такой, как обычно. Там треды сами достают из очереди планировщика горутины, ждущие исполнения, и выполняют их. Как только горутина блокируется на вводе/выводе из канала, тред сразу берет следующую задачу. Это настоящая асинхронность. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From aml на rulezz.ru Sun Feb 8 22:38:25 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Mon, 09 Feb 2015 06:38:25 +0000 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= References: <903678147.20150209014610@softsearch.ru> Message-ID: Народ, я не осилил дочитать это всё до конца. А давайте-ка соберёмся и померяемся. Не в плане теории, а в плане конкретных чисел сравним разные языки, подходы и т.п. А то этот тредик уже попахивает. Эх, я бы с удовольствием, только в Россию не собираюсь в ближайшее время. А что, правда попахивает? Мы вроде очень культурно на технические темы общаемся. Без флейма даже. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From snelius на tsu.ru Sun Feb 8 22:40:03 2015 From: snelius на tsu.ru (Anatoly Y) Date: Mon, 9 Feb 2015 12:40:03 +0600 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: References: Message-ID: Под асихнронностью (в данном контексте) всегда подразумевают операции IO и ничего больше. 2015-02-09 12:34 GMT+06:00 Alexander Lourier : > коллеги, а что вы называете "асинхронно"? > > запуск подпрограмм на тредпуле - это разве асинхронность? то есть - > можно асинхронность здесь устроить, да. но не нужно - выигрыша не > даст... > > > В Go тредпул не такой, как обычно. Там треды сами достают из очереди > планировщика горутины, ждущие исполнения, и выполняют их. Как только > горутина блокируется на вводе/выводе из канала, тред сразу берет следующую > задачу. Это настоящая асинхронность. > > > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From aml на rulezz.ru Sun Feb 8 22:52:45 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Mon, 09 Feb 2015 06:52:45 +0000 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= References: Message-ID: > > Под асихнронностью (в данном контексте) всегда подразумевают операции IO и > ничего больше. > Не обязательно. Можно и вычислительную задачу распараллелить на несколько ядер, а результат собирать асинхронно. Но это к веб-приложениям мало относится. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From worldmind на mail.ru Sun Feb 8 23:09:55 2015 From: worldmind на mail.ru (=?UTF-8?B?QWxleGV5IFNocnVi?=) Date: Mon, 09 Feb 2015 10:09:55 +0300 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC90L4=?= =?utf-8?b?0LzQuNGC0Ywg0YDQtdGB0YPRgNGB0Ysg0YHQtdGA0LLQtdGA0L7Qsg==?= In-Reply-To: <1365378031.20150209000705@softsearch.ru> References: <1365378031.20150209000705@softsearch.ru> Message-ID: <1423465795.744227691@f330.i.mail.ru> Скажу немного "в поддержку", по мне так действительно асинхронный код нужен ровно там где он нужен, а это по сути только взаимодействие с внешним миром - приём запросов извне, вызов кого-то по сети. У нас, например, в итоге все компоненты на одной машине взаимодействуют друг с другом через локальные очереди и т.к. те достаточно быстры (как у многих здесь они на редисе), то нет особой разницы синхронно или асинхронно они написаны - они никого не ждут (взял из очереди, повычислял, положил в очереди), а синхронный код писать попроще. Надо кого-то дёрнуть по http - положил в очередь соответствующему компоненту, а тот уже да, асинхронным должен быть однозначно, иначе нормально работать не будет. (либо при проблемах сети будет память съедать, либо при торможении одного из вызываемых будет стопориться всё) Понедельник, 09 февраля 2015, 0:07 +03:00 от Михаил Монашёв : > Вообще, мне очень сильно кажется, что Daniel Podolsky - тролль, -- Alexey Shrub From onokonem на gmail.com Sun Feb 8 23:37:00 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Mon, 9 Feb 2015 11:37:00 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: References: Message-ID: 2015-02-09 9:40 GMT+03:00 Anatoly Y : > Под асихнронностью (в данном контексте) всегда подразумевают операции IO и > ничего больше. не операции IO, конечно, а способ нашего кода получать их результаты. если результаты доступны в основном потоке выполнения сразу после операции - это синхронное программирование. если результаты приходят когда-нибудь потом, колбеком - асинхронное. так вот, если у нас есть хороший тред-пул - зачем нам асинхронное? From 0body0 на rambler.ru Sun Feb 8 23:44:58 2015 From: 0body0 на rambler.ru (=?KOI8-R?Q?=E1=CE=C1=D4=CF=CC=C9=CA_=E7=D2=C9=DB=C1=C5=D7?=) Date: Mon, 09 Feb 2015 10:44:58 +0300 Subject: [Moscow.pm] =?koi8-r?b?9MXN2SDEzNEgxM/LzMHEz9c=?= In-Reply-To: <1448301.L8bfyLT0Ar@rawen> References: <19923524.20150208131028@softsearch.ru> <1448301.L8bfyLT0Ar@rawen> Message-ID: <54D8657A.2050202@rambler.ru> 08.02.2015 20:36, PEF Secure пишет: > On Sunday, February 08, 2015 12:06:55 Ксения Боброва wrote: >> Что в вашем понимании "сложное"? Мы писали небольшой прокси на AnyEvent, >> несколько сотен строк кода. >> Что касается альтернатив колбэкам, хотелось бы услышать поподробнее, что вы >> имеете в виду. В нашем случае я не видела каких-то альтернатив. >> Квалификация, разумеется, требуется. Но почему это должно стать >> препятствием? > Альтернатива коллбекам была бы треды, если б в Perl они были нормальные и > вообще рабочие. В этом плане, надежда только на Perl6. > 1) было исследование программ на C, которое показывало, асинхронный код не проигрывает тредовому, и довольно часто при большой нагрузке оказывается быстрее. ( Кажется это была толстая зеленая книга) 2) За исключением патологических случаем fork по скорости сравним с threads. 3) Писать и отлаживать на AnyEvent + fork намного проще, чем на threads. Т.е. threads --- это технологический тупик. И если он есть это наверно хорошо, но лучше им не пользоваться. Выгоды от него ограниченные, а гемороя можно получить в разы больше. From onokonem на gmail.com Mon Feb 9 00:01:38 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Mon, 9 Feb 2015 12:01:38 +0400 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: <54D8657A.2050202@rambler.ru> References: <19923524.20150208131028@softsearch.ru> <1448301.L8bfyLT0Ar@rawen> <54D8657A.2050202@rambler.ru> Message-ID: > 1) было исследование программ на C, которое показывало, асинхронный код не > проигрывает тредовому, и довольно > часто при большой нагрузке оказывается быстрее. ( Кажется это была толстая > зеленая книга) > 2) За исключением патологических случаем fork по скорости сравним с threads. > 3) Писать и отлаживать на AnyEvent + fork намного проще, чем на threads. > > Т.е. threads --- это технологический тупик. > И если он есть это наверно хорошо, но лучше им не пользоваться. > Выгоды от него ограниченные, а гемороя можно получить в разы больше. А приведите, пожалуйста, хотя бы по паре аргументов в поддержку этих тезисов :) From 0body0 на rambler.ru Mon Feb 9 00:15:49 2015 From: 0body0 на rambler.ru (=?KOI8-R?Q?=E1=CE=C1=D4=CF=CC=C9=CA_=E7=D2=C9=DB=C1=C5=D7?=) Date: Mon, 09 Feb 2015 11:15:49 +0300 Subject: [Moscow.pm] =?koi8-r?b?wdPJzsjSz87O2cogy8/EINDP2tfPzNHF1CDTyczY?= =?koi8-r?b?zs8g09zLz87PzcnU2CDSxdPV0tPZINPF0tfF0s/X?= In-Reply-To: References: Message-ID: <54D86CB5.9010505@rambler.ru> 09.02.2015 1:14, Alexander Lourier пишет: > > Они оправданны, если имеет смысл экономить ресурсы. Если же эффект от > экономии не оправдывает затрат времени разработчика, то конечно не > надо. Планка в один сервер стоит дёшево. Если серверов 10, и планка > нужна в каждый, это уже дороже. Если это арендованные серверы или > облако, то намного дороже и каждый месяц. Если усилия разработчиков на > разработку и поддержку асинхронного кода меньше, чем выгода от его > внедрения, то ну его нафиг, конечно. > > Собственно, суть в том, что на перле писать и поддерживать асинхронный > код - это боль. Поэтому нужна очень серьёзная экономия, чтобы этим > заниматься. Не могу согласиться, Я свой код и Марк Лемоновский я свободно читаю. И мне даже немного нравиться. > > На Go (или даже Stackless Python) это совершенно естественно и > бесплатно. Поэтому там даже вопрос так не стоит - конечно надо писать > асинхронно. А вот про python так не скажу: больше боли, чем удовольствия, и тем более что это другой язык. Хотя Go более интересно, но по другому --- он прямо компиляется в машинный код. > > > > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From snelius на tsu.ru Mon Feb 9 00:17:42 2015 From: snelius на tsu.ru (snelius на tsu.ru) Date: Mon, 9 Feb 2015 14:17:42 +0600 Subject: [Moscow.pm] =?koi8-r?b?wdPJzsjSz87O2cogy8/EINDP2tfPzNHF1CDTyczY?= =?koi8-r?b?zs8g09zLz87PzcnU2CDSxdPV0tPZINPF0tfF0s/X?= In-Reply-To: References: Message-ID: <002101d04440$e0cecf70$a26c6e50$@tsu.ru> -----Original Message----- From: Moscow-pm [mailto:moscow-pm-bounces+snelius=tsu.ru на pm.org] On Behalf Of Daniel Podolsky Sent: Monday, February 09, 2015 1:37 PM To: Moscow.pm group Subject: Re: [Moscow.pm] асинхронный код позволяет сильно сэкономить ресурсы серверов 2015-02-09 9:40 GMT+03:00 Anatoly Y : > Под асихнронностью (в данном контексте) всегда подразумевают операции > IO и ничего больше. не операции IO, конечно, а способ нашего кода получать их результаты. Именно операции, если ждёте (блокируете всю работу) их выполнения это синхронность, если не ждёте это асинхронность. если результаты доступны в основном потоке выполнения сразу после операции - это синхронное программирование. Как только возникает вероятность ожидания получение результатов не контролируемое вами, то всё, выбирайте механизм обработки sync/async. если результаты приходят когда-нибудь потом, колбеком - асинхронное. Ну если уж совсем по "деревенски" говорить то да :) так вот, если у нас есть хороший тред-пул - зачем нам асинхронное? Да это вообще проблема личного выбора, будете вы сидеть и ждать на селекте или наплодите нити и будете ждать внутри них ожидая уже когда они там отработают вообще неважно чиста теоретически. Я в большинстве задач предпочитаю селект, потомучто на практике это гораздо эффективнее (быстрее). Нитям есть чем заняться в других задачах :) -- Moscow.pm mailing list moscow-pm на pm.org | http://moscow.pm.org From 0body0 на rambler.ru Mon Feb 9 00:22:39 2015 From: 0body0 на rambler.ru (=?KOI8-R?Q?=E1=CE=C1=D4=CF=CC=C9=CA_=E7=D2=C9=DB=C1=C5=D7?=) Date: Mon, 09 Feb 2015 11:22:39 +0300 Subject: [Moscow.pm] =?koi8-r?b?wdPJzsjSz87O2cogy8/EINDP2tfPzNHF1CDTyczY?= =?koi8-r?b?zs8g09zLz87PzcnU2CDSxdPV0tPZINPF0tfF0s/X?= In-Reply-To: References: <562220220.20150208223555@softsearch.ru> Message-ID: <54D86E4F.7000400@rambler.ru> 08.02.2015 22:44, Alexander Lourier пишет: > > > Расскажи это какому-нить Garbage Collector-у, который ведёт учёт > > количества ссылок :-) Он моментом убьёт весь выйгрыш от Copy on > Write. > если мы неправильно написали программу - так и будет... > > > Хм, а как можно правильно написать на перле? Обращение к любой > переменной любого модуля (даже read-only) насилует её счётчик ссылок, > что приводит к немедленному копированию страницы. 1) Ну не всякое обращение к любой переменной, только создание ссылки на нее и уничтожение ссылки. 2) Тело переменной(это касается в основном строк) лежит отдельно от счетчика ссылок. Пользуйтесь строками и будет вам счастье :) > > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From worldmind на mail.ru Sun Feb 8 23:26:19 2015 From: worldmind на mail.ru (=?UTF-8?B?QWxleGV5IFNocnVi?=) Date: Mon, 09 Feb 2015 10:26:19 +0300 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: References: Message-ID: <1423466779.86609318@f46.i.mail.ru> Троллинг: Идеальный доклад Монса выглядит так: "Дорогие перлияне, я (собрался с силами|устроил хакатон|взял в плен рабов) и зарелизил все свои крутые наработки на cpan, а именно: 1 ... 2 ... ... в итоге перл по всем параметрам обошёл все другие языки, а perl foundation выдало мне медаль! Ура!" :-) Суббота, 07 февраля 2015, 6:07 +04:00 от Mons Anderson : > Готов сделать доклад на интересную сообществу тему. > Напишите, плиз, про что было-бы интересно послушать. -- Alexey Shrub From onokonem на gmail.com Mon Feb 9 00:37:18 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Mon, 9 Feb 2015 12:37:18 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: <002101d04440$e0cecf70$a26c6e50$@tsu.ru> References: <002101d04440$e0cecf70$a26c6e50$@tsu.ru> Message-ID: 2015-02-09 11:17 GMT+03:00 : > Я в большинстве задач > предпочитаю селект, потомучто на практике это гораздо эффективнее (быстрее) Это еще один тезис, к которому я бы хотел увидеть аргументы :) не потому, что я хочу поспорить - я могу пообещать НЕ спорить. я хочу уже понять, от чего эта идея так в народе популярна... From denis.fedoseev на gmail.com Mon Feb 9 00:44:10 2015 From: denis.fedoseev на gmail.com (Denis Fedoseev) Date: Mon, 9 Feb 2015 12:44:10 +0400 Subject: [Moscow.pm] =?utf-8?b?0L/RgNC+INC30L7QvtC/0LDRgNC6INGC0LXRhdC9?= =?utf-8?b?0L7Qu9C+0LPQuNC5?= In-Reply-To: References: <807709452.20150208213924@softsearch.ru> Message-ID: Как сотрудник конторы где половина продакшен софта на Java - могу сказать только "бугага". On Feb 8, 2015 10:44 PM, "Ксения Боброва" wrote: > Мне кажется, нужно просто взять нормальный современный язык с хорошим > комьюнити и без недостатка спецов (ту же Java) и не парить себе мозг. > > 8 февраля 2015 г., 19:39 пользователь Михаил Монашёв < > postmaster на softsearch.ru> написал: > >> Здравствуйте, Ксения. >> >> > А что касается "используйте подходящую под задачу языки" - полностью >> > согласна, конечно, но только сначала надо найти проект, где вам >> > разрешат использовать зоопарк инструментов на ваше усмотрение. Есть >> > еще такое понятие как "исторически сложилось" и "у нас все знают >> > хорошо только перл". Обычно добавление в проект не то что нового >> > языка, но новых либ, может быть расценено как "разработчики опять >> > хотят развлекаться вместо работы". >> >> Я у себя в фирме тоже всячески душил в зародыше попытки привнести >> что-то нестандартное. Ведь потом с этим будут только проблемы: >> разбирающийся в нестандартном, например, сменит работу, а вылезет >> какая-нить бага, и чтобы её исправить, придётся кучу новой информации >> быстро впитать, что не всегда получается. Например, писали модули под >> nginx, и так я с ними намучился: новые версии nginx-а выходят часто, >> модули требуют патчинга nginx-а, достаточной компетенции люди были не >> всегда доступны, а решение своими силами - куча времени на ветер. >> >> С другой стороны подход сильного сужения списка доступных технологий >> ущербен по описанным причинам. Не знаю даже, есть ли какой-то >> промежуточный вариант... >> >> У нас, например, все писали и на перле, а также с разной степенью >> отвращения на HTML, CSS, JavaScript, плюс запросы к MySQL. ИМХО, из >> JavaScript вполне легко вытекает для серверного программирования >> Node.js, например, чтобы писать какие-нить простые прототипы нового >> функционала. >> >> При необходимости можно и ещё что-нибудь притянуть: С, Lua, Go. Но >> есть ли такие люди, которые нормально пишут на куче языков? Или может >> ограничиться двумя-тремя... >> >> С БД и всем тем, что на них похоже, та же засада... >> >> -- >> С уважением, >> Михаил mailto:postmaster на softsearch.ru >> >> -- >> Moscow.pm mailing list >> moscow-pm на pm.org | http://moscow.pm.org >> > > > > -- > Ksenia Bobrova > Senior Perl Developer > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From snelius на tsu.ru Mon Feb 9 00:47:13 2015 From: snelius на tsu.ru (snelius на tsu.ru) Date: Mon, 9 Feb 2015 14:47:13 +0600 Subject: [Moscow.pm] =?koi8-r?b?wdPJzsjSz87O2cogy8/EINDP2tfPzNHF1CDTyczY?= =?koi8-r?b?zs8g09zLz87PzcnU2CDSxdPV0tPZINPF0tfF0s/X?= In-Reply-To: References: <002101d04440$e0cecf70$a26c6e50$@tsu.ru> Message-ID: <002d01d04445$00a4fff0$01eeffd0$@tsu.ru> Ну вообще это следует просто из механизмов работы нитей :) (Это ведь и отдельный контекст хоть и проще чем у процесса, хотя в Linux это всё ужасно. И отдельная задача для планировщика и ещё много всяких ньюансов, если даже не брать в расчёт первичное время на их создание. А ещё за ними надо следить, пул нужно уменьшать или увеличивать, вычитывать состояние, забодится о синхронизации, мутексы, переменные состояния и ещё тысяча вещей). Они конечно незаменимы, но для IO я всё-таки предпочту "селект" если это будет возможно. Можно конечно заморочиться и написать какие-то тесты. Но вообще грубо если уж брать, то можно (не самом деле нельзя конечно) сравнить apache (worker mode) и тот же nginx. Последний написан на "селекте", первый по классической модели тредпулов. Nginx способен не особо напрягаясь обрабатывать десятки тысяч соединений. Апачу для этих целей надо значительно больше ресурсов. Ради интереса можно всё-таки написать тесты на Си и закрыть уже этот вопрос чёрт возьми ) -----Original Message----- From: Moscow-pm [mailto:moscow-pm-bounces+snelius=tsu.ru на pm.org] On Behalf Of Daniel Podolsky Sent: Monday, February 09, 2015 2:37 PM To: Moscow.pm group Subject: Re: [Moscow.pm] асинхронный код позволяет сильно сэкономить ресурсы серверов 2015-02-09 11:17 GMT+03:00 : > Я в большинстве задач > предпочитаю селект, потомучто на практике это гораздо эффективнее > (быстрее) Это еще один тезис, к которому я бы хотел увидеть аргументы :) не потому, что я хочу поспорить - я могу пообещать НЕ спорить. я хочу уже понять, от чего эта идея так в народе популярна... -- Moscow.pm mailing list moscow-pm на pm.org | http://moscow.pm.org From 0body0 на rambler.ru Mon Feb 9 00:57:58 2015 From: 0body0 на rambler.ru (=?KOI8-R?Q?=E1=CE=C1=D4=CF=CC=C9=CA_=E7=D2=C9=DB=C1=C5=D7?=) Date: Mon, 09 Feb 2015 11:57:58 +0300 Subject: [Moscow.pm] =?koi8-r?b?9MXN2SDEzNEgxM/LzMHEz9c=?= In-Reply-To: References: <19923524.20150208131028@softsearch.ru> <1448301.L8bfyLT0Ar@rawen> <54D8657A.2050202@rambler.ru> Message-ID: <54D87696.6090201@rambler.ru> 09.02.2015 11:01, Daniel Podolsky пишет: >> 1) было исследование программ на C, которое показывало, асинхронный код не >> проигрывает тредовому, и довольно >> часто при большой нагрузке оказывается быстрее. ( Кажется это была толстая >> зеленая книга) >> 2) За исключением патологических случаем fork по скорости сравним с threads. >> 3) Писать и отлаживать на AnyEvent + fork намного проще, чем на threads. >> >> Т.е. threads --- это технологический тупик. >> И если он есть это наверно хорошо, но лучше им не пользоваться. >> Выгоды от него ограниченные, а гемороя можно получить в разы больше. > А приведите, пожалуйста, хотя бы по паре аргументов в поддержку этих тезисов :) 1) Создание потоков и процессом в Линуксе делается одним вызовом (clone) разница только в копировании адресного пространства при создании процесса, а внутри они ничем не различаются, кроме адресного пространства. Если процесс поток/процесс живет довольно долго, то разницу в накладных расходов при создании процесса можно пренебречь 2) При большом количестве потоков у ядра вырастают накладные расходы на переключение потоков. В случае большой нагрузки вообще говоря количество потоков вырастает(threads), а в случае асинхронной программы это количесто не меняется, поэтому асинхронная модель будет выигрывать за счет накладных расходов ядра системы. 3) Асинхронная программа это однопоточная программа. А поскольку отлаживать однопоточную программу проще чем многопоточную, то и отлаживать асинхронную программу легче, чем программу с потоками. 4) В асинхронной программе не нужны средства синхронизации потоков(Из-за многопоточности), которые просто необходимы в потоках. Накладные расходы на синхронизацию не ускоряют поточные программы и иногда могут быть просто чудовищными. 100-200 циклов процессора минимум на одном примитиве. Слегка не в тему, но для полноты 5) forkи проще концептуально и приводят к меньшему количеству ошибок в программировании, значит отлаживать будет меньше. From 0body0 на rambler.ru Mon Feb 9 01:06:33 2015 From: 0body0 на rambler.ru (=?KOI8-R?Q?=E1=CE=C1=D4=CF=CC=C9=CA_=E7=D2=C9=DB=C1=C5=D7?=) Date: Mon, 09 Feb 2015 12:06:33 +0300 Subject: [Moscow.pm] =?koi8-r?b?wdPJzsjSz87O2cogy8/EINDP2tfPzNHF1CDTyczY?= =?koi8-r?b?zs8g09zLz87PzcnU2CDSxdPV0tPZINPF0tfF0s/X?= In-Reply-To: References: <002101d04440$e0cecf70$a26c6e50$@tsu.ru> Message-ID: <54D87899.7010906@rambler.ru> 09.02.2015 11:37, Daniel Podolsky пишет: > 2015-02-09 11:17 GMT+03:00 : >> Я в большинстве задач >> предпочитаю селект, потомучто на практике это гораздо эффективнее (быстрее) > Это еще один тезис, к которому я бы хотел увидеть аргументы :) Можешь посмотреть Marc Lehmann у него было тесты для select, kqueue, и т.д. Скорее всего это не то, что тебе нужно, но что мешает сделать свои и увидеть на хомячковых задачах async, fork, threads это одно и тоже :) Можешь сравнить AnyEvent::HTTP и LWP. Первый ощутимо и даже видно на глаз. > > не потому, что я хочу поспорить - я могу пообещать НЕ спорить. я хочу > уже понять, от чего эта идея так в народе популярна... From dmitry на eremeev.ru Mon Feb 9 01:14:33 2015 From: dmitry на eremeev.ru (Dmitry Eremeev) Date: Mon, 9 Feb 2015 12:14:33 +0300 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC90L4=?= =?utf-8?b?0LzQuNGC0Ywg0YDQtdGB0YPRgNGB0Ysg0YHQtdGA0LLQtdGA0L7Qsg==?= In-Reply-To: <54D87899.7010906@rambler.ru> References: <002101d04440$e0cecf70$a26c6e50$@tsu.ru> <54D87899.7010906@rambler.ru> Message-ID: Чуваки, вы вообще работаете когда-нибудь? --  Yours Dmitry Eremeev CEO adPremium Russia / office: +7 499 703 32 07 UK / office: +44 870 295 24 46 Skype: eremeev.ru https://linkedin.com/in/dimkae https://facebook.com/dimkae On 9 февраля 2015 г. at 12:07:46, Анатолий Гришаев (0body0 на rambler.ru) wrote: 09.02.2015 11:37, Daniel Podolsky пишет: > 2015-02-09 11:17 GMT+03:00 : >> Я в большинстве задач >> предпочитаю селект, потомучто на практике это гораздо эффективнее (быстрее) > Это еще один тезис, к которому я бы хотел увидеть аргументы :) Можешь посмотреть Marc Lehmann у него было тесты для select, kqueue, и т.д. Скорее всего это не то, что тебе нужно, но что мешает сделать свои и увидеть на хомячковых задачах async, fork, threads это одно и тоже :) Можешь сравнить AnyEvent::HTTP и LWP. Первый ощутимо и даже видно на глаз. > > не потому, что я хочу поспорить - я могу пообещать НЕ спорить. я хочу > уже понять, от чего эта идея так в народе популярна... -- Moscow.pm mailing list moscow-pm на pm.org | http://moscow.pm.org ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From v.perepelitsa на corp.mail.ru Mon Feb 9 01:11:23 2015 From: v.perepelitsa на corp.mail.ru (Mons Anderson) Date: Mon, 9 Feb 2015 12:11:23 +0300 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: <2568912.XdEKZjtt8b@rawen> References: <19923524.20150208131028@softsearch.ru> <2568912.XdEKZjtt8b@rawen> Message-ID: <2036D7A8-A6BA-47AC-9F87-F67D1C0C2D34@corp.mail.ru> > On 8 февр. 2015 г., at 20:43, PEF Secure wrote: > > On Sunday, February 08, 2015 13:10:28 Михаил Монашёв wrote: >> Есть мнение, что более-менее сложное на колбэках писать можно, но >> неудобно (долго писать, сложно сопровождать и отлаживать, требует >> высокой квалификации и умения переключаться на "мыслить колбэками"), а >> потому надо подыскивать альтернативы колбэкам, которые, кстати >> существую. > > В AnyEvent о многом уже подумали и _многие_ вещи можно писать почти линейно, > оно само будет саспендить потоки в ожидании данных, переключаясь на другие > нитки. Многие, но не все. Но это уже заметный шаг вперёд. Вы не путаете-ли с Coro? Никто не за кого не думал и никакие потоки там не усыпляются, т.к. их нет. > > На счёт альтернативы колбекам -- это, как я Вас понимаю, другой язык > программирования, типа Go, да? Это как бы мимо темы списка, что ли... > -- > PEF Developer > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org -- Mons Anderson ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From v.perepelitsa на corp.mail.ru Mon Feb 9 01:23:24 2015 From: v.perepelitsa на corp.mail.ru (Mons Anderson) Date: Mon, 9 Feb 2015 12:23:24 +0300 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC90L4=?= =?utf-8?b?0LzQuNGC0Ywg0YDQtdGB0YPRgNGB0Ysg0YHQtdGA0LLQtdGA0L7Qsg==?= In-Reply-To: <54D87899.7010906@rambler.ru> References: <002101d04440$e0cecf70$a26c6e50$@tsu.ru> <54D87899.7010906@rambler.ru> Message-ID: > > On 9 февр. 2015 г., at 12:06, Анатолий Гришаев <0body0 на rambler.ru> wrote: > > 09.02.2015 11:37, Daniel Podolsky пишет: >> 2015-02-09 11:17 GMT+03:00 : >>> Я в большинстве задач >>> предпочитаю селект, потомучто на практике это гораздо эффективнее (быстрее) >> Это еще один тезис, к которому я бы хотел увидеть аргументы :) > Можешь посмотреть Marc Lehmann у него было тесты для select, kqueue, и т.д. > Скорее всего это не то, что тебе нужно, но что мешает сделать свои и увидеть на хомячковых задачах > async, fork, threads это одно и тоже :) > > Можешь сравнить AnyEvent::HTTP и LWP. Первый ощутимо и даже видно на глаз. 1. глаз в этой задаче плохой измерительный прибор измерительный прибор здесь - wallclock time / cpu time / consumed memory 2. LWP - это пример ужасного кода, который обрастал десятилетиями. можно взять и перевести код AE::HTTP на синхронку и тогда сравнивать. 3. Разница между синхронным и асинхронным кодом становится видна только тогда, когда накладные расходы от планировщика OS начинают быть значимо заметными. т.е. на 100rps вы не заметите разницы между префорком с синхронным кодом и асинхронным (ну разве что LA системы на синхронном будет побольше) а вот если это 1000+ rps или ещё того хуже - 10k+ висящих постоянных соединений >> >> не потому, что я хочу поспорить - я могу пообещать НЕ спорить. я хочу >> уже понять, от чего эта идея так в народе популярна... > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org -- Mons Anderson ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From onokonem на gmail.com Mon Feb 9 01:24:55 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Mon, 9 Feb 2015 13:24:55 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: <002d01d04445$00a4fff0$01eeffd0$@tsu.ru> References: <002101d04440$e0cecf70$a26c6e50$@tsu.ru> <002d01d04445$00a4fff0$01eeffd0$@tsu.ru> Message-ID: > Nginx способен не особо напрягаясь обрабатывать десятки тысяч соединений. > Апачу для этих целей надо значительно больше ресурсов. зато апач способен выполнять полезную работу, а nginx может только перекладывать байты из одной трубы в другую. это я не про спорить, я про неадекватность сравнения :) nginx - клевая софтина, и без нее веб-хайлоад представить себе сегодня трудно, но роль его - роль кеша записи. > Ради интереса можно всё-таки написать тесты на Си и закрыть уже этот вопрос > чёрт возьми ) Я вот не уверен, что тесты эти надо на Си написать. Мы же все остальное, что собираемся писать, не собираемся писать на Си, правда? ;) From snelius на tsu.ru Mon Feb 9 01:36:59 2015 From: snelius на tsu.ru (snelius на tsu.ru) Date: Mon, 9 Feb 2015 15:36:59 +0600 Subject: [Moscow.pm] =?koi8-r?b?wdPJzsjSz87O2cogy8/EINDP2tfPzNHF1CDTyczY?= =?koi8-r?b?zs8g09zLz87PzcnU2CDSxdPV0tPZINPF0tfF0s/X?= In-Reply-To: References: <002101d04440$e0cecf70$a26c6e50$@tsu.ru> <002d01d04445$00a4fff0$01eeffd0$@tsu.ru> Message-ID: <004001d0444b$f4322f70$dc968e50$@tsu.ru> -----Original Message----- From: Moscow-pm [mailto:moscow-pm-bounces+snelius=tsu.ru на pm.org] On Behalf Of Daniel Podolsky Sent: Monday, February 09, 2015 3:25 PM To: Moscow.pm group Subject: Re: [Moscow.pm] асинхронный код позволяет сильно сэкономить ресурсы серверов > Nginx способен не особо напрягаясь обрабатывать десятки тысяч соединений. > Апачу для этих целей надо значительно больше ресурсов. зато апач способен выполнять полезную работу, а nginx может только перекладывать байты из одной трубы в другую. это я не про спорить, я про неадекватность сравнения :) nginx - клевая софтина, и без нее веб-хайлоад представить себе сегодня трудно, но роль его - роль кеша записи. > Ради интереса можно всё-таки написать тесты на Си и закрыть уже этот > вопрос чёрт возьми ) Я вот не уверен, что тесты эти надо на Си написать. Мы же все остальное, что собираемся писать, не собираемся писать на Си, правда? ;) Ну если их нужно писать на Perl. То увы, без меня. Мне к сожалению не хватит скила чтобы достойно изобразить код на тредах. Может найдётся желающий From aml на rulezz.ru Mon Feb 9 01:45:39 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Mon, 09 Feb 2015 09:45:39 +0000 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= References: <002101d04440$e0cecf70$a26c6e50$@tsu.ru> <002d01d04445$00a4fff0$01eeffd0$@tsu.ru> Message-ID: Реальная проблема, с которой лично я сталкиваюсь регулярно - это когда один бэкенд начинает тормозить (например, кто-то загрузил базу данных тяжёлыми запросами на несколько секунд), и в результате все синхронные воркеры, которые иногда записывают данные в эту базу, затыкаются и ждут эти несколько секунд. Остальные клиенты, которым эта база может и вообще не нужна, и которые могли бы быть обслужены в случае асинхронного приложения, стоят в очереди. Добавлять воркеров я уже не могу - их 50 штук на сервере выполняется, и больше уже памяти нет. И даже если их добавить больше, это не помешает им всем заткнуться на той же базе. Синтетические тесты - это всё здорово, но ими не проверить такие ситуации. On Mon Feb 09 2015 at 10:25:01 AM Daniel Podolsky wrote: > > Nginx способен не особо напрягаясь обрабатывать десятки тысяч соединений. > > Апачу для этих целей надо значительно больше ресурсов. > зато апач способен выполнять полезную работу, а nginx может только > перекладывать байты из одной трубы в другую. > > это я не про спорить, я про неадекватность сравнения :) > > nginx - клевая софтина, и без нее веб-хайлоад представить себе сегодня > трудно, но роль его - роль кеша записи. > > > Ради интереса можно всё-таки написать тесты на Си и закрыть уже этот > вопрос > > чёрт возьми ) > Я вот не уверен, что тесты эти надо на Си написать. Мы же все > остальное, что собираемся писать, не собираемся писать на Си, правда? > ;) > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From aml на rulezz.ru Mon Feb 9 01:53:28 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Mon, 09 Feb 2015 09:53:28 +0000 Subject: [Moscow.pm] =?utf-8?b?0L/RgNC+INC30L7QvtC/0LDRgNC6INGC0LXRhdC9?= =?utf-8?b?0L7Qu9C+0LPQuNC5?= References: <807709452.20150208213924@softsearch.ru> Message-ID: > > Как сотрудник конторы где половина продакшен софта на Java - могу сказать > только "бугага". > Как человек, видевший Java в очень суровом продакшне, могу сказать, что она рулит и способна на очень многое. Но это требует разработчиков невероятно высокой квалификации. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From onokonem на gmail.com Mon Feb 9 01:55:20 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Mon, 9 Feb 2015 13:55:20 +0400 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: <54D87696.6090201@rambler.ru> References: <19923524.20150208131028@softsearch.ru> <1448301.L8bfyLT0Ar@rawen> <54D8657A.2050202@rambler.ru> <54D87696.6090201@rambler.ru> Message-ID: Спорить, пожалуй, действительно не стану, но пару уточняющих вопросов задам :) > 1) Создание потоков и процессом в Линуксе делается одним вызовом (clone) > разница только в копировании адресного пространства при создании процесса, > а внутри они ничем не различаются, кроме адресного пространства. > Если процесс поток/процесс живет довольно долго, то разницу в накладных > расходов при создании процесса можно пренебречь а почему мы не взяли язык повыше уровнем, в котором есть виртуальная машина, которая нам все проблемы взаимодействия с системными тредами уже решила? > 2) При большом количестве потоков у ядра вырастают накладные расходы на > переключение потоков. > В случае большой нагрузки вообще говоря количество потоков > вырастает(threads), а в случае асинхронной программы это количесто не > меняется, поэтому > асинхронная модель будет выигрывать за счет накладных расходов ядра системы. Наша программа ведь что-то делает? Сравним ли этот оверхед с затратами на собственно полезную деятельность? > 3) Асинхронная программа это однопоточная программа. А поскольку отлаживать > однопоточную программу проще чем многопоточную, то > и отлаживать асинхронную программу легче, чем программу с потоками. это не аргумент, а еще один тезис :) мой опыт говорит мне прямо противоположное. > 4) В асинхронной программе не нужны средства синхронизации потоков(Из-за > многопоточности), которые просто необходимы в потоках. > Накладные расходы на синхронизацию не ускоряют поточные программы и иногда > могут быть просто чудовищными. > 100-200 циклов процессора минимум на одном примитиве. синхронизация между процессами нам уже не нужна? или на ipc расходы менее чудовищные? > 5) forkи проще концептуально и приводят к меньшему количеству ошибок в > программировании, значит отлаживать будет меньше. forkи проще чем что? чем goroutines? чем jvm threads? черт, все равно спор получается :( From bobrovaksenia на gmail.com Mon Feb 9 01:55:49 2015 From: bobrovaksenia на gmail.com (=?UTF-8?B?0JrRgdC10L3QuNGPINCR0L7QsdGA0L7QstCw?=) Date: Mon, 9 Feb 2015 10:55:49 +0100 Subject: [Moscow.pm] =?utf-8?b?0L/RgNC+INC30L7QvtC/0LDRgNC6INGC0LXRhdC9?= =?utf-8?b?0L7Qu9C+0LPQuNC5?= In-Reply-To: References: <807709452.20150208213924@softsearch.ru> Message-ID: ну посмейтесь. в джаве треды есть, что снимает огромное количество проблем. остальные преимущества джавы перед перлом можно перечислять бесконечно)) 9 февраля 2015 г., 10:53 пользователь Alexander Lourier написал: > Как сотрудник конторы где половина продакшен софта на Java - могу сказать >> только "бугага". >> > Как человек, видевший Java в очень суровом продакшне, могу сказать, что > она рулит и способна на очень многое. Но это требует разработчиков > невероятно высокой квалификации. > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > > -- Ksenia Bobrova Senior Perl Developer ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mialinx на gmail.com Mon Feb 9 02:02:49 2015 From: mialinx на gmail.com (Dmitry Smal) Date: Mon, 09 Feb 2015 13:02:49 +0300 Subject: [Moscow.pm] =?koi8-r?b?0NLPINrPz9DB0ssg1MXIzs/Mz8fJyg==?= In-Reply-To: References: <807709452.20150208213924@softsearch.ru> Message-ID: <54D885C9.9080609@gmail.com> Чего стоят одни стектрейсы на 3 экрана! On 02/09/2015 12:55 PM, Ксения Боброва wrote: > ну посмейтесь. > в джаве треды есть, что снимает огромное количество проблем. > остальные преимущества джавы перед перлом можно перечислять бесконечно)) > > 9 февраля 2015 г., 10:53 пользователь Alexander Lourier > написал: > > Как сотрудник конторы где половина продакшен софта на Java - > могу сказать только "бугага". > > Как человек, видевший Java в очень суровом продакшне, могу > сказать, что она рулит и способна на очень многое. Но это требует > разработчиков невероятно высокой квалификации. > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > > > > > -- > Ksenia Bobrova > Senior Perl Developer > > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From onokonem на gmail.com Mon Feb 9 02:06:27 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Mon, 9 Feb 2015 14:06:27 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: References: <002101d04440$e0cecf70$a26c6e50$@tsu.ru> <002d01d04445$00a4fff0$01eeffd0$@tsu.ru> Message-ID: > Добавлять воркеров я уже не могу - их 50 штук на сервере выполняется, и > больше уже памяти нет. Хочу подробностей! Что это за воркеры такие злые? Почему асинхронному приложению эта память не понадобится? Может, и синхронному не нужна? From 0body0 на rambler.ru Mon Feb 9 03:25:46 2015 From: 0body0 на rambler.ru (=?KOI8-R?Q?=E1=CE=C1=D4=CF=CC=C9=CA_=E7=D2=C9=DB=C1=C5=D7?=) Date: Mon, 09 Feb 2015 14:25:46 +0300 Subject: [Moscow.pm] =?koi8-r?b?0NLPINrPz9DB0ssg1MXIzs/Mz8fJyg==?= In-Reply-To: References: <807709452.20150208213924@softsearch.ru> Message-ID: <54D8993A.6020602@rambler.ru> А select в java есть или только треды? 09.02.2015 12:55, Ксения Боброва пишет: > ну посмейтесь. > в джаве треды есть, что снимает огромное количество проблем. > остальные преимущества джавы перед перлом можно перечислять бесконечно)) > > 9 февраля 2015 г., 10:53 пользователь Alexander Lourier > написал: > > Как сотрудник конторы где половина продакшен софта на Java - > могу сказать только "бугага". > > Как человек, видевший Java в очень суровом продакшне, могу > сказать, что она рулит и способна на очень многое. Но это требует > разработчиков невероятно высокой квалификации. > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > > > > > -- > Ksenia Bobrova > Senior Perl Developer > > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From vaneska.ru на gmail.com Mon Feb 9 03:33:27 2015 From: vaneska.ru на gmail.com (=?UTF-8?B?0JjQstCw0L0g0KHQvtC60L7Qu9C+0LI=?=) Date: Mon, 9 Feb 2015 15:33:27 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: References: <002101d04440$e0cecf70$a26c6e50$@tsu.ru> <002d01d04445$00a4fff0$01eeffd0$@tsu.ru> Message-ID: 9 февраля 2015 г., 13:06 пользователь Daniel Podolsky написал: > > Добавлять воркеров я уже не могу - их 50 штук на сервере выполняется, и > > больше уже памяти нет. > Хочу подробностей! Что это за воркеры такие злые? Почему асинхронному > приложению эта память не понадобится? Может, и синхронному не нужна? > Один асинхронный процесс может ждать сразу несколько запросов одновременно. В процессе ожидания делая полезную работу. Один синхронный процесс может ждать только один запрос одновременно. Например: Чтобы получить данные с 50 урлов для синхронного подхода нужно создать 50 воркеров и внутри каждого отправить запрос на получение урла и ждать данных. Для асинхронного подхода достаточно в одном воркере ( или по кол ядер на сервере ) отправить сразу 50 запросов и ждать данных, в процессе ожидания данных обрабатывать уже пришедшие данные. Асинхронный подход выигрывает там, где есть сетевые задержки. Те где синхронный код ждет ответа, асинхронный код работает. Те, образно говоря, чтобы на одно и то же время получить данные с 50 урлов нужно 1 асинхронный процесс на 1 ядро и 2-3 синхронных процесса. Вот здесь и происходит экономия памяти. За счет максимального использования процессора. З.Ы. интересная дискуссия. Тоже захотелось поучаствовать ) -- С уважением, Иван ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From onokonem на gmail.com Mon Feb 9 03:34:58 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Mon, 9 Feb 2015 15:34:58 +0400 Subject: [Moscow.pm] =?utf-8?b?0L/RgNC+INC30L7QvtC/0LDRgNC6INGC0LXRhdC9?= =?utf-8?b?0L7Qu9C+0LPQuNC5?= In-Reply-To: <54D8993A.6020602@rambler.ru> References: <807709452.20150208213924@softsearch.ru> <54D8993A.6020602@rambler.ru> Message-ID: > А select в java есть или только треды? есть с версии 1.4. ну, то есть, я не проверял, select там используется, или таки ядерные события, но aio есть в полном объеме From eugene.toropov на gmail.com Mon Feb 9 03:43:43 2015 From: eugene.toropov на gmail.com (Eugene Toropov) Date: Mon, 9 Feb 2015 14:43:43 +0300 Subject: [Moscow.pm] =?utf-8?b?0L/RgNC+INC30L7QvtC/0LDRgNC6INGC0LXRhdC9?= =?utf-8?b?0L7Qu9C+0LPQuNC5?= In-Reply-To: References: <807709452.20150208213924@softsearch.ru> <54D8993A.6020602@rambler.ru> Message-ID: <55AF54EB-8895-4FA4-BDB1-6BB3E37C2FE8@gmail.com> http://docs.oracle.com/javase/7/docs/api/java/nio/channels/Selector.html > On Feb 9, 2015, at 2:34 PM, Daniel Podolsky wrote: > >> А select в java есть или только треды? > есть с версии 1.4. ну, то есть, я не проверял, select там > используется, или таки ядерные события, но aio есть в полном объеме > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From onokonem на gmail.com Mon Feb 9 04:06:41 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Mon, 9 Feb 2015 16:06:41 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: References: <002101d04440$e0cecf70$a26c6e50$@tsu.ru> <002d01d04445$00a4fff0$01eeffd0$@tsu.ru> Message-ID: > Вот здесь и происходит экономия памяти. За счет максимального использования > процессора. это зависит от того, как сделаны синхронные воркеры. Если это отдельные процессы - экономия есть. Но такой многозадачности нам и даром не надо - IPC это реальная попаболь. если же это треды, а лучше того горутины - с чего бы им жрать больше памяти, чем надо для исполнения задачи? > Асинхронный подход выигрывает там, где есть сетевые задержки. это правда. вопрос в размере выигрыша, и даже - нужен ли он нам вообще на этом месте... From akovbovich на gmail.com Mon Feb 9 05:09:25 2015 From: akovbovich на gmail.com (Andrey Kovbovich) Date: Mon, 9 Feb 2015 17:09:25 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: References: <002101d04440$e0cecf70$a26c6e50$@tsu.ru> <002d01d04445$00a4fff0$01eeffd0$@tsu.ru> Message-ID: Асинхронно - это когда несколько потоков исполнения работают как им возблагорассудиться, а синхронно - это когда потоки работают в соответствии некому генератору квантов логического времени понедельник, 9 февраля 2015 г. пользователь Daniel Podolsky написал: > > Добавлять воркеров я уже не могу - их 50 штук на сервере выполняется, и > > больше уже памяти нет. > Хочу подробностей! Что это за воркеры такие злые? Почему асинхронному > приложению эта память не понадобится? Может, и синхронному не нужна? > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From postmaster на softsearch.ru Mon Feb 9 05:11:21 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Mon, 9 Feb 2015 16:11:21 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= Message-ID: <19510226719.20150209161121@softsearch.ru> Здравствуйте, Mons. > Народ, я не осилил дочитать это всё до конца. > А давайте-ка соберёмся и померяемся. > Не в плане теории, а в плане конкретных чисел > сравним разные языки, подходы и т.п. А собираться обязательно? Можно ведь и удалённо. Я на Go пишу всего месяц и мне было бы сложно придти и что-то нормально на нём написать за малое время. Но сравнить языки было бы интересно. Предложу простую задачку, которая покажет, насколько хорошо язык работает с памятью: сложить все значения массива, состоящего из 10000000 целых чисел. Код там простой: создаём массив, заполняем его, замеряем время, потом в цикле складываем элементы массива, снова замеряем время и выдаём результат. Вот мой вариант на Go: https://play.golang.org/p/iHGG3nV10L Тонкости: в песочнице код съедает много процессора и время там всегда одно и то же, поэтому его надо сохранить в файл, например main.go и потом запустить вот так: go run main.go Скомпилировать в исполняемый файл можно вот так: go build main.go А вот так выйдет более быстрая версия: go build -gcflags="-B" main.go Скачать Go можно вот тут: http://golang.org/ -- С уважением, Михаил mailto:postmaster на softsearch.ru From warstone на list.ru Mon Feb 9 05:33:58 2015 From: warstone на list.ru (=?UTF-8?B?V2Fyc3RvbmVAbGlzdC5ydQ==?=) Date: Mon, 09 Feb 2015 16:33:58 +0300 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC90L4=?= =?utf-8?b?0LzQuNGC0Ywg0YDQtdGB0YPRgNGB0Ysg0YHQtdGA0LLQtdGA0L7Qsg==?= In-Reply-To: References: Message-ID: <1423488838.964261072@f365.i.mail.ru> Неверно в принципе, ну да ладно... Понедельник, 09 февраля 2015, 17:09 +04:00 от Andrey Kovbovich : >Асинхронно - это когда несколько потоков исполнения работают как им возблагорассудиться, а синхронно - это когда потоки работают в соответствии некому генератору квантов логического  времени > >понедельник, 9 февраля 2015 г. пользователь Daniel Podolsky написал: >>> Добавлять воркеров я уже не могу - их 50 штук на сервере выполняется, и >>> больше уже памяти нет. >>Хочу подробностей! Что это за воркеры такие злые? Почему асинхронному >>приложению эта память не понадобится? Может, и синхронному не нужна? >>-- >>Moscow.pm mailing list >>moscow-pm на pm.org  | http://moscow.pm.org >-- >Moscow.pm mailing list >moscow-pm на pm.org | http://moscow.pm.org Собственно тут вроде-бы еще не проскальзывала мысль, что асинхронность, при условии достаточности ресурсов - это всегда медленнее чем синхронность. Например: Я зажевал в один поток все сообщения, раздал запросы на данные и обрабатываю результаты.... Пока я обрабатываю один результат, остальные стоят. В случае с синхронным форком такого-бы не было (у нас много ядер). Проблема назревает когда у нас бекэнд (то, что отвечает на запросы), обрабатывает запрос долго. Но в этом случае какая, нафиг, кому разница - где делается "асинхронность" - у нас в лупе или в ядре при свитче контекста. Бек все-равно дольше... Асинхронность нужна в некоторых случаях: - Если у вас стоимость свитча контекста гораздо дороже ответа от бэка (по времени), но при переходе на асинк у вас еще будет дофига ресурсов ЦПУ (так как свитч контекста - это ЦПУ задача). - Если у вас асинк дает другие преимущества (в то числе и "потому что его умеют готовить разработчики, а вот с форком им сложно"). - Если у вас задача "обработать данные, зная что у вас в очереди всегда есть следующие задачи". Допустим быстрое преобразование фурье с отсылкой результатов далее по конвееру. (Привет SETI на Home) Вот тогда - да. Тогда есть у вас CPU баунд задача и вам важны такты процессора. На практике мы всегда боимся 1го, но зачастую протормозы в беках гораздо больше. ЗЫ: Тоже поучаствовать решил. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From postmaster на softsearch.ru Mon Feb 9 05:36:33 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Mon, 9 Feb 2015 16:36:33 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: <19510226719.20150209161121@softsearch.ru> References: <19510226719.20150209161121@softsearch.ru> Message-ID: <678779427.20150209163633@softsearch.ru> Здравствуйте, Михаил. Вот вариант на JavaScript http://pastebin.com/T1DVHNFM Его надо сохранить в файл, например main.js, поставить Node.js отсюда http://nodejs.org/ , и потом запусть примерно вот так: C:\Program Files\nodejs\node.exe main.js На 32-битной венде этот код на javascript работает примерно вдвое быстрее, чем код на Go. 35ms против 52ms :-) Посмотрю, как можно ускорить код на Go... -- С уважением, Михаил mailto:postmaster на softsearch.ru From aml на rulezz.ru Mon Feb 9 05:43:44 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Mon, 09 Feb 2015 13:43:44 +0000 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= References: <002101d04440$e0cecf70$a26c6e50$@tsu.ru> <002d01d04445$00a4fff0$01eeffd0$@tsu.ru> Message-ID: > > > Добавлять воркеров я уже не могу - их 50 штук на сервере выполняется, и > > больше уже памяти нет. > Хочу подробностей! Что это за воркеры такие злые? Почему асинхронному > приложению эта память не понадобится? Может, и синхронному не нужна? > Онлайн-игра. В ней есть много локаций (на данный момент сейчас их 130518 штук). Про каждую локацию есть примерно килобайт данных. Игрок может сделать запрос на прокладку пути из пункта A в пункт B. Надо загрузить граф локаций, сделать поиск по нему, вернуть ответ игроку. Связность локаций постоянно меняется (игроки открывают/закрывают порталы), и граф надо перестраивать. Поэтому загрузить его один раз, а потом отфоркать воркеров уже не получается. Поэтому каждый воркер должен держать в памяти копию. 130 мегабайт. И это не единственные полезные вещи, которые в памяти оседают. Есть и ещё всякое. В результате 50 воркеров едят 10 гигов памяти. Для решения этой проблемы у меня прокладкой пути занимается отдельный сервис, который единственный держит в памяти граф всего мира. Недостаток этого решения - latency. Если несколько клиентов хотят проложить путь, они это делают по очереди, а процессоры воркеров в это время простаивают. Если бы воркеры были асинхронными, то можно было бы запустить 8 воркеров (по числу ядер на машине), и на каждый воркер хранилась бы всего одна копия графа. Внезапно высвободилась бы куча памяти, которой бы нашлось лучшее применение (дисковые кэши, memcached и т.д.) ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From aml на rulezz.ru Mon Feb 9 05:49:32 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Mon, 09 Feb 2015 13:49:32 +0000 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> Message-ID: О, а можно я на Go напишу так, что сделаю частичное сложение в 8 горутин, а потом сложу частичные суммы? А вообще, тестировать надо на задачах, которые тебе в продакшне нужны, а не на абстрактных числодробительных тестах. On Mon Feb 09 2015 at 2:37:00 PM Михаил Монашёв wrote: > Здравствуйте, Михаил. > > Вот вариант на JavaScript http://pastebin.com/T1DVHNFM > Его надо сохранить в файл, например main.js, поставить Node.js > отсюда http://nodejs.org/ , и потом запусть примерно вот так: > C:\Program Files\nodejs\node.exe main.js > > На 32-битной венде этот код на javascript работает примерно вдвое > быстрее, чем код на Go. 35ms против 52ms :-) Посмотрю, как можно > ускорить код на Go... > > -- > С уважением, > Михаил mailto:postmaster на softsearch.ru > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From postmaster на softsearch.ru Mon Feb 9 05:50:19 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Mon, 9 Feb 2015 16:50:19 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: <678779427.20150209163633@softsearch.ru> References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> Message-ID: <1009399030.20150209165019@softsearch.ru> Здравствуйте, Михаил. > На 32-битной венде этот код на javascript работает примерно вдвое > быстрее, чем код на Go. 35ms против 52ms :-) Посмотрю, как можно > ускорить код на Go... https://play.golang.org/p/61DOm3N2Ne - вот вариант на Go, который стал работать быстрее: 40ms вместо 52ms. -- С уважением, Михаил mailto:postmaster на softsearch.ru From onokonem на gmail.com Mon Feb 9 05:50:45 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Mon, 9 Feb 2015 17:50:45 +0400 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= In-Reply-To: References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> Message-ID: > А вообще, тестировать надо на задачах, которые тебе в продакшне нужны, а не > на абстрактных числодробительных тестах. +1 From onokonem на gmail.com Mon Feb 9 05:56:29 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Mon, 9 Feb 2015 17:56:29 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: References: <002101d04440$e0cecf70$a26c6e50$@tsu.ru> <002d01d04445$00a4fff0$01eeffd0$@tsu.ru> Message-ID: > Если бы воркеры были асинхронными, то можно было бы запустить 8 воркеров (по > числу ядер на машине), и на каждый воркер хранилась бы всего одна копия > графа. если бы воркеры были синхронными, но на тредах - копия хранилась бы вообще одна на всех. памяти освободилось бы еще. только тогда воркеры были бы не на перле, да... слушайте, а что мешает взять да переписать? раз есть работающий прототип - это на неделю занятие. From aml на rulezz.ru Mon Feb 9 06:04:47 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Mon, 09 Feb 2015 14:04:47 +0000 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= References: <002101d04440$e0cecf70$a26c6e50$@tsu.ru> <002d01d04445$00a4fff0$01eeffd0$@tsu.ru> Message-ID: Всё выбросить и переписать - это для богатых :) Работает - не трогай. Если бы я начинал новый проект, то конечно на других технологиях. Перл для этой задачи малопригоден. On Mon Feb 09 2015 at 2:56:47 PM Daniel Podolsky wrote: > > Если бы воркеры были асинхронными, то можно было бы запустить 8 воркеров > (по > > числу ядер на машине), и на каждый воркер хранилась бы всего одна копия > > графа. > если бы воркеры были синхронными, но на тредах - копия хранилась бы > вообще одна на всех. памяти освободилось бы еще. > > только тогда воркеры были бы не на перле, да... > > слушайте, а что мешает взять да переписать? раз есть работающий > прототип - это на неделю занятие. > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From 0body0 на rambler.ru Mon Feb 9 06:06:32 2015 From: 0body0 на rambler.ru (=?KOI8-R?Q?=E1=CE=C1=D4=CF=CC=C9=CA_=E7=D2=C9=DB=C1=C5=D7?=) Date: Mon, 09 Feb 2015 17:06:32 +0300 Subject: [Moscow.pm] =?koi8-r?b?wdPJzsjSz87O2cogy8/EINDP2tfPzNHF1CDTyczY?= =?koi8-r?b?zs8g09zLz87PzcnU2CDSxdPV0tPZINPF0tfF0s/X?= In-Reply-To: References: <002101d04440$e0cecf70$a26c6e50$@tsu.ru> <002d01d04445$00a4fff0$01eeffd0$@tsu.ru> Message-ID: <54D8BEE8.4030201@rambler.ru> 09.02.2015 16:43, Alexander Lourier пишет: > > > Добавлять воркеров я уже не могу - их 50 штук на сервере > выполняется, и > > больше уже памяти нет. > Хочу подробностей! Что это за воркеры такие злые? Почему асинхронному > приложению эта память не понадобится? Может, и синхронному не нужна? > > > Онлайн-игра. В ней есть много локаций (на данный момент сейчас их > 130518 штук). Про каждую локацию есть примерно килобайт данных. Игрок > может сделать запрос на прокладку пути из пункта A в пункт B. Надо > загрузить граф локаций, сделать поиск по нему, вернуть ответ игроку. > > Связность локаций постоянно меняется (игроки открывают/закрывают > порталы), и граф надо перестраивать. Поэтому загрузить его один раз, а > потом отфоркать воркеров уже не получается. Поэтому каждый воркер > должен держать в памяти копию. 130 мегабайт. И это не единственные > полезные вещи, которые в памяти оседают. Есть и ещё всякое. В > результате 50 воркеров едят 10 гигов памяти. > > Для решения этой проблемы у меня прокладкой пути занимается отдельный > сервис, который единственный держит в памяти граф всего мира. > Недостаток этого решения - latency. Если несколько клиентов хотят > проложить путь, они это делают по очереди, а процессоры воркеров в это > время простаивают. > > Если бы воркеры были асинхронными, то можно было бы запустить 8 > воркеров (по числу ядер на машине), и на каждый воркер хранилась бы > всего одна копия графа. Внезапно высвободилась бы куча памяти, которой > бы нашлось лучшее применение (дисковые кэши, memcached и т.д.) > > Вау, мы такую задачу решали на перле лет этак 6 назад. prefork + map + async + немного xs. Решили так: 1) маппили файл с графом на память 2) prefork 3) перед тем как найти путь или перестроить граф делали flock ( для изменения LOCK_EX, для построения LOCK_SH) 4) поиск пути делался XS функцей(получалось сильно быстрее), а все остальное на perl 1) В итоге граф не клонируется между форками 2) Все процессоры могут поучаствовать в расчете пути. 3) единственный минус изменение пути может выполнять один процессор. В принципе flock можно заменить на более прикольные блокировки. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From aml на rulezz.ru Mon Feb 9 06:10:27 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Mon, 09 Feb 2015 14:10:27 +0000 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> <1009399030.20150209165019@softsearch.ru> Message-ID: > > https://play.golang.org/p/61DOm3N2Ne - вот вариант на Go, который стал > работать быстрее: 40ms вместо 52ms. > Вот такой посмотри: https://play.golang.org/p/UDN6j8dB5x ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From aml на rulezz.ru Mon Feb 9 06:10:53 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Mon, 09 Feb 2015 14:10:53 +0000 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> <1009399030.20150209165019@softsearch.ru> Message-ID: Запускать с GOMAXPROCS=8 On Mon Feb 09 2015 at 3:10:27 PM Alexander Lourier wrote: > https://play.golang.org/p/61DOm3N2Ne - вот вариант на Go, который стал >> работать быстрее: 40ms вместо 52ms. >> > > Вот такой посмотри: https://play.golang.org/p/UDN6j8dB5x > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From postmaster на softsearch.ru Mon Feb 9 06:10:51 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Mon, 9 Feb 2015 17:10:51 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> Message-ID: <14035051.20150209171051@softsearch.ru> Здравствуйте, Alexander. > О, а можно я на Go напишу так, что сделаю частичное сложение в 8 > горутин, а потом сложу частичные суммы? Напиши конечно. Лучше даже по числу ядер. > А вообще, тестировать надо на задачах, которые тебе в продакшне > нужны, а не на абстрактных числодробительных тестах. Их писать долго. А это и писать просто и ИМХО отлично показывает возможности языка, а не программиста. У Go, например, go build генерит жутко неоптимизированный код и его руками на ассемблере можно сильно ускорить, если стоит такая задача. В gcc или icc c -O3 для подобной задачи код был бы с использование SIMD наверняка... Надеюсь кто-то на сях напишет и сравнит задачку. Я пока накропал вот это: #include int main(int argc, char *argv[]) { int arr[10000000]; unsigned long long sum = 0; int i; for( i=10000000-1; i>=0; i--) { sum+=arr[i]; } printf("%lu", sum); return 0; } но пока не знаю, как получить размер массива (чтоб код красивее был) и как время замерить. -- С уважением, Михаил mailto:postmaster на softsearch.ru From pef-secure на yandex.ru Mon Feb 9 06:13:01 2015 From: pef-secure на yandex.ru (PEF Secure) Date: Mon, 09 Feb 2015 15:13:01 +0100 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: References: Message-ID: <474510465.4jegOOD7eU@rawen> On Monday, February 09, 2015 11:37:00 Daniel Podolsky wrote: > 2015-02-09 9:40 GMT+03:00 Anatoly Y : > > > Под асихнронностью (в данном контексте) всегда подразумевают операции IO > > и > > ничего больше. > > не операции IO, конечно, а способ нашего кода получать их результаты. > > если результаты доступны в основном потоке выполнения сразу после > операции - это синхронное программирование. > > если результаты приходят когда-нибудь потом, колбеком - асинхронное. Замечательное свойство AE/Coro -- condvar, когда можно писать по сути синхронный код, который будет выполняться асинхронно. Например: заявка на чтение из потока, колбек через кондвар сигнализирует о результате; <засыпаем на ожидании кондвар, управление переходит к другим ниткам> данные прочитаны, работаем дальше; Т.е. возможно писать код, который выглядит как синхронный, но работает при этом асинхронно. -- PEF Developer From 0body0 на rambler.ru Mon Feb 9 06:14:43 2015 From: 0body0 на rambler.ru (=?KOI8-R?Q?=E1=CE=C1=D4=CF=CC=C9=CA_=E7=D2=C9=DB=C1=C5=D7?=) Date: Mon, 09 Feb 2015 17:14:43 +0300 Subject: [Moscow.pm] =?koi8-r?b?wdPJzsjSz87O2cogy8/EINDP2tfPzNHF1CDTyczY?= =?koi8-r?b?zs8g09zLz87PzcnU2CDSxdPV0tPZINPF0tfF0s/X?= In-Reply-To: References: <002101d04440$e0cecf70$a26c6e50$@tsu.ru> <002d01d04445$00a4fff0$01eeffd0$@tsu.ru> Message-ID: <54D8C0D3.4080805@rambler.ru> 09.02.2015 17:04, Alexander Lourier пишет: > Всё выбросить и переписать - это для богатых :) Работает - не трогай. > Если бы я начинал новый проект, то конечно на других технологиях. Перл > для этой задачи малопригоден. Почему малопригоден? Для решения твоей задачи существует хорошое решение без особенных недостатков. А что за игра, которую ты делаешь/поддерживаешь? > > On Mon Feb 09 2015 at 2:56:47 PM Daniel Podolsky > wrote: > > > Если бы воркеры были асинхронными, то можно было бы запустить 8 > воркеров (по > > числу ядер на машине), и на каждый воркер хранилась бы всего > одна копия > > графа. > если бы воркеры были синхронными, но на тредах - копия хранилась бы > вообще одна на всех. памяти освободилось бы еще. > > только тогда воркеры были бы не на перле, да... > > слушайте, а что мешает взять да переписать? раз есть работающий > прототип - это на неделю занятие. > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > > > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From aml на rulezz.ru Mon Feb 9 06:17:57 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Mon, 09 Feb 2015 14:17:57 +0000 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= Message-ID: 1. Если у тебя производительность не упирается в CPU, увеличение качества компилируемого кода не даст настолько большого ускорения. Если ты картинки ресайзишь основное время - это один разговор. Если только и делаешь, что базу данных ждёшь, то другой. 2. Посмотри ещё gccgo - это альтернативный компилятор. Может быть, он поддерживает всякие -O3 и SIMD. Я не смотрел на него сам, правда. On Mon Feb 09 2015 at 3:11:22 PM Михаил Монашёв wrote: > Здравствуйте, Alexander. > > > О, а можно я на Go напишу так, что сделаю частичное сложение в 8 > > горутин, а потом сложу частичные суммы? > > Напиши конечно. Лучше даже по числу ядер. > > > А вообще, тестировать надо на задачах, которые тебе в продакшне > > нужны, а не на абстрактных числодробительных тестах. > > Их писать долго. А это и писать просто и ИМХО отлично показывает > возможности языка, а не программиста. > > У Go, например, go build генерит жутко неоптимизированный код и его > руками на ассемблере можно сильно ускорить, если стоит такая задача. В > gcc или icc c -O3 для подобной задачи код был бы с использование SIMD > наверняка... > > Надеюсь кто-то на сях напишет и сравнит задачку. Я пока накропал вот > это: > #include > > int main(int argc, char *argv[]) > { > > int arr[10000000]; > > unsigned long long sum = 0; > int i; > > for( i=10000000-1; i>=0; i--) { > sum+=arr[i]; > } > printf("%lu", sum); > return 0; > } > > но пока не знаю, как получить размер массива (чтоб код красивее был) и > как время замерить. > > -- > С уважением, > Михаил mailto:postmaster на softsearch.ru > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From onokonem на gmail.com Mon Feb 9 06:18:48 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Mon, 9 Feb 2015 18:18:48 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: References: <002101d04440$e0cecf70$a26c6e50$@tsu.ru> <002d01d04445$00a4fff0$01eeffd0$@tsu.ru> Message-ID: > Всё выбросить и переписать - это для богатых :) Работает - не трогай. зачем - выбросить? остановить одного воркера из 50, и вместо него запустить нового. и посмотреть, как справляется. From postmaster на softsearch.ru Mon Feb 9 06:19:43 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Mon, 9 Feb 2015 17:19:43 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> <1009399030.20150209165019@softsearch.ru> Message-ID: <79379696.20150209171943@softsearch.ru> Здравствуйте, Alexander. > https://play.golang.org/p/61DOm3N2Ne - вот вариант на Go, который стал > работать быстрее: 40ms вместо 52ms. > > Вот такой посмотри: https://play.golang.org/p/UDN6j8dB5x 30ms -- С уважением, Михаил mailto:postmaster на softsearch.ru From pef-secure на yandex.ru Mon Feb 9 06:20:22 2015 From: pef-secure на yandex.ru (PEF Secure) Date: Mon, 09 Feb 2015 15:20:22 +0100 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: <54D8657A.2050202@rambler.ru> References: <1448301.L8bfyLT0Ar@rawen> <54D8657A.2050202@rambler.ru> Message-ID: <1611038.am9g1Uy45O@rawen> On Monday, February 09, 2015 10:44:58 Анатолий Гришаев wrote: > 1) было исследование программ на C, которое показывало, асинхронный код > не проигрывает тредовому, и довольно > часто при большой нагрузке оказывается быстрее. ( Кажется это была > толстая зеленая книга) Ни разу не сомневался, что это именно так. Асинхронные программы на си я начал писать 13 лет назад, я представлял зачем. > 2) За исключением патологических случаем fork по скорости сравним с threads. Ну когда два параллельных процесса друг от друга не зависят, тогда верно. Если не считать времени на создание/отпочкование. Когда требуется синхронизация доступа к ресурсам, то в случае форков это становится "весело", с тредами проще. > 3) Писать и отлаживать на AnyEvent + fork намного проще, чем на threads. Это очень непонятное мне утверждение. Какие к чёрту треды в перле??? Мы только что разговаривали про си, но переход к эниэвент означает перл, а это уже "никакие" треды. > Т.е. threads --- это технологический тупик. > И если он есть это наверно хорошо, но лучше им не пользоваться. > Выгоды от него ограниченные, а гемороя можно получить в разы больше. Слишком общее утверждение, чтобы я смог его понять. В перле тредов нет в системном смысле, поэтому, я не понимаю утверждение. Есть форки и асинхронность. Есть AE/Coro, которые можно использовать, чтобы асинхронность спрятать "под капот" и получить "зелёные нитки". -- PEF Developer From postmaster на softsearch.ru Mon Feb 9 06:25:40 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Mon, 9 Feb 2015 17:25:40 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> <1009399030.20150209165019@softsearch.ru> Message-ID: <117390181.20150209172540@softsearch.ru> Здравствуйте, Alexander. > Запускать с GOMAXPROCS=8 > Вот такой посмотри: https://play.golang.org/p/UDN6j8dB5x Забыл совсем про это. Вышло 17ms. -- С уважением, Михаил mailto:postmaster на softsearch.ru From aml на rulezz.ru Mon Feb 9 06:26:23 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Mon, 09 Feb 2015 14:26:23 +0000 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= References: <002101d04440$e0cecf70$a26c6e50$@tsu.ru> <002d01d04445$00a4fff0$01eeffd0$@tsu.ru> <54D8BEE8.4030201@rambler.ru> Message-ID: > > > Добавлять воркеров я уже не могу - их 50 штук на сервере выполняется, и >> > больше уже памяти нет. >> Хочу подробностей! Что это за воркеры такие злые? Почему асинхронному >> приложению эта память не понадобится? Может, и синхронному не нужна? >> > > Онлайн-игра. В ней есть много локаций (на данный момент сейчас их 130518 > штук). Про каждую локацию есть примерно килобайт данных. Игрок может > сделать запрос на прокладку пути из пункта A в пункт B. Надо загрузить граф > локаций, сделать поиск по нему, вернуть ответ игроку. > > Связность локаций постоянно меняется (игроки открывают/закрывают > порталы), и граф надо перестраивать. Поэтому загрузить его один раз, а > потом отфоркать воркеров уже не получается. Поэтому каждый воркер должен > держать в памяти копию. 130 мегабайт. И это не единственные полезные вещи, > которые в памяти оседают. Есть и ещё всякое. В результате 50 воркеров едят > 10 гигов памяти. > > Для решения этой проблемы у меня прокладкой пути занимается отдельный > сервис, который единственный держит в памяти граф всего мира. Недостаток > этого решения - latency. Если несколько клиентов хотят проложить путь, они > это делают по очереди, а процессоры воркеров в это время простаивают. > > Если бы воркеры были асинхронными, то можно было бы запустить 8 воркеров > (по числу ядер на машине), и на каждый воркер хранилась бы всего одна копия > графа. Внезапно высвободилась бы куча памяти, которой бы нашлось лучшее > применение (дисковые кэши, memcached и т.д.) > > > Вау, мы такую задачу решали на перле лет этак 6 назад. > prefork + map + async + немного xs. > Решили так: > 1) маппили файл с графом на память > 2) prefork > 3) перед тем как найти путь или перестроить граф делали flock ( для > изменения LOCK_EX, для построения LOCK_SH) > 4) поиск пути делался XS функцей(получалось сильно быстрее), а все > остальное на perl > > 1) В итоге граф не клонируется между форками > 2) Все процессоры могут поучаствовать в расчете пути. > 3) единственный минус изменение пути может выполнять один процессор. > Угу, хорошее решение. По факту, возможности, отсутствующие в перле (разделение данных), вы переписали на C. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From aml на rulezz.ru Mon Feb 9 06:30:16 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Mon, 09 Feb 2015 14:30:16 +0000 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= References: <002101d04440$e0cecf70$a26c6e50$@tsu.ru> <002d01d04445$00a4fff0$01eeffd0$@tsu.ru> Message-ID: > > > Всё выбросить и переписать - это для богатых :) Работает - не трогай. > зачем - выбросить? остановить одного воркера из 50, и вместо него > запустить нового. и посмотреть, как справляется. > Это не единственное место, где воркеры память жрут. Ещё бывает, что надо из базы данных выбрать много данных, чтобы сформировать ответ. Например, у меня есть монитор цен по магазинам всего мира в игре: надо получить список магазинов, отфильтровать те, к которым игрок не имеет доступа, загрузить ассортимент их товаров, сформировать отчёт, показать игроку. Память отводится под ответ базы, потом освобождается, но Perl так устроен, что операционке память уже никогда не возвращает. В результате, воркеры запускаются небольшими, а со временем толстеют. Я их прибиваю после каждой 1000 обработанных запросов, но всё равно - они успевают прилично растолстеть, и в среднем занимают много памяти. Асинхронное приложение от этой проблемы тоже бы не страдало. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From aml на rulezz.ru Mon Feb 9 06:32:11 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Mon, 09 Feb 2015 14:32:11 +0000 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> <1009399030.20150209165019@softsearch.ru> <117390181.20150209172540@softsearch.ru> Message-ID: Вот и ноду обогнали :) On Mon Feb 09 2015 at 3:26:24 PM Михаил Монашёв wrote: > Здравствуйте, Alexander. > > > Запускать с GOMAXPROCS=8 > > Вот такой посмотри: https://play.golang.org/p/UDN6j8dB5x > > Забыл совсем про это. Вышло 17ms. > > > -- > С уважением, > Михаил mailto:postmaster на softsearch.ru > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From postmaster на softsearch.ru Mon Feb 9 06:33:16 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Mon, 9 Feb 2015 17:33:16 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: References: Message-ID: <17510262042.20150209173316@softsearch.ru> Здравствуйте, Alexander. > 1. Если у тебя производительность не упирается в CPU, увеличение > качества компилируемого кода не даст настолько большого ускорения. > Если ты картинки ресайзишь основное время - это один разговор. Если > только и делаешь, что базу данных ждёшь, то другой. Всё верно. Кстати, упираться в CPU, как я тут недавно узнал, можно очень по разному. Данные могут не успевать читаться/писаться из/в памяти из-за того, что в кэш процессора они не попадают, инструкции не могут выполняться параллельно из-за того, что логически связаны, предсказатель ветвлений может плохо предсказывать из-за кучи меняющихся условий, блоки процессора, отвечающие, например, за вычисление адреса в памяти, заняты чем-то и т.д. > 2. Посмотри ещё gccgo - это альтернативный компилятор. Может быть, он поддерживает всякие -O3 и SIMD. Я не смотрел на него сам, правда. Я сам не пробовал, но читал где-то, что у него есть проблема: он горутины заменяет на обычные треды. -- С уважением, Михаил mailto:postmaster на softsearch.ru From pef-secure на yandex.ru Mon Feb 9 06:38:06 2015 From: pef-secure на yandex.ru (PEF Secure) Date: Mon, 09 Feb 2015 15:38:06 +0100 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: <54D87696.6090201@rambler.ru> References: <54D87696.6090201@rambler.ru> Message-ID: <3347111.ZmatzggfzH@rawen> On Monday, February 09, 2015 11:57:58 Анатолий Гришаев wrote: > 2) При большом количестве потоков у ядра вырастают накладные расходы на > переключение потоков. > В случае большой нагрузки вообще говоря количество потоков > вырастает(threads), а в случае асинхронной программы это количесто не > меняется, поэтому > асинхронная модель будет выигрывать за счет накладных расходов ядра системы. Считается, что потоки программы, завязанные на сетевой IO, по большей части мирно спят. А зачем ядру будить спящие потоки? Поэтому, я бы хотел услышать доказательства этого тезиса. Ну, типа: "было исследование, вот ссылка"... Каждый тред -- отдельный стек. Сколько дадим? Допустим, 64кб. 10 тыс тредов, это 640мб стека. Не так уж и много. Время на сканирование очереди из 10к тредов чтобы передать управление -- только те, что не спят, а по статистике, работает одновременно всего 3-5%% соединений, это 500 тредов максимум. Современному процессору это раз плюнуть. Самое неприятное в переключении контекстов -- сброс кешей, но в серверные процессоры их не просто так по много мегабайт ставят. Вобщем, несмотря на то, что асинхронная модель не требует отдельных контекстов, стеков и прочего, треды не так уж безнадёжны. Самый главный минус тредов -- их нет в перле. На этом можно про них и закончить. > 3) Асинхронная программа это однопоточная программа. А поскольку > отлаживать однопоточную программу проще чем многопоточную, то > и отлаживать асинхронную программу легче, чем программу с потоками. Кроме логов я способа отладки не знаю. В этом случае мне всё равно что там с потоками. > 4) В асинхронной программе не нужны средства синхронизации потоков(Из-за > многопоточности), которые просто необходимы в потоках. Ах, если бы. Дайте мне, пожалуйста, _нормальное_ средство синхронизации между процессами, простого мьютекса мне было б уже достаточно. А то в итоге лок- менеджеры или прости господи файловые локи приходится делать... > Накладные расходы на синхронизацию не ускоряют поточные программы и > иногда могут быть просто чудовищными. > 100-200 циклов процессора минимум на одном примитиве. Уж лучше синхронизировать доступ, чем удивляться некорректному поведению. > Слегка не в тему, но для полноты > 5) forkи проще концептуально и приводят к меньшему количеству ошибок в > программировании, значит отлаживать будет меньше. Это просто синхронное программирование проще. Как раз параллелизация на форках уже заметно сложнее. -- PEF Developer From pef-secure на yandex.ru Mon Feb 9 06:40:32 2015 From: pef-secure на yandex.ru (PEF Secure) Date: Mon, 09 Feb 2015 15:40:32 +0100 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: <2036D7A8-A6BA-47AC-9F87-F67D1C0C2D34@corp.mail.ru> References: <2568912.XdEKZjtt8b@rawen> <2036D7A8-A6BA-47AC-9F87-F67D1C0C2D34@corp.mail.ru> Message-ID: <3162725.PxWo5lW6aH@rawen> On Monday, February 09, 2015 12:11:23 Mons Anderson wrote: > Вы не путаете-ли с Coro? Не совсем. Дело в том, что AE невозможно поставить без Coro, кондвар-ы работать без него не смогут. > Никто не за кого не думал и никакие потоки там не усыпляются, т.к. их нет. К словам цепляться будем? Мне не в падлу и перестать тут общаться. -- PEF Developer From foxcool333 на gmail.com Mon Feb 9 06:42:11 2015 From: foxcool333 на gmail.com (Foxcool) Date: Mon, 09 Feb 2015 17:42:11 +0300 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: <3347111.ZmatzggfzH@rawen> References: <54D87696.6090201@rambler.ru> <3347111.ZmatzggfzH@rawen> Message-ID: <54D8C743.4080209@gmail.com> В шестом Перле появляется штука под названием каналы. Я не вдавался в подробности, но по-моему это как раз на тему многопоточности. From pef-secure на yandex.ru Mon Feb 9 06:43:37 2015 From: pef-secure на yandex.ru (PEF Secure) Date: Mon, 09 Feb 2015 15:43:37 +0100 Subject: [Moscow.pm] =?utf-8?b?0L/RgNC+INC30L7QvtC/0LDRgNC6INGC0LXRhdC9?= =?utf-8?b?0L7Qu9C+0LPQuNC5?= In-Reply-To: References: <807709452.20150208213924@softsearch.ru> Message-ID: <2046966.KeEXEpWOrg@rawen> On Monday, February 09, 2015 10:55:49 Ксения Боброва wrote: > ну посмейтесь. > в джаве треды есть, что снимает огромное количество проблем. > остальные преимущества джавы перед перлом можно перечислять бесконечно)) > Остальных преимуществ там нет. Есть много недостатков. -- PEF Developer From eugene.toropov на gmail.com Mon Feb 9 06:45:30 2015 From: eugene.toropov на gmail.com (Eugene Toropov) Date: Mon, 9 Feb 2015 17:45:30 +0300 Subject: [Moscow.pm] =?koi8-r?b?9MXN2SDEzNEgxM/LzMHEz9c=?= In-Reply-To: <3162725.PxWo5lW6aH@rawen> References: <2568912.XdEKZjtt8b@rawen> <2036D7A8-A6BA-47AC-9F87-F67D1C0C2D34@corp.mail.ru> <3162725.PxWo5lW6aH@rawen> Message-ID: <0BD44B60-1D5A-4A01-AFE0-44F9D9860B35@gmail.com> > On Feb 9, 2015, at 5:40 PM, PEF Secure wrote: > > On Monday, February 09, 2015 12:11:23 Mons Anderson wrote: >> Вы не путаете-ли с Coro? > > Не совсем. Дело в том, что AE невозможно поставить без Coro, кондвар-ы > работать без него не смогут. Чувак, ты реально напутал. Попробуй поставить AE - никакой Коро там нафиг не нужен. И потоков там нет никаких - мы поэтому и уходили в свое время на Коро с AE Евгений From postmaster на softsearch.ru Mon Feb 9 06:49:35 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Mon, 9 Feb 2015 17:49:35 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> <1009399030.20150209165019@softsearch.ru> <117390181.20150209172540@softsearch.ru> Message-ID: <6505964.20150209174935@softsearch.ru> Здравствуйте, Alexander. > Вот и ноду обогнали :-) Ну это не совсем честно, ИМХО. Да и посмотри, как сильно читаемость кода ухудшилась! Переписал через слайсы, чтобы перейти в цикле к сравнению с нулём (что намного быстрее): https://play.golang.org/p/SZYYqGDmQY и стало 11ms. -- С уважением, Михаил mailto:postmaster на softsearch.ru From onokonem на gmail.com Mon Feb 9 06:51:39 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Mon, 9 Feb 2015 18:51:39 +0400 Subject: [Moscow.pm] =?utf-8?b?0L/RgNC+INC30L7QvtC/0LDRgNC6INGC0LXRhdC9?= =?utf-8?b?0L7Qu9C+0LPQuNC5?= In-Reply-To: <2046966.KeEXEpWOrg@rawen> References: <807709452.20150208213924@softsearch.ru> <2046966.KeEXEpWOrg@rawen> Message-ID: >> остальные преимущества джавы перед перлом можно перечислять бесконечно)) > Остальных преимуществ там нет. Есть много недостатков. вообще-то - есть, и я готов рассказать о преимуществах jvm перед перловой vm (не java, конечно же, java - просто один из языков для jvm) а вот про недостатки - прошу подробнее, пожалуйста. раз уж мы про зоопарк. From akovbovich на gmail.com Mon Feb 9 06:55:07 2015 From: akovbovich на gmail.com (Andrey Kovbovich) Date: Mon, 9 Feb 2015 18:55:07 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: <1423488838.964261072@f365.i.mail.ru> References: <1423488838.964261072@f365.i.mail.ru> Message-ID: Прошу развернуть свою мысль. Если для тебя асинхронно значит мультиплексирование коннектов через один канал, то наверное мы о разном немного. понедельник, 9 февраля 2015 г. пользователь Warstone на list.ru написал: > Неверно в принципе, ну да ладно... > > Понедельник, 09 февраля 2015, 17:09 +04:00 от Andrey Kovbovich < > akovbovich на gmail.com > >: > > Асинхронно - это когда несколько потоков исполнения работают как им > возблагорассудиться, а синхронно - это когда потоки работают в соответствии > некому генератору квантов логического времени > > понедельник, 9 февраля 2015 г. пользователь Daniel Podolsky написал: > > > Добавлять воркеров я уже не могу - их 50 штук на сервере выполняется, и > > больше уже памяти нет. > Хочу подробностей! Что это за воркеры такие злые? Почему асинхронному > приложению эта память не понадобится? Может, и синхронному не нужна? > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > > -- > Moscow.pm mailing list > moscow-pm на pm.org | > http://moscow.pm.org > > > Собственно тут вроде-бы еще не проскальзывала мысль, что асинхронность, > при условии достаточности ресурсов - это всегда медленнее чем синхронность. > Например: Я зажевал в один поток все сообщения, раздал запросы на данные и > обрабатываю результаты.... Пока я обрабатываю один результат, остальные > стоят. В случае с синхронным форком такого-бы не было (у нас много ядер). > > Проблема назревает когда у нас бекэнд (то, что отвечает на запросы), > обрабатывает запрос долго. Но в этом случае какая, нафиг, кому разница - > где делается "асинхронность" - у нас в лупе или в ядре при свитче > контекста. Бек все-равно дольше... > > Асинхронность нужна в некоторых случаях: > - Если у вас стоимость свитча контекста гораздо дороже ответа от бэка (по > времени), но при переходе на асинк у вас еще будет дофига ресурсов ЦПУ (так > как свитч контекста - это ЦПУ задача). > - Если у вас асинк дает другие преимущества (в то числе и "потому что его > умеют готовить разработчики, а вот с форком им сложно"). > - Если у вас задача "обработать данные, зная что у вас в очереди всегда > есть следующие задачи". Допустим быстрое преобразование фурье с отсылкой > результатов далее по конвееру. (Привет SETI на Home) > Вот тогда - да. Тогда есть у > вас CPU баунд задача и вам важны такты процессора. > > На практике мы всегда боимся 1го, но зачастую протормозы в беках гораздо > больше. > > ЗЫ: Тоже поучаствовать решил. > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From foxcool333 на gmail.com Mon Feb 9 07:00:15 2015 From: foxcool333 на gmail.com (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCk0L7QutGB0LrRg9C7?=) Date: Mon, 9 Feb 2015 19:00:15 +0400 Subject: [Moscow.pm] =?utf-8?b?0L/RgNC+INC30L7QvtC/0LDRgNC6INGC0LXRhdC9?= =?utf-8?b?0L7Qu9C+0LPQuNC5?= In-Reply-To: <2046966.KeEXEpWOrg@rawen> References: <807709452.20150208213924@softsearch.ru> <2046966.KeEXEpWOrg@rawen> Message-ID: Я бы еще разделял понятие синтаксиса и реализации. Реализация у перла говно. А у джавы язык говно. Вот и все дела. 09.02.2015 17:45 пользователь "PEF Secure" написал: > On Monday, February 09, 2015 10:55:49 Ксения Боброва wrote: > > ну посмейтесь. > > в джаве треды есть, что снимает огромное количество проблем. > > остальные преимущества джавы перед перлом можно перечислять бесконечно)) > > > > Остальных преимуществ там нет. Есть много недостатков. > -- > PEF Developer > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From pef-secure на yandex.ru Mon Feb 9 07:05:08 2015 From: pef-secure на yandex.ru (PEF Secure) Date: Mon, 09 Feb 2015 16:05:08 +0100 Subject: [Moscow.pm] =?utf-8?b?0L/RgNC+INC30L7QvtC/0LDRgNC6INGC0LXRhdC9?= =?utf-8?b?0L7Qu9C+0LPQuNC5?= In-Reply-To: References: <807709452.20150208213924@softsearch.ru> <2046966.KeEXEpWOrg@rawen> Message-ID: <5008121.RW1j0514ZB@rawen> On Monday, February 09, 2015 18:51:39 Daniel Podolsky wrote: > >> остальные преимущества джавы перед перлом можно перечислять бесконечно)) > > > > Остальных преимуществ там нет. Есть много недостатков. > > вообще-то - есть, и я готов рассказать о преимуществах jvm перед > перловой vm (не java, конечно же, java - просто один из языков для > jvm) > > а вот про недостатки - прошу подробнее, пожалуйста. раз уж мы про зоопарк. Главный недостаток -- жуткая многословность. Нужно посчитать SHA1 по прочитанной из сокета строке. Алгоритм: берём фабрику, она создаёт нам класс- алгоритм SHA1, который считает дайджест побайтно, потом эти байты мы в хекс конвертируем. Всё это надо обернуть в try/catch, а то мало ли, не нашлось вдруг алгоритма на фабрике. Итоговый код длинный, много лишних действий, читать это намного труднее, чем просто перловый sha1_hex($str). И так там на каждом шагу. -- PEF Developer From aml на rulezz.ru Mon Feb 9 07:08:54 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Mon, 09 Feb 2015 15:08:54 +0000 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> <1009399030.20150209165019@softsearch.ru> <117390181.20150209172540@softsearch.ru> <6505964.20150209174935@softsearch.ru> Message-ID: Конечно, не честно. Просто есть много трейд-оффов при разработке языков. В результате, у каждого языка есть свои слабые стороны. Надо просто под конкретную задачу выбирать технологию. Если тебе надо числа гигабайтами складывать, пиши на C. Если 10K открытых соединений держать, то на чем-то асинхронном. Что касается читаемости. Попробуй напиши тот же алгоритм на C, Java или на node.js (там есть web workers для параллелизации) и сравни код, что получится, с Go. Я ещё не видел более лаконичного языка для описания параллелизации. On Mon, Feb 9, 2015, 15:50 Михаил Монашёв wrote: > Здравствуйте, Alexander. > > > Вот и ноду обогнали :-) > > Ну это не совсем честно, ИМХО. Да и посмотри, как сильно читаемость > кода ухудшилась! > > Переписал через слайсы, чтобы перейти в цикле к сравнению с нулём (что > намного быстрее): https://play.golang.org/p/SZYYqGDmQY и стало 11ms. > > -- > С уважением, > Михаил mailto:postmaster на softsearch.ru > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From eugene.toropov на gmail.com Mon Feb 9 07:09:55 2015 From: eugene.toropov на gmail.com (Eugene Toropov) Date: Mon, 9 Feb 2015 18:09:55 +0300 Subject: [Moscow.pm] =?utf-8?b?0L/RgNC+INC30L7QvtC/0LDRgNC6INGC0LXRhdC9?= =?utf-8?b?0L7Qu9C+0LPQuNC5?= In-Reply-To: <5008121.RW1j0514ZB@rawen> References: <807709452.20150208213924@softsearch.ru> <2046966.KeEXEpWOrg@rawen> <5008121.RW1j0514ZB@rawen> Message-ID: Многословность есть, но sha1 - плохой пример ибо String sha1password = DigestUtils.sha1Hex(password); http://commons.apache.org/proper/commons-codec/apidocs/org/apache/commons/codec/digest/DigestUtils.html Евгений > On Feb 9, 2015, at 6:05 PM, PEF Secure wrote: > > On Monday, February 09, 2015 18:51:39 Daniel Podolsky wrote: >>>> остальные преимущества джавы перед перлом можно перечислять бесконечно)) >>> >>> Остальных преимуществ там нет. Есть много недостатков. >> >> вообще-то - есть, и я готов рассказать о преимуществах jvm перед >> перловой vm (не java, конечно же, java - просто один из языков для >> jvm) >> >> а вот про недостатки - прошу подробнее, пожалуйста. раз уж мы про зоопарк. > > Главный недостаток -- жуткая многословность. Нужно посчитать SHA1 по > прочитанной из сокета строке. Алгоритм: берём фабрику, она создаёт нам класс- > алгоритм SHA1, который считает дайджест побайтно, потом эти байты мы в хекс > конвертируем. Всё это надо обернуть в try/catch, а то мало ли, не нашлось > вдруг алгоритма на фабрике. Итоговый код длинный, много лишних действий, > читать это намного труднее, чем просто перловый sha1_hex($str). И так там на > каждом шагу. > > -- > PEF Developer > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From eugene.toropov на gmail.com Mon Feb 9 07:11:01 2015 From: eugene.toropov на gmail.com (Eugene Toropov) Date: Mon, 9 Feb 2015 18:11:01 +0300 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= In-Reply-To: References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> <1009399030.20150209165019@softsearch.ru> <117390181.20150209172540@softsearch.ru> <6505964.20150209174935@softsearch.ru> Message-ID: <51702301-8221-4BEA-8C89-09D77185F7BD@gmail.com> > Я ещё не видел более лаконичного языка для описания параллелизации. > > +100500 ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From onokonem на gmail.com Mon Feb 9 07:17:07 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Mon, 9 Feb 2015 19:17:07 +0400 Subject: [Moscow.pm] =?utf-8?b?0L/RgNC+INC30L7QvtC/0LDRgNC6INGC0LXRhdC9?= =?utf-8?b?0L7Qu9C+0LPQuNC5?= In-Reply-To: <5008121.RW1j0514ZB@rawen> References: <807709452.20150208213924@softsearch.ru> <2046966.KeEXEpWOrg@rawen> <5008121.RW1j0514ZB@rawen> Message-ID: > Главный недостаток -- жуткая многословность. в награду за эту многословность компилятор ловит нам больше ошибок но мы же говорили об эксплуатации! речь идет о преимуществах jvm перед perl vm, а не о преимуществах языка java перед языком perl. ps главное преимущество языка java перед языком perl - наличие формального описания грамматики. не могу удержаться, извините. From pef-secure на yandex.ru Mon Feb 9 07:15:30 2015 From: pef-secure на yandex.ru (PEF Secure) Date: Mon, 09 Feb 2015 16:15:30 +0100 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: <0BD44B60-1D5A-4A01-AFE0-44F9D9860B35@gmail.com> References: <3162725.PxWo5lW6aH@rawen> <0BD44B60-1D5A-4A01-AFE0-44F9D9860B35@gmail.com> Message-ID: <1966072.6nRWdhgONy@rawen> On Monday, February 09, 2015 17:45:30 Eugene Toropov wrote: > > On Feb 9, 2015, at 5:40 PM, PEF Secure wrote: > > > > On Monday, February 09, 2015 12:11:23 Mons Anderson wrote: > >> Вы не путаете-ли с Coro? > > > > Не совсем. Дело в том, что AE невозможно поставить без Coro, кондвар-ы > > работать без него не смогут. > > Чувак, ты реально напутал. Попробуй поставить AE - никакой Коро там нафиг не > нужен. И потоков там нет никаких - мы поэтому и уходили в свое время на > Коро с AE > > Евгений AE/Coro должны работать вместе. -- PEF Developer From eugene.toropov на gmail.com Mon Feb 9 07:21:11 2015 From: eugene.toropov на gmail.com (Eugene Toropov) Date: Mon, 9 Feb 2015 18:21:11 +0300 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: <1966072.6nRWdhgONy@rawen> References: <3162725.PxWo5lW6aH@rawen> <0BD44B60-1D5A-4A01-AFE0-44F9D9860B35@gmail.com> <1966072.6nRWdhgONy@rawen> Message-ID: > > On Feb 9, 2015, at 6:15 PM, PEF Secure wrote: > > On Monday, February 09, 2015 17:45:30 Eugene Toropov wrote: >>> On Feb 9, 2015, at 5:40 PM, PEF Secure wrote: >>> >>> On Monday, February 09, 2015 12:11:23 Mons Anderson wrote: >>>> Вы не путаете-ли с Coro? >>> >>> Не совсем. Дело в том, что AE невозможно поставить без Coro, кондвар-ы >>> работать без него не смогут. >> >> Чувак, ты реально напутал. Попробуй поставить AE - никакой Коро там нафиг не >> нужен. И потоков там нет никаких - мы поэтому и уходили в свое время на >> Коро с AE >> >> Евгений > > AE/Coro должны работать вместе. > Они могут работать вместе благодаря http://search.cpan.org/~mlehmann/Coro-6.41/Coro/AnyEvent.pm , но никто вам не запрещает использовать одно без другого ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From warstone на list.ru Mon Feb 9 07:24:01 2015 From: warstone на list.ru (=?UTF-8?B?V2Fyc3RvbmVAbGlzdC5ydQ==?=) Date: Mon, 09 Feb 2015 18:24:01 +0300 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC90L4=?= =?utf-8?b?0LzQuNGC0Ywg0YDQtdGB0YPRgNGB0Ysg0YHQtdGA0LLQtdGA0L7Qsg==?= In-Reply-To: References: <1423488838.964261072@f365.i.mail.ru> Message-ID: <1423495441.760598539@f437.i.mail.ru> Асинхронно в любом случае будет "в порядке очереди событий, как тебе ядро сгенерит". select не беру в рассмотрение. Или мы уже асинк не через epoll/kqueue научились делать? Синхронно - это "я жду ответа", а как меня там ОС будет менеджерить - это проблемы ОС, а не мои. Понедельник, 09 февраля 2015, 18:55 +04:00 от Andrey Kovbovich : >Прошу развернуть свою мысль. Если для тебя асинхронно значит мультиплексирование коннектов через один канал, то наверное мы о разном немного. > >понедельник, 9 февраля 2015 г. пользователь Warstone на list.ru написал: >>Неверно в принципе, ну да ладно... >> >>Понедельник, 09 февраля 2015, 17:09 +04:00 от Andrey Kovbovich < akovbovich на gmail.com >: >>>Асинхронно - это когда несколько потоков исполнения работают как им возблагорассудиться, а синхронно - это когда потоки работают в соответствии некому генератору квантов логического  времени >>> >>>понедельник, 9 февраля 2015 г. пользователь Daniel Podolsky написал: >>>>> Добавлять воркеров я уже не могу - их 50 штук на сервере выполняется, и >>>>> больше уже памяти нет. >>>>Хочу подробностей! Что это за воркеры такие злые? Почему асинхронному >>>>приложению эта память не понадобится? Может, и синхронному не нужна? >>>>-- >>>>Moscow.pm mailing list >>>>moscow-pm на pm.org  | http://moscow.pm.org >>>-- >>>Moscow.pm mailing list >>>moscow-pm на pm.org | http://moscow.pm.org >> >>Собственно тут вроде-бы еще не проскальзывала мысль, что асинхронность, при условии достаточности ресурсов - это всегда медленнее чем синхронность. Например: Я зажевал в один поток все сообщения, раздал запросы на данные и обрабатываю результаты.... Пока я обрабатываю один результат, остальные стоят. В случае с синхронным форком такого-бы не было (у нас много ядер). >> >>Проблема назревает когда у нас бекэнд (то, что отвечает на запросы), обрабатывает запрос долго. Но в этом случае какая, нафиг, кому разница - где делается "асинхронность" - у нас в лупе или в ядре при свитче контекста. Бек все-равно дольше... >> >>Асинхронность нужна в некоторых случаях: >>- Если у вас стоимость свитча контекста гораздо дороже ответа от бэка (по времени), но при переходе на асинк у вас еще будет дофига ресурсов ЦПУ (так как свитч контекста - это ЦПУ задача). >>- Если у вас асинк дает другие преимущества (в то числе и "потому что его умеют готовить разработчики, а вот с форком им сложно"). >>- Если у вас задача "обработать данные, зная что у вас в очереди всегда есть следующие задачи". Допустим быстрое преобразование фурье с отсылкой результатов далее по конвееру. (Привет SETI на Home) Вот тогда - да. Тогда есть у вас CPU баунд задача и вам важны такты процессора. >> >>На практике мы всегда боимся 1го, но зачастую протормозы в беках гораздо больше. >> >>ЗЫ: Тоже поучаствовать решил. >-- >Moscow.pm mailing list >moscow-pm на pm.org | http://moscow.pm.org ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From onokonem на gmail.com Mon Feb 9 07:27:35 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Mon, 9 Feb 2015 19:27:35 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: <1423495441.760598539@f437.i.mail.ru> References: <1423488838.964261072@f365.i.mail.ru> <1423495441.760598539@f437.i.mail.ru> Message-ID: 2015-02-09 18:24 GMT+03:00 Warstone на list.ru : > Асинхронно в любом случае будет "в порядке очереди событий, как тебе ядро > сгенерит". select не беру в рассмотрение. Или мы уже асинк не через > epoll/kqueue научились делать? > Синхронно - это "я жду ответа", а как меня там ОС будет менеджерить - это > проблемы ОС, а не мои. это про кооперативную и вытесняющую многозадачность, а не про асинхронность и синхронность. From warstone на list.ru Mon Feb 9 07:41:54 2015 From: warstone на list.ru (=?UTF-8?B?V2Fyc3RvbmVAbGlzdC5ydQ==?=) Date: Mon, 09 Feb 2015 18:41:54 +0300 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC90L4=?= =?utf-8?b?0LzQuNGC0Ywg0YDQtdGB0YPRgNGB0Ysg0YHQtdGA0LLQtdGA0L7Qsg==?= In-Reply-To: References: <1423495441.760598539@f437.i.mail.ru> Message-ID: <1423496514.555747044@f417.i.mail.ru> Не совсем... Это про синхронность и асинхронность и как этого добиваются в многозадачной системе. Понедельник, 09 февраля 2015, 19:27 +04:00 от Daniel Podolsky : >2015-02-09 18:24 GMT+03:00 Warstone на list.ru < warstone на list.ru >: >> Асинхронно в любом случае будет "в порядке очереди событий, как тебе ядро >> сгенерит". select не беру в рассмотрение. Или мы уже асинк не через >> epoll/kqueue научились делать? >> Синхронно - это "я жду ответа", а как меня там ОС будет менеджерить - это >> проблемы ОС, а не мои. >это про кооперативную и вытесняющую многозадачность, а не про >асинхронность и синхронность. >-- >Moscow.pm mailing list >moscow-pm на pm.org | http://moscow.pm.org ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From postmaster на softsearch.ru Mon Feb 9 07:42:11 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Mon, 9 Feb 2015 18:42:11 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: <6505964.20150209174935@softsearch.ru> References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> <1009399030.20150209165019@softsearch.ru> <117390181.20150209172540@softsearch.ru> <6505964.20150209174935@softsearch.ru> Message-ID: <401626144.20150209184211@softsearch.ru> Здравствуйте, Alexander. >> Вот и ноду обогнали :-) > Ну это не совсем честно, ИМХО. Да и посмотри, как сильно читаемость > кода ухудшилась! > Переписал через слайсы, чтобы перейти в цикле к сравнению с нулём (что > намного быстрее): https://play.golang.org/p/SZYYqGDmQY и стало 11ms. Кстати, что странно, время выполнения этого кода прыгает иногда в 2 раза. И профайлер VTune показывает в таких случаях очень большой Spin Time: Elapsed Time: 0.382s Total Thread Count: 5 Paused Time: 0s CPU Time: 0.063s Spin Time: 0.011s <--- почти столько же, сколько работает наше суммирование Overhead Time: 0s Effective Time: 0.052s Idle: 0.000s Poor: 0.052s Ok: 0s Ideal: 0s Over: 0s Top Hotspots Function CPU Time runtime.memclr 0.026s <--- это освобождение памяти после окончания работы main.main 0.017s <--- это выделение памяти и заполнение массива первичными данными WaitForSingleObject 0.011s <--- это какие-то непонятные локи в kernel32.dll main.func╥001 0.009s <---- это код, работающий в горутине, который мы собственно и замеряем Есть мысли, что это и как избегать? -- С уважением, Михаил mailto:postmaster на softsearch.ru From onokonem на gmail.com Mon Feb 9 07:46:06 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Mon, 9 Feb 2015 19:46:06 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: <1423496514.555747044@f417.i.mail.ru> References: <1423495441.760598539@f437.i.mail.ru> <1423496514.555747044@f417.i.mail.ru> Message-ID: > Не совсем... Это про синхронность и асинхронность и как этого добиваются в > многозадачной системе. синхронность и асинхронность - это только про то, как мы получаем результат попытки ввода-вывода. ну - если не выдумывать новых значений для устоявшегося термина. From warstone на list.ru Mon Feb 9 07:49:44 2015 From: warstone на list.ru (=?UTF-8?B?V2Fyc3RvbmVAbGlzdC5ydQ==?=) Date: Mon, 09 Feb 2015 18:49:44 +0300 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC90L4=?= =?utf-8?b?0LzQuNGC0Ywg0YDQtdGB0YPRgNGB0Ysg0YHQtdGA0LLQtdGA0L7Qsg==?= In-Reply-To: References: <1423496514.555747044@f417.i.mail.ru> Message-ID: <1423496983.391800857@f405.i.mail.ru> Ну так примерно это я и сказал... Хотя, признаюсь, для асинхронности пропустил пару шагов. Надо было написать "это когда мы не ждем ответа на запрос, но прочитаем его позже". Понедельник, 09 февраля 2015, 19:46 +04:00 от Daniel Podolsky : >> Не совсем... Это про синхронность и асинхронность и как этого добиваются в >> многозадачной системе. >синхронность и асинхронность - это только про то, как мы получаем >результат попытки ввода-вывода. ну - если не выдумывать новых значений >для устоявшегося термина. >-- >Moscow.pm mailing list >moscow-pm на pm.org | http://moscow.pm.org ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From aml на rulezz.ru Mon Feb 9 08:09:30 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Mon, 09 Feb 2015 16:09:30 +0000 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> <1009399030.20150209165019@softsearch.ru> <117390181.20150209172540@softsearch.ru> <6505964.20150209174935@softsearch.ru> <401626144.20150209184211@softsearch.ru> Message-ID: Прерывание процесса наверняка операционкой. Увеличь размер данных раз в 1000 - будет меньше прыгать. On Mon, Feb 9, 2015, 16:42 Михаил Монашёв wrote: > Здравствуйте, Alexander. > > >> Вот и ноду обогнали :-) > > > Ну это не совсем честно, ИМХО. Да и посмотри, как сильно читаемость > > кода ухудшилась! > > > Переписал через слайсы, чтобы перейти в цикле к сравнению с нулём (что > > намного быстрее): https://play.golang.org/p/SZYYqGDmQY и стало 11ms. > > Кстати, что странно, время выполнения этого кода прыгает иногда в 2 > раза. И профайлер VTune показывает в таких случаях очень большой Spin > Time: > > Elapsed Time: 0.382s > Total Thread Count: 5 > Paused Time: 0s > CPU Time: 0.063s > Spin Time: 0.011s <--- почти столько же, сколько работает > наше суммирование > Overhead Time: 0s > Effective Time: 0.052s > Idle: 0.000s > Poor: 0.052s > Ok: 0s > Ideal: 0s > Over: 0s > > Top Hotspots > Function CPU Time > runtime.memclr 0.026s <--- это освобождение памяти после окончания > работы > main.main 0.017s <--- это выделение памяти и заполнение массива > первичными данными > WaitForSingleObject 0.011s <--- это какие-то непонятные локи в > kernel32.dll > main.func╥001 0.009s <---- это код, работающий в горутине, который > мы собственно и замеряем > > Есть мысли, что это и как избегать? > > -- > С уважением, > Михаил mailto:postmaster на softsearch.ru > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From onokonem на gmail.com Mon Feb 9 08:31:33 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Mon, 9 Feb 2015 20:31:33 +0400 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= In-Reply-To: References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> <1009399030.20150209165019@softsearch.ru> <117390181.20150209172540@softsearch.ru> Message-ID: тот первый вариант на go, для масштаба The call took 12.588269ms to run. Sum is 49999995000000 обгоняющий ноду при GOMAXPROCS=1 The call took 17.580054ms to run. Sum is 49999995000000 обгоняющий ноду при GOMAXPROCS=8 The call took 4.3454ms to run. Sum is 49999995000000 Lua 5.2.3, http://pastebin.com/1PmmJtFF The call took 214.273214ms to run. Sum is 49999995000000 luajit чет капризничает Groovy Version: 2.4.0 JVM: 1.7.0_67, http://pastebin.com/EvsE9Es1 The call took 9ms to run. Sum is 49999995000000 интересно, что оноже, но скомпиленной в jar и запущенное java The call took 27ms to run. Sum is 49999995000000 java, http://pastebin.com/Np2vAVza The call took 7ms to run. Sum is 49999995000000 к вопросу о том, что такое jit и зачем он нужен: http://pastebin.com/E7r8piXt The call took 7ms to run. Sum is 49999995000000 The call took 4ms to run. Sum is 49999995000000 The call took 4ms to run. Sum is 49999995000000 2015-02-09 17:32 GMT+03:00 Alexander Lourier : > Вот и ноду обогнали :) > > On Mon Feb 09 2015 at 3:26:24 PM Михаил Монашёв > wrote: >> >> Здравствуйте, Alexander. >> >> > Запускать с GOMAXPROCS=8 >> > Вот такой посмотри: https://play.golang.org/p/UDN6j8dB5x >> >> Забыл совсем про это. Вышло 17ms. >> >> >> -- >> С уважением, >> Михаил mailto:postmaster на softsearch.ru >> >> -- >> Moscow.pm mailing list >> moscow-pm на pm.org | http://moscow.pm.org > > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > From aml на rulezz.ru Mon Feb 9 09:05:51 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Mon, 09 Feb 2015 17:05:51 +0000 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> <1009399030.20150209165019@softsearch.ru> <117390181.20150209172540@softsearch.ru> Message-ID: Для Java можно тоже числа сделать 64-битными? :) On Mon Feb 09 2015 at 17:31:49 Daniel Podolsky wrote: > тот первый вариант на go, для масштаба > The call took 12.588269ms to run. Sum is 49999995000000 > > обгоняющий ноду при GOMAXPROCS=1 > The call took 17.580054ms to run. Sum is 49999995000000 > > обгоняющий ноду при GOMAXPROCS=8 > The call took 4.3454ms to run. Sum is 49999995000000 > > Lua 5.2.3, http://pastebin.com/1PmmJtFF > The call took 214.273214ms to run. Sum is 49999995000000 > > luajit чет капризничает > > Groovy Version: 2.4.0 JVM: 1.7.0_67, http://pastebin.com/EvsE9Es1 > The call took 9ms to run. Sum is 49999995000000 > > интересно, что оноже, но скомпиленной в jar и запущенное java > The call took 27ms to run. Sum is 49999995000000 > > java, http://pastebin.com/Np2vAVza > The call took 7ms to run. Sum is 49999995000000 > > к вопросу о том, что такое jit и зачем он нужен: > http://pastebin.com/E7r8piXt > The call took 7ms to run. Sum is 49999995000000 > The call took 4ms to run. Sum is 49999995000000 > The call took 4ms to run. Sum is 49999995000000 > > > > 2015-02-09 17:32 GMT+03:00 Alexander Lourier : > > Вот и ноду обогнали :) > > > > On Mon Feb 09 2015 at 3:26:24 PM Михаил Монашёв < > postmaster на softsearch.ru> > > wrote: > >> > >> Здравствуйте, Alexander. > >> > >> > Запускать с GOMAXPROCS=8 > >> > Вот такой посмотри: https://play.golang.org/p/UDN6j8dB5x > >> > >> Забыл совсем про это. Вышло 17ms. > >> > >> > >> -- > >> С уважением, > >> Михаил mailto:postmaster на softsearch.ru > >> > >> -- > >> Moscow.pm mailing list > >> moscow-pm на pm.org | http://moscow.pm.org > > > > > > -- > > Moscow.pm mailing list > > moscow-pm на pm.org | http://moscow.pm.org > > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From postmaster на softsearch.ru Mon Feb 9 09:16:17 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Mon, 9 Feb 2015 20:16:17 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: <401626144.20150209184211@softsearch.ru> References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> <1009399030.20150209165019@softsearch.ru> <117390181.20150209172540@softsearch.ru> <6505964.20150209174935@softsearch.ru> <401626144.20150209184211@softsearch.ru> Message-ID: <589450097.20150209201617@softsearch.ru> Здравствуйте. На том же компе, но на windows 7 64-bit Node.js - 31ms (http://pastebin.com/T1DVHNFM) А Go стал медленнее из-за того, что массив из int-ов стал вдвое длиннее. Но если вместо int явно задать uint32 то результаты сразу лучше, чем в ноде: без горутин 64-bit: 14ms https://play.golang.org/p/ojQUVxQEaH c горутинами 64-bit: 9ms https://play.golang.org/p/ptqnfBqLJk и в 32-битной венде тоже стало сразу быстрее: без горутин 32-bit: 22ms c горутинами 32-bit: 9ms Из-за того, что все операции только с беззнаковые целыми инструкции процессора сильно упростились и их почти вдвое стало меньше. -- С уважением, Михаил mailto:postmaster на softsearch.ru From onokonem на gmail.com Mon Feb 9 09:17:28 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Mon, 9 Feb 2015 21:17:28 +0400 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= In-Reply-To: References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> <1009399030.20150209165019@softsearch.ru> <117390181.20150209172540@softsearch.ru> Message-ID: > Для Java можно тоже числа сделать 64-битными? :) в каком смысле? sum там long, он 64 бита. From postmaster на softsearch.ru Mon Feb 9 09:20:22 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Mon, 9 Feb 2015 20:20:22 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> <1009399030.20150209165019@softsearch.ru> <117390181.20150209172540@softsearch.ru> Message-ID: <1692218297.20150209202022@softsearch.ru> Здравствуйте, Alexander. > Для Java можно тоже числа сделать 64-битными? :) http://docs.oracle.com/javase/7/docs/api/java/lang/Long.html Да и результат суммирования правильный. Если б было 32 бита, был бы неверный результат. -- С уважением, Михаил mailto:postmaster на softsearch.ru From aml на rulezz.ru Mon Feb 9 09:21:26 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Mon, 09 Feb 2015 17:21:26 +0000 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> <1009399030.20150209165019@softsearch.ru> <117390181.20150209172540@softsearch.ru> Message-ID: > > > Для Java можно тоже числа сделать 64-битными? :) > в каком смысле? sum там long, он 64 бита На 64-битном Go int 64-битный. А в Java 32-битный. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From onokonem на gmail.com Mon Feb 9 09:23:54 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Mon, 9 Feb 2015 21:23:54 +0400 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= In-Reply-To: References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> <1009399030.20150209165019@softsearch.ru> <117390181.20150209172540@softsearch.ru> Message-ID: 2015-02-09 20:21 GMT+03:00 Alexander Lourier : > На 64-битном Go int 64-битный. А в Java 32-битный. не знал groovy The call took 10ms to run. Sum is 49999995000000 java The call took 9ms to run. Sum is 49999995000000 The call took 6ms to run. Sum is 49999995000000 The call took 6ms to run. Sum is 49999995000000 это я тип массива в long переделал From postmaster на softsearch.ru Mon Feb 9 09:28:02 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Mon, 9 Feb 2015 20:28:02 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> <1009399030.20150209165019@softsearch.ru> <117390181.20150209172540@softsearch.ru> Message-ID: <65553360.20150209202802@softsearch.ru> Здравствуйте, Daniel. > java, http://pastebin.com/Np2vAVza > The call took 7ms to run. Sum is 49999995000000 > к вопросу о том, что такое jit и зачем он нужен: http://pastebin.com/E7r8piXt > The call took 7ms to run. Sum is 49999995000000 > The call took 4ms to run. Sum is 49999995000000 > The call took 4ms to run. Sum is 49999995000000 На Ноде такое не прокатило. Вынес суммирование в отдельную функцию, запустил её несколько раз, потом запустил уже с подсчётом времени: время такое же осталось. :-( 4ms - это мощно конечно. Наверняка без SIMD не обошлось. -- С уважением, Михаил mailto:postmaster на softsearch.ru From postmaster на softsearch.ru Mon Feb 9 09:30:13 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Mon, 9 Feb 2015 20:30:13 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> <1009399030.20150209165019@softsearch.ru> <117390181.20150209172540@softsearch.ru> Message-ID: <47994855.20150209203013@softsearch.ru> Здравствуйте, Daniel. >> На 64-битном Go int 64-битный. А в Java 32-битный. > не знал > groovy > The call took 10ms to run. Sum is 49999995000000 > java > The call took 9ms to run. Sum is 49999995000000 > The call took 6ms to run. Sum is 49999995000000 > The call took 6ms to run. Sum is 49999995000000 > это я тип массива в long переделал Зря. Там хранятся 32-битные числа. Зачем вдвое больше памяти лопатить? Попробуй вернуть их обратно в 32 бита и избавить от знака. Должно ещё быстрее стать. -- С уважением, Михаил mailto:postmaster на softsearch.ru From eugene.toropov на gmail.com Mon Feb 9 09:31:22 2015 From: eugene.toropov на gmail.com (Eugene Toropov) Date: Mon, 9 Feb 2015 20:31:22 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: <65553360.20150209202802@softsearch.ru> References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> <1009399030.20150209165019@softsearch.ru> <117390181.20150209172540@softsearch.ru> <65553360.20150209202802@softsearch.ru> Message-ID: Померьте память плз On 09 Feb 2015, at 20:28, Михаил Монашёв wrote: > Здравствуйте, Daniel. > >> java, http://pastebin.com/Np2vAVza >> The call took 7ms to run. Sum is 49999995000000 > >> к вопросу о том, что такое jit и зачем он нужен: http://pastebin.com/E7r8piXt >> The call took 7ms to run. Sum is 49999995000000 >> The call took 4ms to run. Sum is 49999995000000 >> The call took 4ms to run. Sum is 49999995000000 > > На Ноде такое не прокатило. Вынес суммирование в отдельную функцию, > запустил её несколько раз, потом запустил уже с подсчётом времени: > время такое же осталось. :-( > > 4ms - это мощно конечно. Наверняка без SIMD не обошлось. > > -- > С уважением, > Михаил mailto:postmaster на softsearch.ru > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org From onokonem на gmail.com Mon Feb 9 09:32:23 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Mon, 9 Feb 2015 21:32:23 +0400 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= In-Reply-To: <47994855.20150209203013@softsearch.ru> References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> <1009399030.20150209165019@softsearch.ru> <117390181.20150209172540@softsearch.ru> <47994855.20150209203013@softsearch.ru> Message-ID: 2015-02-09 20:30 GMT+03:00 Михаил Монашёв : > Зря. Там хранятся 32-битные числа. Зачем вдвое больше памяти лопатить? Александр просил! > Попробуй вернуть их обратно в 32 бита и избавить от знака. в яве нуте беззнаковых типов до 1.8, а у меня 1.7 сейчас в наличии From aml на rulezz.ru Mon Feb 9 09:32:45 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Mon, 09 Feb 2015 17:32:45 +0000 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> <1009399030.20150209165019@softsearch.ru> <117390181.20150209172540@softsearch.ru> <65553360.20150209202802@softsearch.ru> Message-ID: > > Померьте память плз > Гусары, молчать! ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From eugene.toropov на gmail.com Mon Feb 9 09:34:15 2015 From: eugene.toropov на gmail.com (Eugene Toropov) Date: Mon, 9 Feb 2015 20:34:15 +0300 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= In-Reply-To: References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> <1009399030.20150209165019@softsearch.ru> <117390181.20150209172540@softsearch.ru> <65553360.20150209202802@softsearch.ru> Message-ID: <20E412B3-811E-47F2-8479-4EDFF1F13CFD@gmail.com> On 09 Feb 2015, at 20:32, Alexander Lourier wrote: > Померьте память плз > > Гусары, молчать! > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org WTF? :) ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From onokonem на gmail.com Mon Feb 9 09:36:25 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Mon, 9 Feb 2015 21:36:25 +0400 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= In-Reply-To: References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> <1009399030.20150209165019@softsearch.ru> <117390181.20150209172540@softsearch.ru> <65553360.20150209202802@softsearch.ru> Message-ID: > Померьте память плз не знаю, как это корректно сделать. процесс занимает столько, сколько ему сказано в -Xms поджиматть ему -Xmx, пока падать не начнет? на тяжелых приложениях я на отчеты GC ориентируюсь, но тут никакого GC не будет From eugene.toropov на gmail.com Mon Feb 9 09:40:14 2015 From: eugene.toropov на gmail.com (Eugene Toropov) Date: Mon, 9 Feb 2015 20:40:14 +0300 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= In-Reply-To: References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> <1009399030.20150209165019@softsearch.ru> <117390181.20150209172540@softsearch.ru> <65553360.20150209202802@softsearch.ru> Message-ID: <8C83E59D-498F-4651-9CE7-806FB902B1AE@gmail.com> On 09 Feb 2015, at 20:36, Daniel Podolsky wrote: >> Померьте память плз > не знаю, как это корректно сделать. процесс занимает столько, сколько > ему сказано в -Xms > > поджиматть ему -Xmx, пока падать не начнет? > > на тяжелых приложениях я на отчеты GC ориентируюсь, но тут никакого GC не будет > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org Полагаю чем меньше ты ему скажешь - тем медленнее он должен быть по логике. Чем замерять не уверен. Может чем-то вроде https://collectd.org/ ? ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From postmaster на softsearch.ru Mon Feb 9 09:40:08 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Mon, 9 Feb 2015 20:40:08 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> <1009399030.20150209165019@softsearch.ru> <117390181.20150209172540@softsearch.ru> <65553360.20150209202802@softsearch.ru> Message-ID: <1344961285.20150209204008@softsearch.ru> Здравствуйте. Daniel, запусти, пожалуйста, Go вот с этим, оно тоже может 4ms выдать: без горутин: https://play.golang.org/p/ojQUVxQEaH c горутинами: https://play.golang.org/p/ptqnfBqLJk -- С уважением, Михаил mailto:postmaster на softsearch.ru From aml на rulezz.ru Mon Feb 9 09:41:45 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Mon, 09 Feb 2015 17:41:45 +0000 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> <1009399030.20150209165019@softsearch.ru> <117390181.20150209172540@softsearch.ru> <65553360.20150209202802@softsearch.ru> <20E412B3-811E-47F2-8479-4EDFF1F13CFD@gmail.com> Message-ID: > > On 09 Feb 2015, at 20:32, Alexander Lourier wrote: > > Померьте память плз >> > > Гусары, молчать! > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > > > WTF? :) > Ну когда народ уже не знает, чем ещё помериться, это не всегда хорошо заканчивается :) ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From postmaster на softsearch.ru Mon Feb 9 09:59:42 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Mon, 9 Feb 2015 20:59:42 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> <1009399030.20150209165019@softsearch.ru> <117390181.20150209172540@softsearch.ru> <65553360.20150209202802@softsearch.ru> Message-ID: <256414415.20150209205942@softsearch.ru> Здравствуйте, Eugene. > Померьте память плз Как её в венде можно измерить? Процесс быстро очень отрабатывает. Пока замерил просто вызывая много раз функцию расчёта суммы и глядя на диспетчер задач. Node.js http://pastebin.com/T1DVHNFM : 68Mb, использует 50% процессора, т.е. одно ядро из двух Go без горутин: https://play.golang.org/p/ojQUVxQEaH 40Mb, использует 50% процессора, т.е. одно ядро из двух Go c горутинами: https://play.golang.org/p/ptqnfBqLJk 42Mb показывает загрузку проца 99%, т.е. использует оба ядра -- С уважением, Михаил mailto:postmaster на softsearch.ru From me на ryvasy.net Mon Feb 9 10:04:13 2015 From: me на ryvasy.net (=?UTF-8?B?0JLQsNGB0LjQu9C40Lkg0KDRj9Cx0L7Qsg==?=) Date: Mon, 09 Feb 2015 21:04:13 +0300 Subject: [Moscow.pm] =?utf-8?b?0YDQsNCx0L7RgtGDINC90LjQutGC0L4g0L3QtSA=?= =?utf-8?b?0LjRidC10YI/?= Message-ID: <54D8F69D.9010805@ryvasy.net> Всем привет Мы, интернет-кинотеатр Zoomby.ru, ищем perl-разработчика. Кто заинтересован - присылайте резюме, пообщаемся. -- Василий Рябов, me на ryvasy.net From eugene.toropov на gmail.com Mon Feb 9 10:05:09 2015 From: eugene.toropov на gmail.com (Eugene Toropov) Date: Mon, 9 Feb 2015 21:05:09 +0300 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= In-Reply-To: References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> <1009399030.20150209165019@softsearch.ru> <117390181.20150209172540@softsearch.ru> <65553360.20150209202802@softsearch.ru> <20E412B3-811E-47F2-8479-4EDFF1F13CFD@gmail.com> Message-ID: On 09 Feb 2015, at 20:41, Alexander Lourier wrote: > On 09 Feb 2015, at 20:32, Alexander Lourier wrote: >> Померьте память плз >> >> Гусары, молчать! > >> -- >> Moscow.pm mailing list >> moscow-pm на pm.org | http://moscow.pm.org > > > WTF? :) > > Ну когда народ уже не знает, чем ещё помериться, это не всегда хорошо заканчивается :) > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org Экономия памяти столько раз упоминалась в этой теме, что забивать на ее замеры просто преступление :) ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From eugene.toropov на gmail.com Mon Feb 9 10:06:41 2015 From: eugene.toropov на gmail.com (Eugene Toropov) Date: Mon, 9 Feb 2015 21:06:41 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: <256414415.20150209205942@softsearch.ru> References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> <1009399030.20150209165019@softsearch.ru> <117390181.20150209172540@softsearch.ru> <65553360.20150209202802@softsearch.ru> <256414415.20150209205942@softsearch.ru> Message-ID: On 09 Feb 2015, at 20:59, Михаил Монашёв wrote: > Здравствуйте, Eugene. > >> Померьте память плз > > Как её в венде можно измерить? Процесс быстро очень отрабатывает. > > Пока замерил просто вызывая много раз функцию расчёта суммы и глядя на > диспетчер задач. > Node.js http://pastebin.com/T1DVHNFM : 68Mb, использует 50% процессора, т.е. одно ядро из двух > Go без горутин: https://play.golang.org/p/ojQUVxQEaH 40Mb, использует 50% процессора, т.е. одно ядро из двух > Go c горутинами: https://play.golang.org/p/ptqnfBqLJk 42Mb показывает загрузку проца 99%, т.е. использует оба ядра > > -- > С уважением, > Михаил mailto:postmaster на softsearch.ru > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org Я понятия не имею как :) надо погуглить From onokonem на gmail.com Mon Feb 9 10:12:19 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Mon, 9 Feb 2015 22:12:19 +0400 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= In-Reply-To: <256414415.20150209205942@softsearch.ru> References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> <1009399030.20150209165019@softsearch.ru> <117390181.20150209172540@softsearch.ru> <65553360.20150209202802@softsearch.ru> <256414415.20150209205942@softsearch.ru> Message-ID: > Как её в венде можно измерить? Процесс быстро очень отрабатывает. а я сунул sleep в конец :) vsz, rss, %mem go 145892932 16540 0,1 groovy 7090392 163696 1,0 java 7068528 99932 0,6 From onokonem на gmail.com Mon Feb 9 10:14:27 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Mon, 9 Feb 2015 22:14:27 +0400 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= In-Reply-To: <1344961285.20150209204008@softsearch.ru> References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> <1009399030.20150209165019@softsearch.ru> <117390181.20150209172540@softsearch.ru> <65553360.20150209202802@softsearch.ru> <1344961285.20150209204008@softsearch.ru> Message-ID: > без горутин: https://play.golang.org/p/ojQUVxQEaH The call took 9.055331ms to run. Sum is 49999995000000 > c горутинами: https://play.golang.org/p/ptqnfBqLJk The call took 3.393955ms to run. Sum is 49999995000000 From postmaster на softsearch.ru Mon Feb 9 10:37:17 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Mon, 9 Feb 2015 21:37:17 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> <1009399030.20150209165019@softsearch.ru> <117390181.20150209172540@softsearch.ru> <65553360.20150209202802@softsearch.ru> <256414415.20150209205942@softsearch.ru> Message-ID: <1276697561.20150209213717@softsearch.ru> Здравствуйте, Daniel. >> Как её в венде можно измерить? Процесс быстро очень отрабатывает. > а я сунул sleep в конец :) > vsz, rss, %mem > go 145892932 16540 0,1 > groovy 7090392 163696 1,0 > java 7068528 99932 0,6 Ты для go старый код наверное замерил. Попробуй то, для чего ты только что время замерял. Оно на 64 битах будет вдвое меньше памяти кушать. Вообще, даже 145Mb - это странно как-то. Должно быть чуть больше 80Mb. sleep в конце - это не совсем верно. Во время сна сборщики мусора могут всю память освободить. Ведь переменные, включая массив уже больше не нужны. Надо после sleep-а вставить что-то, что будет работать с массивом. -- С уважением, Михаил mailto:postmaster на softsearch.ru From foxcool333 на gmail.com Mon Feb 9 10:40:27 2015 From: foxcool333 на gmail.com (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCk0L7QutGB0LrRg9C7?=) Date: Mon, 9 Feb 2015 22:40:27 +0400 Subject: [Moscow.pm] =?utf-8?b?0YDQsNCx0L7RgtGDINC90LjQutGC0L4g0L3QtSA=?= =?utf-8?b?0LjRidC10YI/?= In-Reply-To: <54D8F69D.9010805@ryvasy.net> References: <54D8F69D.9010805@ryvasy.net> Message-ID: Удаленка? 09.02.2015 21:04 пользователь "Василий Рябов" написал: > Всем привет > > Мы, интернет-кинотеатр Zoomby.ru, ищем perl-разработчика. > > Кто заинтересован - присылайте резюме, пообщаемся. > -- > Василий Рябов, > me на ryvasy.net > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From postmaster на softsearch.ru Mon Feb 9 10:45:38 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Mon, 9 Feb 2015 21:45:38 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> <1009399030.20150209165019@softsearch.ru> <117390181.20150209172540@softsearch.ru> <65553360.20150209202802@softsearch.ru> <256414415.20150209205942@softsearch.ru> Message-ID: <131618058.20150209214538@softsearch.ru> Здравствуйте, Daniel. >> Как её в венде можно измерить? Процесс быстро очень отрабатывает. > а я сунул sleep в конец :) > vsz, rss, %mem > go 145892932 16540 0,1 > groovy 7090392 163696 1,0 > java 7068528 99932 0,6 А покажи ещё, пожалуйста, сколько процессора Java и Груви кушают. Хочется понять, они на одном ядре работают или на нескольких. -- С уважением, Михаил mailto:postmaster на softsearch.ru From postmaster на softsearch.ru Mon Feb 9 10:58:25 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Mon, 9 Feb 2015 21:58:25 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> <1009399030.20150209165019@softsearch.ru> <117390181.20150209172540@softsearch.ru> <65553360.20150209202802@softsearch.ru> <256414415.20150209205942@softsearch.ru> Message-ID: <755382607.20150209215825@softsearch.ru> Здравствуйте, Daniel. Надо бы как-то Ноду подтянуть. Что-то она совсем сильно отстала. Есть мысли? -- С уважением, Михаил mailto:postmaster на softsearch.ru From postmaster на softsearch.ru Mon Feb 9 11:10:19 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Mon, 9 Feb 2015 22:10:19 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> <1009399030.20150209165019@softsearch.ru> Message-ID: <1243981472.20150209221019@softsearch.ru> Здравствуйте, Alexander. Что-то вариант с горутинами течёт: https://play.golang.org/p/nvE_hf7mPw Не могу понять, где именно. -- С уважением, Михаил mailto:postmaster на softsearch.ru From postmaster на softsearch.ru Mon Feb 9 10:58:14 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Mon, 9 Feb 2015 21:58:14 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> <1009399030.20150209165019@softsearch.ru> <117390181.20150209172540@softsearch.ru> <65553360.20150209202802@softsearch.ru> Message-ID: <587103361.20150209215814@softsearch.ru> Здравствуйте, Eugene. > Померьте память плз Замерил точно так же в 64-битной венде: Node.js http://pastebin.com/T1DVHNFM : 86Mb, использует 50% процессора, т.е. одно ядро из двух Go без горутин: https://play.golang.org/p/ojQUVxQEaH 40Mb, использует 50% процессора, т.е. одно ядро из двух Go c горутинами: https://play.golang.org/p/ptqnfBqLJk 42Mb показывает загрузку проца 99%, т.е. использует оба ядра Т.е. у ноды потребление памяти выросло, а у go осталось прежним. Правда заметил, что у варианта с горутинами память постепенно растёт. Разберусь попозже с этим... -- С уважением, Михаил mailto:postmaster на softsearch.ru -- Moscow.pm mailing list moscow-pm на pm.org | http://moscow.pm.org From aml на rulezz.ru Mon Feb 9 11:29:46 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Mon, 09 Feb 2015 19:29:46 +0000 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> <1009399030.20150209165019@softsearch.ru> <1243981472.20150209221019@softsearch.ru> Message-ID: > > Что-то вариант с горутинами течёт: https://play.golang.org/p/nvE_hf7mPw > Не могу понять, где именно. > Я думаю, что это просто GC не включился и не почистил память. Для того, чтобы проверить эту гипотезу, можешь вызвать runtime.GC(). ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From postmaster на softsearch.ru Mon Feb 9 11:56:03 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Mon, 9 Feb 2015 22:56:03 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> <1009399030.20150209165019@softsearch.ru> <1243981472.20150209221019@softsearch.ru> Message-ID: <1763475480.20150209225603@softsearch.ru> Здравствуйте, Alexander. >> Что-то вариант с горутинами течёт: https://play.golang.org/p/nvE_hf7mPw >> Не могу понять, где именно. > > Я думаю, что это просто GC не включился и не почистил память. > Для того, чтобы проверить эту гипотезу, можешь вызвать runtime.GC(). Ты оказался прав. -- С уважением, Михаил mailto:postmaster на softsearch.ru From onokonem на gmail.com Mon Feb 9 12:45:16 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Tue, 10 Feb 2015 00:45:16 +0400 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= In-Reply-To: <1763475480.20150209225603@softsearch.ru> References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> <1009399030.20150209165019@softsearch.ru> <1243981472.20150209221019@softsearch.ru> <1763475480.20150209225603@softsearch.ru> Message-ID: я тут подумал, и гоняю не один раз этот расчет, а 10 тысяч. исходники, если нужны, готов предоставить. получил вот такие результаты: COMMAND %CPU #TH MEM avg time go 100.5 2/1 122M 7ms go-rt 160.6 15/1 123M 2ms java 109.6 20/1 3008M 4ms groovy 112.2 20/1 1837M 5ms чет эта развлекуха мне поднадоела :) да и очевидно уже, какие шишки в лесу чьи. наблюдал ленивые вычисления в действии - забыл добавить печать суммы в диагностику. время на java тут же упало до нуля. скажите, коллеги, то, что никто из нас даже не подумал потестить перл - это из уважения к сообществу? From vividsnow на gmail.com Mon Feb 9 13:00:46 2015 From: vividsnow на gmail.com (vividsnow) Date: Tue, 10 Feb 2015 00:00:46 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> <1009399030.20150209165019@softsearch.ru> <1243981472.20150209221019@softsearch.ru> <1763475480.20150209225603@softsearch.ru> Message-ID: <54D91FFE.6040004@gmail.com> perl+pdl: ~$ /usr/bin/time -f 'mem: %MKb' perl -MPDL::LiteF -MBenchmark=countit -e ' my $s = sequence long, 1e7; printf "time: %dms sum: %d\n", 1e3/countit(1, sub { $s->dsum })->iters, $s->dsum' time: 19ms sum: 49999995000000 mem: 48516Kb p.s. intel core2duo t7400 On 02/09/2015 11:45 PM, Daniel Podolsky wrote: > я тут подумал, и гоняю не один раз этот расчет, а 10 тысяч. исходники, > если нужны, готов предоставить. > > получил вот такие результаты: > COMMAND %CPU #TH MEM avg time > go 100.5 2/1 122M 7ms > go-rt 160.6 15/1 123M 2ms > java 109.6 20/1 3008M 4ms > groovy 112.2 20/1 1837M 5ms > > чет эта развлекуха мне поднадоела :) да и очевидно уже, какие шишки в лесу чьи. > > наблюдал ленивые вычисления в действии - забыл добавить печать суммы в > диагностику. время на java тут же упало до нуля. > > скажите, коллеги, то, что никто из нас даже не подумал потестить перл > - это из уважения к сообществу? > From v.perepelitsa на corp.mail.ru Mon Feb 9 17:20:16 2015 From: v.perepelitsa на corp.mail.ru (Mons Anderson) Date: Tue, 10 Feb 2015 04:20:16 +0300 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: <3162725.PxWo5lW6aH@rawen> References: <2568912.XdEKZjtt8b@rawen> <2036D7A8-A6BA-47AC-9F87-F67D1C0C2D34@corp.mail.ru> <3162725.PxWo5lW6aH@rawen> Message-ID: <3AD23D67-BE52-45DA-AE89-BF96325EB1B6@corp.mail.ru> > On 9 февр. 2015 г., at 17:40, PEF Secure wrote: > > On Monday, February 09, 2015 12:11:23 Mons Anderson wrote: >> Вы не путаете-ли с Coro? > > Не совсем. Дело в том, что AE невозможно поставить без Coro, кондвар-ы > работать без него не смогут. Да ладно! В сорцы пробовали заглядывать, что такое AE::cv? https://metacpan.org/source/MLEHMANN/AnyEvent-7.08/lib/AnyEvent.pm#L1940 > >> Никто не за кого не думал и никакие потоки там не усыпляются, т.к. их нет. > > К словам цепляться будем? Мне не в падлу и перестать тут общаться. > -- > PEF Developer > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org -- Mons Anderson ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From v.perepelitsa на corp.mail.ru Mon Feb 9 17:23:57 2015 From: v.perepelitsa на corp.mail.ru (Mons Anderson) Date: Tue, 10 Feb 2015 04:23:57 +0300 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: <1966072.6nRWdhgONy@rawen> References: <3162725.PxWo5lW6aH@rawen> <0BD44B60-1D5A-4A01-AFE0-44F9D9860B35@gmail.com> <1966072.6nRWdhgONy@rawen> Message-ID: <73D11BE2-4164-48A6-A28B-6DE02B7F521F@corp.mail.ru> > On 9 февр. 2015 г., at 18:15, PEF Secure wrote: > > On Monday, February 09, 2015 17:45:30 Eugene Toropov wrote: >>> On Feb 9, 2015, at 5:40 PM, PEF Secure wrote: >>> >>> On Monday, February 09, 2015 12:11:23 Mons Anderson wrote: >>>> Вы не путаете-ли с Coro? >>> >>> Не совсем. Дело в том, что AE невозможно поставить без Coro, кондвар-ы >>> работать без него не смогут. >> >> Чувак, ты реально напутал. Попробуй поставить AE - никакой Коро там нафиг не >> нужен. И потоков там нет никаких - мы поэтому и уходили в свое время на >> Коро с AE >> >> Евгений > > AE/Coro должны работать вместе. Могут != Должны Я пишу на чистом AE/EV. К коро иногда пишу врапперы, иногда нет. В продакшне у меня коро нигде нет. Коро - абстракция, сбрасывающая около 20-30% производительности по сравнению с AE и вносящая ограничения на стеке каждой коры. > > -- > PEF Developer > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org -- Mons Anderson ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From v.perepelitsa на corp.mail.ru Mon Feb 9 17:34:42 2015 From: v.perepelitsa на corp.mail.ru (Mons Anderson) Date: Tue, 10 Feb 2015 04:34:42 +0300 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= In-Reply-To: <19510226719.20150209161121@softsearch.ru> References: <19510226719.20150209161121@softsearch.ru> Message-ID: Пожалуй в данном вопросе стоит начать с того, что CPU-арифметика никак не сильный конёк перла. (Кстати, удивлён, что никто не затестил CUDA) Во вторых - CPU-intensive задачи выгоднее решать именно в синхронной модели. Асинхрон рулит только тогда, когда переключение контекста планировщиком OS становится дороже, чем ?ручное" управление контекстами при помощи event-машины. Ну и в третьих, хотелось бы спросить: какое отношение данная задача имеет к реальной жизни? -- Mons Anderson > On 9 февр. 2015 г., at 16:11, Михаил Монашёв wrote: > > Здравствуйте, Mons. > >> Народ, я не осилил дочитать это всё до конца. >> А давайте-ка соберёмся и померяемся. >> Не в плане теории, а в плане конкретных чисел >> сравним разные языки, подходы и т.п. > > А собираться обязательно? Можно ведь и удалённо. Я на Go пишу всего > месяц и мне было бы сложно придти и что-то нормально на нём написать > за малое время. Но сравнить языки было бы интересно. > > Предложу простую задачку, которая покажет, насколько хорошо язык > работает с памятью: сложить все значения массива, состоящего из > 10000000 целых чисел. Код там простой: создаём массив, заполняем его, > замеряем время, потом в цикле складываем элементы массива, снова > замеряем время и выдаём результат. Вот мой вариант на Go: > https://play.golang.org/p/iHGG3nV10L > > Тонкости: в песочнице код съедает много процессора и время там всегда > одно и то же, поэтому его надо сохранить в файл, например main.go и > потом запустить вот так: go run main.go > Скомпилировать в исполняемый файл можно вот так: go build main.go > А вот так выйдет более быстрая версия: go build -gcflags="-B" main.go > Скачать Go можно вот тут: http://golang.org/ > > -- > С уважением, > Михаил mailto:postmaster на softsearch.ru > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From alexclear на gmail.com Mon Feb 9 18:13:35 2015 From: alexclear на gmail.com (Alex Chistyakov) Date: Tue, 10 Feb 2015 06:13:35 +0400 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: <236366112.20150208185126@softsearch.ru> References: <19923524.20150208131028@softsearch.ru> <236366112.20150208185126@softsearch.ru> Message-ID: 2015-02-08 18:51 GMT+03:00 Михаил Монашёв : > Здравствуйте, Ксения. > >> Что в вашем понимании "сложное"? Мы писали небольшой прокси на >> AnyEvent, несколько сотен строк кода. > > У меня лично хорошо писалось на Node.js пока всё помещалось в моей > голове. Потом я забросил код и через год было очень сложно разобраться > и продолжить его писать. Даже удивился, неужели я написал всю эту > чушь. :-) Пока проект маленький и простой, всё очевидно нет проблем с > его развитием. А как он вырастает, то требуется или очень хороший > архитектор, который заранее правильно распишет все модули их > функционал и прочее или легко завязнуть, когда развитие станет > оооочень медленным. > >> Что касается альтернатив колбэкам, хотелось бы услышать поподробнее, >> что вы имеете в виду. В нашем случае я не видела каких-то >> альтернатив. > > Go с его дешёвыми горутинами и каналами. Код выходит более линейный, а > потому более привычный для обычного программиста. Соглашусь с > Александром Лурье, что язык стоит выбирать под задачу. Какой больше > подходит, на том и писать. Только > > Вот что Вам дают колбэки кроме иллюзии параллельности. Латентность > понижать можно и без них. К слову - вот уж латентность-то колбэки не понижают вообще никогда. Наоборот, 90%-й персентиль вытянется. И это ведь логично. -- SY, Alex > > P.S. > Читаю и лист и удивляюсь как многие тут зациклились на перле. Это > древний язык, хотя и не умирающий пока. Но многое изменилось в мире и > он уже не поспевает за изменениями. Это сразу бросается в глаза, когда > пробуешь новые языки. > > -- > С уважением, > Михаил mailto:postmaster на softsearch.ru > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org From alexclear на gmail.com Mon Feb 9 18:18:01 2015 From: alexclear на gmail.com (Alex Chistyakov) Date: Tue, 10 Feb 2015 06:18:01 +0400 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: References: <19923524.20150208131028@softsearch.ru> <1448301.L8bfyLT0Ar@rawen> Message-ID: 2015-02-08 20:41 GMT+03:00 Ксения Боброва : > О том и речь, что в перле особо альтернатив нет)) Была бы джава, можно было > бы не заморачиваться. > > А что касается "используйте подходящую под задачу языки" - полностью > согласна, конечно, но только сначала надо найти проект, где вам разрешат Если бизнес не понимает язык метрик, стоит ли работать на такой бизнес? > использовать зоопарк инструментов на ваше усмотрение. Есть еще такое понятие > как "исторически сложилось" и "у нас все знают хорошо только перл". Как выясняется, Perl у них тоже знают не хорошо. Просто люди верят в то, во что легко и удобно верить, а неприятную правду предпочитают обходить. > Обычно > добавление в проект не то что нового языка, но новых либ, может быть > расценено как "разработчики опять хотят развлекаться вместо работы". Да, а еще "у наших сисадминов нет регламента по поддержке таких технологий". Поэтому выкатываются с CVS монолитным бинарем - "здесь так заведено". -- SY, Alex > > 8 февраля 2015 г., 18:36 пользователь PEF Secure > написал: > >> On Sunday, February 08, 2015 12:06:55 Ксения Боброва wrote: >> > Что в вашем понимании "сложное"? Мы писали небольшой прокси на AnyEvent, >> > несколько сотен строк кода. >> > Что касается альтернатив колбэкам, хотелось бы услышать поподробнее, что >> > вы >> > имеете в виду. В нашем случае я не видела каких-то альтернатив. >> > Квалификация, разумеется, требуется. Но почему это должно стать >> > препятствием? >> >> Альтернатива коллбекам была бы треды, если б в Perl они были нормальные и >> вообще рабочие. В этом плане, надежда только на Perl6. >> >> -- >> PEF Developer >> -- >> Moscow.pm mailing list >> moscow-pm на pm.org | http://moscow.pm.org > > > > > -- > Ksenia Bobrova > Senior Perl Developer > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > From alexclear на gmail.com Mon Feb 9 18:21:22 2015 From: alexclear на gmail.com (Alex Chistyakov) Date: Tue, 10 Feb 2015 06:21:22 +0400 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: References: <3554242.MnZySGtjuc@rawen> Message-ID: 2015-02-08 20:57 GMT+03:00 Alexander Lourier : > Так мир же недетерминированный. Ну да, поэтому 40% россиян хотят жить в Москве. Опять же - зайдешь в рассылку тред почитать и начинаешь лапшу с ушей снимать ведрами - в одном обсуждении и колбэки понижают латентность, и треды не работают (в Perl - а в Java работают, ну надо же?), и мир еще недетерминирован. Как страшно жить. -- SY, Alex > Пакеты по сети приходят, когда хотят. Иначе > будет: "У нас тут детерминированный код, и пусть весь мир подождёт". > > On Sun Feb 08 2015 at 18:49:48 Andrey Kovbovich > wrote: >> >> А я бы послушал доклад на тему "как перестать писать асинхронный >> недетерминированный код и начать жить". >> >> воскресенье, 8 февраля 2015 г. пользователь Александр Фокскул написал: >>> >>> Тред в рассылке той же был бы более полезным. >>> >>> 08.02.2015 20:40 пользователь "Daniel Podolsky" >>> написал: >>>> >>>> > Не понимаю. Исходные коды AnyEvent/Coro лежат на CPAN, смотреть >>>> > внутренности >>>> > можно лично, без пересказов. >>>> Есть люди, которые успешно пользуются AnyEvent/Coro/etc >>>> >>>> есть другие люди, которые думают, что это круто - успешно пользоваться >>>> AnyEvent/Coro/etc, и хотят научиться. и думают, что этому их могут >>>> научить те, первые люди. >>>> >>>> а есть третьи люди, вроде меня, которые об AnyEvent постучались лбом, >>>> и думают, что это круто, но пользоваться этим не надо. >>>> >>>> правда, хотите доклад на тему "перл - гоязык >>>> ограниченной применимости"? >>>> >>>> я прочту, хоть в питере, хоть в москве :) >>>> -- >>>> Moscow.pm mailing list >>>> moscow-pm на pm.org | http://moscow.pm.org >> >> -- >> Moscow.pm mailing list >> moscow-pm на pm.org | http://moscow.pm.org > > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > From v.perepelitsa на corp.mail.ru Mon Feb 9 18:22:20 2015 From: v.perepelitsa на corp.mail.ru (Mons Anderson) Date: Tue, 10 Feb 2015 05:22:20 +0300 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= In-Reply-To: <19510226719.20150209161121@softsearch.ru> References: <19510226719.20150209161121@softsearch.ru> Message-ID: int main (int argc,char **argv) { long int S = atoi(argv[1]); long int i,z; clock_t start = clock(); long int sum = 0; for(z = 0; z < 1000; z++ ){ sum = 0; for (i=0;i < S - S % 16; i+=16) { sum += i + i+1 + i+2 + i+3 + i+4 + i+5 + i+6 + i+7 + i+8 + i+9 + i+10 + i+11 + i+12 + i+13 + i+14 + i+15 ; } for (i; i < S; i++ ) { sum += i; } } clock_t end = clock(); printf("%lu (%0.8f)\n",sum,((double)end-start)/1e6/z); } 1.5 ms gcc --std=c99 -O3 -march=native -- Mons Anderson > On 9 февр. 2015 г., at 16:11, Михаил Монашёв wrote: > > Здравствуйте, Mons. > >> Народ, я не осилил дочитать это всё до конца. >> А давайте-ка соберёмся и померяемся. >> Не в плане теории, а в плане конкретных чисел >> сравним разные языки, подходы и т.п. > > А собираться обязательно? Можно ведь и удалённо. Я на Go пишу всего > месяц и мне было бы сложно придти и что-то нормально на нём написать > за малое время. Но сравнить языки было бы интересно. > > Предложу простую задачку, которая покажет, насколько хорошо язык > работает с памятью: сложить все значения массива, состоящего из > 10000000 целых чисел. Код там простой: создаём массив, заполняем его, > замеряем время, потом в цикле складываем элементы массива, снова > замеряем время и выдаём результат. Вот мой вариант на Go: > https://play.golang.org/p/iHGG3nV10L > > Тонкости: в песочнице код съедает много процессора и время там всегда > одно и то же, поэтому его надо сохранить в файл, например main.go и > потом запустить вот так: go run main.go > Скомпилировать в исполняемый файл можно вот так: go build main.go > А вот так выйдет более быстрая версия: go build -gcflags="-B" main.go > Скачать Go можно вот тут: http://golang.org/ > > -- > С уважением, > Михаил mailto:postmaster на softsearch.ru > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From alexclear на gmail.com Mon Feb 9 18:23:10 2015 From: alexclear на gmail.com (Alex Chistyakov) Date: Tue, 10 Feb 2015 06:23:10 +0400 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: <8854513.V95ACoDWLW@rawen> References: <8854513.V95ACoDWLW@rawen> Message-ID: 2015-02-08 21:00 GMT+03:00 PEF Secure : > On Sunday, February 08, 2015 21:49:36 Andrey Kovbovich wrote: >> А я бы послушал доклад на тему "как перестать писать асинхронный >> недетерминированный код и начать жить". > > Перейдите на яву. До версии 1.4 там даже неблокирующихся сокетов не было. "Даже"? Версия 1.4 - это 2002 год, если что. -- SY, Alex > -- > PEF Developer > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org From alexclear на gmail.com Mon Feb 9 18:27:45 2015 From: alexclear на gmail.com (Alex Chistyakov) Date: Tue, 10 Feb 2015 06:27:45 +0400 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: <54D87696.6090201@rambler.ru> References: <19923524.20150208131028@softsearch.ru> <1448301.L8bfyLT0Ar@rawen> <54D8657A.2050202@rambler.ru> <54D87696.6090201@rambler.ru> Message-ID: 2015-02-09 11:57 GMT+03:00 Анатолий Гришаев <0body0 на rambler.ru>: > 09.02.2015 11:01, Daniel Podolsky пишет: > >>> 1) было исследование программ на C, которое показывало, асинхронный код >>> не >>> проигрывает тредовому, и довольно >>> часто при большой нагрузке оказывается быстрее. ( Кажется это была >>> толстая >>> зеленая книга) >>> 2) За исключением патологических случаем fork по скорости сравним с >>> threads. >>> 3) Писать и отлаживать на AnyEvent + fork намного проще, чем на threads. >>> >>> Т.е. threads --- это технологический тупик. >>> И если он есть это наверно хорошо, но лучше им не пользоваться. >>> Выгоды от него ограниченные, а гемороя можно получить в разы больше. >> >> А приведите, пожалуйста, хотя бы по паре аргументов в поддержку этих >> тезисов :) > > > 1) Создание потоков и процессом в Линуксе делается одним вызовом (clone) > разница только в копировании адресного пространства при создании процесса, > а внутри они ничем не различаются, кроме адресного пространства. > Если процесс поток/процесс живет довольно долго, то разницу в накладных > расходов при создании процесса можно пренебречь > 2) При большом количестве потоков у ядра вырастают накладные расходы на > переключение потоков. > В случае большой нагрузки вообще говоря количество потоков > вырастает(threads), а в случае асинхронной программы это количесто не > меняется, поэтому > асинхронная модель будет выигрывать за счет накладных расходов ядра системы. > 3) Асинхронная программа это однопоточная программа. А поскольку отлаживать > однопоточную программу проще чем многопоточную, то > и отлаживать асинхронную программу легче, чем программу с потоками. Это утверждение вопиюще неверно. > 4) В асинхронной программе не нужны средства синхронизации потоков(Из-за > многопоточности), которые просто необходимы в потоках. > Накладные расходы на синхронизацию не ускоряют поточные программы и иногда > могут быть просто чудовищными. Все мы работаем с базами данных, каман. Ну - те из нас, кто работает. Так вот, те, кто работают с базами данных, знают слова вроде "оптимистичная блокировка", "MVCC". Есть еще такая вещь, как STM. > 100-200 циклов процессора минимум на одном примитиве. compare-and-swap это 100-200 циклов процессора минимум? Но на что? O_O -- SY, Alex > > Слегка не в тему, но для полноты > 5) forkи проще концептуально и приводят к меньшему количеству ошибок в > программировании, значит отлаживать будет меньше. > > > > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org From v.perepelitsa на corp.mail.ru Mon Feb 9 18:40:10 2015 From: v.perepelitsa на corp.mail.ru (Mons Anderson) Date: Tue, 10 Feb 2015 05:40:10 +0300 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: References: <19923524.20150208131028@softsearch.ru> <1448301.L8bfyLT0Ar@rawen> <54D8657A.2050202@rambler.ru> <54D87696.6090201@rambler.ru> Message-ID: <7BC4A39C-1A06-48CF-B50F-673BDFD0C779@corp.mail.ru> > On 10 февр. 2015 г., at 5:27, Alex Chistyakov wrote: > > compare-and-swap это 100-200 циклов процессора минимум? > Но на что? O_O Э-э-э, товарищ, lockfree попахивает ;) -- Mons Anderson ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From alexclear на gmail.com Mon Feb 9 18:45:59 2015 From: alexclear на gmail.com (Alex Chistyakov) Date: Tue, 10 Feb 2015 06:45:59 +0400 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: <7BC4A39C-1A06-48CF-B50F-673BDFD0C779@corp.mail.ru> References: <19923524.20150208131028@softsearch.ru> <1448301.L8bfyLT0Ar@rawen> <54D8657A.2050202@rambler.ru> <54D87696.6090201@rambler.ru> <7BC4A39C-1A06-48CF-B50F-673BDFD0C779@corp.mail.ru> Message-ID: 2015-02-10 5:40 GMT+03:00 Mons Anderson : > > On 10 февр. 2015 г., at 5:27, Alex Chistyakov wrote: > > compare-and-swap это 100-200 циклов процессора минимум? > Но на что? O_O > > > Э-э-э, товарищ, lockfree попахивает ;) А никто не обещал, что будет легко! > > -- > Mons Anderson > > > > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > From postmaster на softsearch.ru Mon Feb 9 21:35:38 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 10 Feb 2015 08:35:38 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: References: <19510226719.20150209161121@softsearch.ru> Message-ID: <303343247.20150210083538@softsearch.ru> Здравствуйте, Mons. Этот код не обходит 10000000 элементов массива. > int main (int argc,char **argv) { > ═ ═ ═ ═ longint S = atoi(argv[1]); > ═ ═ ═ ═ longint i,z; > ═ ═ ═ ═ clock_t start = clock(); > ═ ═ ═ ═ longint sum = 0; > ═ ═ ═ ═ for(z = 0; z < 1000; z++ ){ > ═ ═ ═ ═ ═ ═ ═ ═ sum = 0; > ═ ═ ═ ═ ═ ═ ═ ═ for (i=0;i < S - S % 16; i+=16) { > ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ sum += i ═ + i+1 + i+2═ + i+3═ + i+4═ + i+5═ + i+6═ + i+7 > ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ══+═ i+8 + i+9 + i+10 + i+11 + i+12 + i+13 + i+14 + i+15 > ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ; > ═ ═ ═ ═ ═ ═ ═ ═ } > ═ ═ ═ ═ ═ ═ ═ ═ for (i; i < S; i++ ) { > ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ sum += i; > ═ ═ ═ ═ ═ ═ ═ ═ } > ═ ═ ═ ═ } > ═ ═ ═ ═ clock_t end = clock(); > ═ ═ ═ ═ printf("%lu (%0.8f)\n",sum,((double)end-start)/1e6/z); > } > > 1.5 ms > > gcc --std=c99 -O3 -march=native попытался написать на C unsigned int arr[10000000]; но это приводит к падению программы, видимо надо выделять память динамически. Но не помню как? -- С уважением, Михаил mailto:postmaster на softsearch.ru From postmaster на softsearch.ru Mon Feb 9 22:28:47 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 10 Feb 2015 09:28:47 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: References: <19510226719.20150209161121@softsearch.ru> Message-ID: <1825727633.20150210092847@softsearch.ru> Здравствуйте, Mons. Вот код, который соответствует исходной задаче. #include #include int main() { unsigned __int32 *arr; arr = (unsigned __int32 *) malloc(10000000 * sizeof(unsigned __int32)); int i; for( i=10000000-1; i>=0; i--) { arr[i] = i; } clock_t start = clock(); unsigned __int64 sum; sum = 0; for( i=10000000-1; i>=0; i--) { sum+=arr[i]; } clock_t end = clock(); printf("Time:(%0.8f)ms . Sum: %llu", ((double)end-start)/CLOCKS_PER_SEC*1000, sum); return 0; } C:\Temp>gcc -O3 -march=native 3.c -o 3.exe 3.c: In function 'main': 3.c:8:30: warning: incompatible implicit declaration of built-in function 'malloc' [enabled by default] arr = (unsigned __int32 *) malloc(10000000 * sizeof(unsigned __int32)); ^ C:\Temp>3.exe Time:(11.00000000)ms . Sum: 49999995000000 Это время в 32-битной венде. Как победить этот варнинг при компиляции я не разбирался пока. > int main (int argc,char **argv) { > ═ ═ ═ ═ longint S = atoi(argv[1]); > ═ ═ ═ ═ longint i,z; > ═ ═ ═ ═ clock_t start = clock(); > ═ ═ ═ ═ longint sum = 0; > ═ ═ ═ ═ for(z = 0; z < 1000; z++ ){ > ═ ═ ═ ═ ═ ═ ═ ═ sum = 0; > ═ ═ ═ ═ ═ ═ ═ ═ for (i=0;i < S - S % 16; i+=16) { > ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ sum += i ═ + i+1 + i+2═ + i+3═ + i+4═ + i+5═ + i+6═ + i+7 > ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ══+═ i+8 + i+9 + i+10 + i+11 + i+12 + i+13 + i+14 + i+15 > ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ; > ═ ═ ═ ═ ═ ═ ═ ═ } > ═ ═ ═ ═ ═ ═ ═ ═ for (i; i < S; i++ ) { > ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ sum += i; > ═ ═ ═ ═ ═ ═ ═ ═ } > ═ ═ ═ ═ } > ═ ═ ═ ═ clock_t end = clock(); > ═ ═ ═ ═ printf("%lu (%0.8f)\n",sum,((double)end-start)/1e6/z); > } > 1.5 ms > gcc --std=c99 -O3 -march=native > --═ > Mons Anderson > > On 9 февр. 2015 г., at 16:11, Михаил Монашёв > wrote: > Здравствуйте, Mons. > Народ, я не осилил дочитать это всё до конца. > А давайте-ка соберёмся и померяемся. > Не в плане теории, а в плане конкретных чисел > сравним разные языки, подходы и т.п. > А ═собираться ═обязательно? ═Можно ведь и удалённо. Я на Go пишу всего > месяц ═и ═мне было бы сложно придти и что-то нормально на нём написать > за малое время. Но сравнить языки было бы интересно. > Предложу ═простую ═задачку, ═которая ═покажет, ═насколько ═хорошо язык > работает ═с ═памятью: ═сложить ═все ═значения ═массива, ═состоящего из > 10000000 ═целых чисел. Код там простой: создаём массив, заполняем его, > замеряем ═время, ═потом ═в ═цикле ═складываем ═элементы массива, снова > замеряем время и выдаём результат. Вот мой вариант на Go: > https://play.golang.org/p/iHGG3nV10L > Тонкости: ═в песочнице код съедает много процессора и время там всегда > одно ═и ═то ═же, поэтому его надо сохранить в файл, например main.go и > потом запустить вот так: go run main.go > Скомпилировать ═в исполняемый файл можно вот так: go build main.go > А вот так выйдет более быстрая версия: go build -gcflags="-B" main.go > Скачать Go можно вот тут: http://golang.org/ > -- > С уважением, > Михаил ═════════════════════════mailto:postmaster на softsearch.ru -- С уважением, Михаил mailto:postmaster на softsearch.ru From 0body0 на rambler.ru Mon Feb 9 22:35:23 2015 From: 0body0 на rambler.ru (=?KOI8-R?Q?=E1=CE=C1=D4=CF=CC=C9=CA_=E7=D2=C9=DB=C1=C5=D7?=) Date: Tue, 10 Feb 2015 09:35:23 +0300 Subject: [Moscow.pm] =?koi8-r?b?9MXN2SDEzNEgxM/LzMHEz9c=?= In-Reply-To: References: <19923524.20150208131028@softsearch.ru> <1448301.L8bfyLT0Ar@rawen> <54D8657A.2050202@rambler.ru> <54D87696.6090201@rambler.ru> Message-ID: <54D9A6AB.5080902@rambler.ru> 10.02.2015 5:27, Alex Chistyakov пишет: > 2015-02-09 11:57 GMT+03:00 Анатолий Гришаев <0body0 на rambler.ru>: >> 09.02.2015 11:01, Daniel Podolsky пишет: >> >>>> 1) было исследование программ на C, которое показывало, асинхронный код >>>> не >>>> проигрывает тредовому, и довольно >>>> часто при большой нагрузке оказывается быстрее. ( Кажется это была >>>> толстая >>>> зеленая книга) >>>> 2) За исключением патологических случаем fork по скорости сравним с >>>> threads. >>>> 3) Писать и отлаживать на AnyEvent + fork намного проще, чем на threads. >>>> >>>> Т.е. threads --- это технологический тупик. >>>> И если он есть это наверно хорошо, но лучше им не пользоваться. >>>> Выгоды от него ограниченные, а гемороя можно получить в разы больше. >>> А приведите, пожалуйста, хотя бы по паре аргументов в поддержку этих >>> тезисов :) >> >> 1) Создание потоков и процессом в Линуксе делается одним вызовом (clone) >> разница только в копировании адресного пространства при создании процесса, >> а внутри они ничем не различаются, кроме адресного пространства. >> Если процесс поток/процесс живет довольно долго, то разницу в накладных >> расходов при создании процесса можно пренебречь >> 2) При большом количестве потоков у ядра вырастают накладные расходы на >> переключение потоков. >> В случае большой нагрузки вообще говоря количество потоков >> вырастает(threads), а в случае асинхронной программы это количесто не >> меняется, поэтому >> асинхронная модель будет выигрывать за счет накладных расходов ядра системы. >> 3) Асинхронная программа это однопоточная программа. А поскольку отлаживать >> однопоточную программу проще чем многопоточную, то >> и отлаживать асинхронную программу легче, чем программу с потоками. > Это утверждение вопиюще неверно. Ага так и поверил, где аргументы? И что собственно неверно? > >> 4) В асинхронной программе не нужны средства синхронизации потоков(Из-за >> многопоточности), которые просто необходимы в потоках. >> Накладные расходы на синхронизацию не ускоряют поточные программы и иногда >> могут быть просто чудовищными. > Все мы работаем с базами данных, каман. > Ну - те из нас, кто работает. Во первых не все, и не всегда. Можно пользоваться redis и memcached и не думать о базах данных. А иногда бывает полезно иметь общий пул данных > Так вот, те, кто работают с базами данных, знают слова вроде > "оптимистичная блокировка", "MVCC". > Есть еще такая вещь, как STM. Опять не все, и не всегда. Даже если блокировка самая быстрая, это не значит что на неё не используются ресурсы процессора вообще. А поход в базу данных это совсем не дешевая альтернатива. > >> 100-200 циклов процессора минимум на одном примитиве. > compare-and-swap это 100-200 циклов процессора минимум? > Но на что? O_O А вы читали Intel Design Manual для IE-32 и IE-64? А про POSIX ? А про примитивы синхронизации, как они устроены? А про spin lock, что вам известно? Почитайте, погуглите. Может оказаться, что на CAS 100-200 циклов и уходит. А одной блокировкой как правило, дело обычно не заканчивается. > > -- > SY, > Alex > > >> Слегка не в тему, но для полноты >> 5) forkи проще концептуально и приводят к меньшему количеству ошибок в >> программировании, значит отлаживать будет меньше. >> >> >> >> >> -- >> Moscow.pm mailing list >> moscow-pm на pm.org | http://moscow.pm.org From 0body0 на rambler.ru Mon Feb 9 22:40:56 2015 From: 0body0 на rambler.ru (=?KOI8-R?Q?=E1=CE=C1=D4=CF=CC=C9=CA_=E7=D2=C9=DB=C1=C5=D7?=) Date: Tue, 10 Feb 2015 09:40:56 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: <1825727633.20150210092847@softsearch.ru> References: <19510226719.20150209161121@softsearch.ru> <1825727633.20150210092847@softsearch.ru> Message-ID: <54D9A7F8.40608@rambler.ru> 10.02.2015 9:28, Михаил Монашёв пишет: > > C:\Temp>3.exe > Time:(11.00000000)ms . Sum: 49999995000000 > > Это время в 32-битной венде. > > Как победить этот варнинг при компиляции я не разбирался пока. > добавь #include >> int main (int argc,char **argv) { >> ═ ═ ═ ═ longint S = atoi(argv[1]); >> ═ ═ ═ ═ longint i,z; >> ═ ═ ═ ═ clock_t start = clock(); >> ═ ═ ═ ═ longint sum = 0; >> ═ ═ ═ ═ for(z = 0; z < 1000; z++ ){ >> ═ ═ ═ ═ ═ ═ ═ ═ sum = 0; >> ═ ═ ═ ═ ═ ═ ═ ═ for (i=0;i < S - S % 16; i+=16) { >> ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ sum += i ═ + i+1 + i+2═ + i+3═ + i+4═ + i+5═ + i+6═ + i+7 >> ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ══+═ i+8 + i+9 + i+10 + i+11 + i+12 + i+13 + i+14 + i+15 >> ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ; >> ═ ═ ═ ═ ═ ═ ═ ═ } >> ═ ═ ═ ═ ═ ═ ═ ═ for (i; i < S; i++ ) { >> ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ sum += i; >> ═ ═ ═ ═ ═ ═ ═ ═ } >> ═ ═ ═ ═ } >> ═ ═ ═ ═ clock_t end = clock(); >> ═ ═ ═ ═ printf("%lu (%0.8f)\n",sum,((double)end-start)/1e6/z); >> } > > > > >> 1.5 ms > >> gcc --std=c99 -O3 -march=native > > > >> --═ >> Mons Anderson >> > > > > >> On 9 февр. 2015 г., at 16:11, Михаил Монашёв >> wrote: >> Здравствуйте, Mons. >> Народ, я не осилил дочитать это всё до конца. >> А давайте-ка соберёмся и померяемся. >> Не в плане теории, а в плане конкретных чисел >> сравним разные языки, подходы и т.п. > > >> А ═собираться ═обязательно? ═Можно ведь и удалённо. Я на Go пишу всего >> месяц ═и ═мне было бы сложно придти и что-то нормально на нём написать >> за малое время. Но сравнить языки было бы интересно. >> Предложу ═простую ═задачку, ═которая ═покажет, ═насколько ═хорошо язык >> работает ═с ═памятью: ═сложить ═все ═значения ═массива, ═состоящего из >> 10000000 ═целых чисел. Код там простой: создаём массив, заполняем его, >> замеряем ═время, ═потом ═в ═цикле ═складываем ═элементы массива, снова >> замеряем время и выдаём результат. Вот мой вариант на Go: >> https://play.golang.org/p/iHGG3nV10L >> Тонкости: ═в песочнице код съедает много процессора и время там всегда >> одно ═и ═то ═же, поэтому его надо сохранить в файл, например main.go и >> потом запустить вот так: go run main.go >> Скомпилировать ═в исполняемый файл можно вот так: go build main.go >> А вот так выйдет более быстрая версия: go build -gcflags="-B" main.go >> Скачать Go можно вот тут: http://golang.org/ >> -- >> С уважением, >> Михаил ═════════════════════════mailto:postmaster на softsearch.ru > > > From 0body0 на rambler.ru Mon Feb 9 22:49:21 2015 From: 0body0 на rambler.ru (=?KOI8-R?Q?=E1=CE=C1=D4=CF=CC=C9=CA_=E7=D2=C9=DB=C1=C5=D7?=) Date: Tue, 10 Feb 2015 09:49:21 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: <1825727633.20150210092847@softsearch.ru> References: <19510226719.20150209161121@softsearch.ru> <1825727633.20150210092847@softsearch.ru> Message-ID: <54D9A9F1.30408@rambler.ru> Linux i386 > gcc -O3 -march=native 3.c -o 3.out && ./3.out Time:(0.00000000)ms . Sum: 49999995000000 иногда но редко получается > gcc -O3 -march=native 3.c -o 3.out && ./3.out Time:(10.00000000)ms . Sum: 49999985000000 Кстати лучше считать с нуля тогда процесор может использовать prefetch 10.02.2015 9:28, Михаил Монашёв пишет: > Здравствуйте, Mons. > > Вот код, который соответствует исходной задаче. > > #include > #include > > int main() > { > unsigned __int32 *arr; > > arr = (unsigned __int32 *) malloc(10000000 * sizeof(unsigned __int32)); > > int i; > for( i=10000000-1; i>=0; i--) { > arr[i] = i; > } > > clock_t start = clock(); > > unsigned __int64 sum; > sum = 0; > for( i=10000000-1; i>=0; i--) { > sum+=arr[i]; > } > > clock_t end = clock(); > > printf("Time:(%0.8f)ms . Sum: %llu", ((double)end-start)/CLOCKS_PER_SEC*1000, sum); > return 0; > } > > C:\Temp>gcc -O3 -march=native 3.c -o 3.exe > 3.c: In function 'main': > 3.c:8:30: warning: incompatible implicit declaration of built-in function 'malloc' [enabled by default] > arr = (unsigned __int32 *) malloc(10000000 * sizeof(unsigned __int32)); > ^ > > C:\Temp>3.exe > Time:(11.00000000)ms . Sum: 49999995000000 > > Это время в 32-битной венде. > > Как победить этот варнинг при компиляции я не разбирался пока. > > >> int main (int argc,char **argv) { >> ═ ═ ═ ═ longint S = atoi(argv[1]); >> ═ ═ ═ ═ longint i,z; >> ═ ═ ═ ═ clock_t start = clock(); >> ═ ═ ═ ═ longint sum = 0; >> ═ ═ ═ ═ for(z = 0; z < 1000; z++ ){ >> ═ ═ ═ ═ ═ ═ ═ ═ sum = 0; >> ═ ═ ═ ═ ═ ═ ═ ═ for (i=0;i < S - S % 16; i+=16) { >> ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ sum += i ═ + i+1 + i+2═ + i+3═ + i+4═ + i+5═ + i+6═ + i+7 >> ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ══+═ i+8 + i+9 + i+10 + i+11 + i+12 + i+13 + i+14 + i+15 >> ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ; >> ═ ═ ═ ═ ═ ═ ═ ═ } >> ═ ═ ═ ═ ═ ═ ═ ═ for (i; i < S; i++ ) { >> ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ sum += i; >> ═ ═ ═ ═ ═ ═ ═ ═ } >> ═ ═ ═ ═ } >> ═ ═ ═ ═ clock_t end = clock(); >> ═ ═ ═ ═ printf("%lu (%0.8f)\n",sum,((double)end-start)/1e6/z); >> } > > > > >> 1.5 ms > >> gcc --std=c99 -O3 -march=native > > > >> --═ >> Mons Anderson >> > > > > >> On 9 февр. 2015 г., at 16:11, Михаил Монашёв >> wrote: >> Здравствуйте, Mons. >> Народ, я не осилил дочитать это всё до конца. >> А давайте-ка соберёмся и померяемся. >> Не в плане теории, а в плане конкретных чисел >> сравним разные языки, подходы и т.п. > > >> А ═собираться ═обязательно? ═Можно ведь и удалённо. Я на Go пишу всего >> месяц ═и ═мне было бы сложно придти и что-то нормально на нём написать >> за малое время. Но сравнить языки было бы интересно. >> Предложу ═простую ═задачку, ═которая ═покажет, ═насколько ═хорошо язык >> работает ═с ═памятью: ═сложить ═все ═значения ═массива, ═состоящего из >> 10000000 ═целых чисел. Код там простой: создаём массив, заполняем его, >> замеряем ═время, ═потом ═в ═цикле ═складываем ═элементы массива, снова >> замеряем время и выдаём результат. Вот мой вариант на Go: >> https://play.golang.org/p/iHGG3nV10L >> Тонкости: ═в песочнице код съедает много процессора и время там всегда >> одно ═и ═то ═же, поэтому его надо сохранить в файл, например main.go и >> потом запустить вот так: go run main.go >> Скомпилировать ═в исполняемый файл можно вот так: go build main.go >> А вот так выйдет более быстрая версия: go build -gcflags="-B" main.go >> Скачать Go можно вот тут: http://golang.org/ >> -- >> С уважением, >> Михаил ═════════════════════════mailto:postmaster на softsearch.ru > > > From alexclear на gmail.com Mon Feb 9 23:41:19 2015 From: alexclear на gmail.com (Alex Chistyakov) Date: Tue, 10 Feb 2015 11:41:19 +0400 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: <54D9A6AB.5080902@rambler.ru> References: <19923524.20150208131028@softsearch.ru> <1448301.L8bfyLT0Ar@rawen> <54D8657A.2050202@rambler.ru> <54D87696.6090201@rambler.ru> <54D9A6AB.5080902@rambler.ru> Message-ID: 2015-02-10 9:35 GMT+03:00 Анатолий Гришаев <0body0 на rambler.ru>: > 10.02.2015 5:27, Alex Chistyakov пишет: > >> 2015-02-09 11:57 GMT+03:00 Анатолий Гришаев <0body0 на rambler.ru>: >>> >>> 09.02.2015 11:01, Daniel Podolsky пишет: >>> >>>>> 1) было исследование программ на C, которое показывало, асинхронный код >>>>> не >>>>> проигрывает тредовому, и довольно >>>>> часто при большой нагрузке оказывается быстрее. ( Кажется это была >>>>> толстая >>>>> зеленая книга) >>>>> 2) За исключением патологических случаем fork по скорости сравним с >>>>> threads. >>>>> 3) Писать и отлаживать на AnyEvent + fork намного проще, чем на >>>>> threads. >>>>> >>>>> Т.е. threads --- это технологический тупик. >>>>> И если он есть это наверно хорошо, но лучше им не пользоваться. >>>>> Выгоды от него ограниченные, а гемороя можно получить в разы больше. >>>> >>>> А приведите, пожалуйста, хотя бы по паре аргументов в поддержку этих >>>> тезисов :) >>> >>> >>> 1) Создание потоков и процессом в Линуксе делается одним вызовом (clone) >>> разница только в копировании адресного пространства при создании >>> процесса, >>> а внутри они ничем не различаются, кроме адресного пространства. >>> Если процесс поток/процесс живет довольно долго, то разницу в накладных >>> расходов при создании процесса можно пренебречь >>> 2) При большом количестве потоков у ядра вырастают накладные расходы на >>> переключение потоков. >>> В случае большой нагрузки вообще говоря количество потоков >>> вырастает(threads), а в случае асинхронной программы это количесто не >>> меняется, поэтому >>> асинхронная модель будет выигрывать за счет накладных расходов ядра >>> системы. >>> 3) Асинхронная программа это однопоточная программа. А поскольку >>> отлаживать >>> однопоточную программу проще чем многопоточную, то >>> и отлаживать асинхронную программу легче, чем программу с потоками. >> >> Это утверждение вопиюще неверно. > > > Ага так и поверил, где аргументы? И что собственно неверно? Значит, вот как мы теперь будем делать: один из нас напишет лютую чушь, а второй ему на это укажет, первый попросит у второго аргументы. То есть, чушь нести будет можно без аргументов - ну, это прекрасно же. > >> >>> 4) В асинхронной программе не нужны средства синхронизации потоков(Из-за >>> многопоточности), которые просто необходимы в потоках. >>> Накладные расходы на синхронизацию не ускоряют поточные программы и >>> иногда >>> могут быть просто чудовищными. >> >> Все мы работаем с базами данных, каман. >> Ну - те из нас, кто работает. > > Во первых не все, и не всегда. Можно пользоваться redis и memcached и не > думать о базах данных. А у memcached внутри не MVCC? O_O > А иногда бывает полезно иметь общий пул данных >> >> Так вот, те, кто работают с базами данных, знают слова вроде >> "оптимистичная блокировка", "MVCC". >> Есть еще такая вещь, как STM. > > Опять не все, и не всегда. Да я уже понял, что не все и не всегда. > Даже если блокировка самая быстрая, это не значит что на неё не используются > ресурсы процессора вообще. Где я это утверждал? > А поход в базу данных это совсем не дешевая альтернатива. Где я говорил, что это альтернатива? > >> >>> 100-200 циклов процессора минимум на одном примитиве. >> >> compare-and-swap это 100-200 циклов процессора минимум? >> Но на что? O_O > > А вы читали Intel Design Manual для IE-32 и IE-64? А Вы читали Orange Book? > А про POSIX ? А про > примитивы синхронизации, как они устроены? Да не - ну куда мне? > А про spin lock, что вам известно? А какая связь между spinlock и CAS? > Почитайте, погуглите. > Может оказаться, что на CAS 100-200 циклов и уходит. Мне интересно другое - с чего Вы вообще про эти 100-200 циклов речь завели? У Вас что, профайлер в это место в коде показал, или что? Или Вам жалко эти 100-200 циклов? Ну вот же все на поверхности лежит: http://stackoverflow.com/questions/2972389/why-is-compareandswap-instruction-considered-expensive Какие спинлоки, какой позикс, какой интел дизайн? Где факты, где основания, где показания профайлера? А то то, что для одного expensive, для другого может быть не expensive - тут вон учаснеги на динамически типизированном языке годами пишут, и норм им. > А одной блокировкой как правило, дело обычно не заканчивается. > > >> >> -- >> SY, >> Alex >> >> >>> Слегка не в тему, но для полноты >>> 5) forkи проще концептуально и приводят к меньшему количеству ошибок в >>> программировании, значит отлаживать будет меньше. >>> >>> >>> >>> >>> -- >>> Moscow.pm mailing list >>> moscow-pm на pm.org | http://moscow.pm.org > > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org From 0body0 на rambler.ru Tue Feb 10 00:25:37 2015 From: 0body0 на rambler.ru (=?KOI8-R?Q?=E1=CE=C1=D4=CF=CC=C9=CA_=E7=D2=C9=DB=C1=C5=D7?=) Date: Tue, 10 Feb 2015 11:25:37 +0300 Subject: [Moscow.pm] =?koi8-r?b?9MXN2SDEzNEgxM/LzMHEz9c=?= In-Reply-To: References: <19923524.20150208131028@softsearch.ru> <1448301.L8bfyLT0Ar@rawen> <54D8657A.2050202@rambler.ru> <54D87696.6090201@rambler.ru> <54D9A6AB.5080902@rambler.ru> Message-ID: <54D9C081.1040101@rambler.ru> 10.02.2015 10:41, Alex Chistyakov пишет: > Это утверждение вопиюще неверно. >> >> Ага так и поверил, где аргументы? И что собственно неверно? > Значит, вот как мы теперь будем делать: один из нас напишет лютую > чушь, а второй ему на это укажет, первый попросит у второго аргументы. > То есть, чушь нести будет можно без аргументов - ну, это прекрасно же. Ну прекрасно на вопрос "О чем это вы?" Вы говорите "А что вы вообще себе позволяете!!!" Вот и прекрасно поговорили. >> Во первых не все, и не всегда. Можно пользоваться redis и memcached и >> не думать о базах данных. > А у memcached внутри не MVCC? O_O Скорее всего нет. MVCC(MultiVersion *Concurrency* *Control) * это относится к базам данных и то не ко всем. И к сожалению к языкам программирования к async,threads, сустемному программированию не относиться ни одним боком. То написано ниже --- не понятно зачем это было написано, и к теме вообще не относиться. > >> А иногда бывает полезно иметь общий пул данных >>> Так вот, те, кто работают с базами данных, знают слова вроде >>> "оптимистичная блокировка", "MVCC". >>> Есть еще такая вещь, как STM. >> Опять не все, и не всегда. > Да я уже понял, что не все и не всегда. > >> Даже если блокировка самая быстрая, это не значит что на неё не используются >> ресурсы процессора вообще. > Где я это утверждал? > >> А поход в базу данных это совсем не дешевая альтернатива. > Где я говорил, что это альтернатива? > >>>> 100-200 циклов процессора минимум на одном примитиве. >>> compare-and-swap это 100-200 циклов процессора минимум? >>> Но на что? O_O >> А вы читали Intel Design Manual для IE-32 и IE-64? > А Вы читали Orange Book? > >> А про POSIX ? А про >> примитивы синхронизации, как они устроены? > Да не - ну куда мне? > >> А про spin lock, что вам известно? > А какая связь между spinlock и CAS? > >> Почитайте, погуглите. >> Может оказаться, что на CAS 100-200 циклов и уходит. > Мне интересно другое - с чего Вы вообще про эти 100-200 циклов речь завели? > У Вас что, профайлер в это место в коде показал, или что? > Или Вам жалко эти 100-200 циклов? > Ну вот же все на поверхности лежит: > http://stackoverflow.com/questions/2972389/why-is-compareandswap-instruction-considered-expensive > Какие спинлоки, какой позикс, какой интел дизайн? > Где факты, где основания, где показания профайлера? > А то то, что для одного expensive, для другого может быть не expensive > - тут вон учаснеги на динамически типизированном языке годами пишут, и > норм им. > >> А одной блокировкой как правило, дело обычно не заканчивается. >> >> >>> -- >>> SY, >>> Alex >>> >>> >>>> Слегка не в тему, но для полноты >>>> 5) forkи проще концептуально и приводят к меньшему количеству ошибок в >>>> программировании, значит отлаживать будет меньше. >>>> >>>> >>>> >>>> >>>> -- >>>> Moscow.pm mailing list >>>> moscow-pm на pm.org | http://moscow.pm.org >> >> -- >> Moscow.pm mailing list >> moscow-pm на pm.org | http://moscow.pm.org ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From akovbovich на gmail.com Tue Feb 10 00:29:09 2015 From: akovbovich на gmail.com (Andrey Kovbovich) Date: Tue, 10 Feb 2015 12:29:09 +0400 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= In-Reply-To: <54D9A9F1.30408@rambler.ru> References: <19510226719.20150209161121@softsearch.ru> <1825727633.20150210092847@softsearch.ru> <54D9A9F1.30408@rambler.ru> Message-ID: ? ~ ? /Applications/Julia-0.3.5.app/Contents/Resources/julia/bin/julia -e '@time x=Int32[0:10000000-1];@time s=sum(x);print(s)' elapsed time: 0.088132927 seconds (40157560 bytes allocated, 21.96% gc time) elapsed time: 0.05047629 seconds (910000 bytes allocated) 49999995000000% ? /Applications/j64-701 ? ./bin/jconsole 7!:2 'x=:i.10000000' 134219264 6!:2 's=:+/x' 0.016223 s 49999995000000 итого: Julia 50ms/38MB J 16ms/128MB 10 февраля 2015 г., 9:49 пользователь Анатолий Гришаев <0body0 на rambler.ru> написал: > > Linux i386 > > gcc -O3 -march=native 3.c -o 3.out && ./3.out > Time:(0.00000000)ms . Sum: 49999995000000 > > иногда но редко получается > > gcc -O3 -march=native 3.c -o 3.out && ./3.out > Time:(10.00000000)ms . Sum: 49999985000000 > > Кстати лучше считать с нуля тогда процесор может использовать prefetch > > 10.02.2015 9:28, Михаил Монашёв пишет: > >> Здравствуйте, Mons. >> >> >> Вот код, который соответствует исходной задаче. >> >> #include >> #include >> >> int main() >> { >> unsigned __int32 *arr; >> >> arr = (unsigned __int32 *) malloc(10000000 * sizeof(unsigned >> __int32)); >> >> int i; >> for( i=10000000-1; i>=0; i--) { >> arr[i] = i; >> } >> >> clock_t start = clock(); >> >> unsigned __int64 sum; >> sum = 0; >> for( i=10000000-1; i>=0; i--) { >> sum+=arr[i]; >> } >> >> clock_t end = clock(); >> >> printf("Time:(%0.8f)ms . Sum: %llu", ((double)end-start)/CLOCKS_PER_SEC*1000, >> sum); >> return 0; >> } >> >> C:\Temp>gcc -O3 -march=native 3.c -o 3.exe >> 3.c: In function 'main': >> 3.c:8:30: warning: incompatible implicit declaration of built-in function >> 'malloc' [enabled by default] >> arr = (unsigned __int32 *) malloc(10000000 * sizeof(unsigned >> __int32)); >> ^ >> >> C:\Temp>3.exe >> Time:(11.00000000)ms . Sum: 49999995000000 >> >> Это время в 32-битной венде. >> >> Как победить этот варнинг при компиляции я не разбирался пока. >> >> >> int main (int argc,char **argv) { >>> ═ ═ ═ ═ longint S = atoi(argv[1]); >>> ═ ═ ═ ═ longint i,z; >>> ═ ═ ═ ═ clock_t start = clock(); >>> ═ ═ ═ ═ longint sum = 0; >>> ═ ═ ═ ═ for(z = 0; z < 1000; z++ ){ >>> ═ ═ ═ ═ ═ ═ ═ ═ sum = 0; >>> ═ ═ ═ ═ ═ ═ ═ ═ for (i=0;i < S - S % 16; i+=16) { >>> ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ sum += i ═ + i+1 + i+2═ + i+3═ + i+4═ + i+5═ + >>> i+6═ + i+7 >>> ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ══+═ i+8 + i+9 + i+10 + i+11 + i+12 + i+13 + >>> i+14 + i+15 >>> ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ; >>> ═ ═ ═ ═ ═ ═ ═ ═ } >>> ═ ═ ═ ═ ═ ═ ═ ═ for (i; i < S; i++ ) { >>> ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ sum += i; >>> ═ ═ ═ ═ ═ ═ ═ ═ } >>> ═ ═ ═ ═ } >>> ═ ═ ═ ═ clock_t end = clock(); >>> ═ ═ ═ ═ printf("%lu (%0.8f)\n",sum,((double)end-start)/1e6/z); >>> } >>> >> >> >> >> >> 1.5 ms >>> >> >> gcc --std=c99 -O3 -march=native >>> >> >> >> >> --═ >>> Mons Anderson >>> >>> >> >> >> >> >> On 9 февр. 2015 г., at 16:11, Михаил Монашёв >>> wrote: >>> Здравствуйте, Mons. >>> Народ, я не осилил дочитать это всё до конца. >>> А давайте-ка соберёмся и померяемся. >>> Не в плане теории, а в плане конкретных чисел >>> сравним разные языки, подходы и т.п. >>> >> >> >> А ═собираться ═обязательно? ═Можно ведь и удалённо. Я на Go пишу всего >>> месяц ═и ═мне было бы сложно придти и что-то нормально на нём написать >>> за малое время. Но сравнить языки было бы интересно. >>> Предложу ═простую ═задачку, ═которая ═покажет, ═насколько ═хорошо язык >>> работает ═с ═памятью: ═сложить ═все ═значения ═массива, ═состоящего из >>> 10000000 ═целых чисел. Код там простой: создаём массив, заполняем его, >>> замеряем ═время, ═потом ═в ═цикле ═складываем ═элементы массива, снова >>> замеряем время и выдаём результат. Вот мой вариант на Go: >>> https://play.golang.org/p/iHGG3nV10L >>> Тонкости: ═в песочнице код съедает много процессора и время там всегда >>> одно ═и ═то ═же, поэтому его надо сохранить в файл, например main.go и >>> потом запустить вот так: go run main.go >>> Скомпилировать ═в исполняемый файл можно вот так: go build main.go >>> А вот так выйдет более быстрая версия: go build -gcflags="-B" main.go >>> Скачать Go можно вот тут: http://golang.org/ >>> -- >>> С уважением, >>> Михаил ═════════════════════════mailto:postmaster на softsearch.ru >>> >> >> >> >> > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From alexclear на gmail.com Tue Feb 10 01:01:54 2015 From: alexclear на gmail.com (Alex Chistyakov) Date: Tue, 10 Feb 2015 13:01:54 +0400 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: <54D9C081.1040101@rambler.ru> References: <19923524.20150208131028@softsearch.ru> <1448301.L8bfyLT0Ar@rawen> <54D8657A.2050202@rambler.ru> <54D87696.6090201@rambler.ru> <54D9A6AB.5080902@rambler.ru> <54D9C081.1040101@rambler.ru> Message-ID: 2015-02-10 11:25 GMT+03:00 Анатолий Гришаев <0body0 на rambler.ru>: > 10.02.2015 10:41, Alex Chistyakov пишет: > > Это утверждение вопиюще неверно. > > Ага так и поверил, где аргументы? И что собственно неверно? > > Значит, вот как мы теперь будем делать: один из нас напишет лютую > чушь, а второй ему на это укажет, первый попросит у второго аргументы. > То есть, чушь нести будет можно без аргументов - ну, это прекрасно же. > > Ну прекрасно на вопрос "О чем это вы?" Вы говорите "А что вы вообще себе > позволяете!!!" > Вот и прекрасно поговорили. Стало быть - аргументов Вы не предоставите. Хорошо, тогда я их предоставлю. В данный момент в индустрии существует представление о том, что асинхронный код сложнее для понимания человеком, чем синхронный. Речь идет о понимании средним человеком, а не профессионалом, который два десятка лет на такие вещи смотрит. Вы сейчас можете, конечно, начать утверждать, что Вы и есть тот профессионал (да и все здесь), но я уже давно перестал верить в Деда Мороза и другие сказки. > > Во первых не все, и не всегда. Можно пользоваться redis и memcached и не > думать о базах данных. > > А у memcached внутри не MVCC? O_O > > > Скорее всего нет. Не "скорее всего нет", а "точно да". > > MVCC(MultiVersion Concurrency Control) это относится к базам данных и то не > ко всем. Я знаю, к чему это относится. У memcached внутри мультиверсионность, это совершенно точно. > И к сожалению к языкам программирования к async,threads, сустемному > программированию не относиться ни одним боком. Когда я писал про STM, Вы это предпочли проигнорировать - это потому, что Вы перловик? Вот веди я дискуссию, скажем, с лиспером, он бы взглядом зацепился бы. Но еще не поздно - давайте все вернем, как было, и Вы мне объясните, чем Вам STM не MVCC. > То написано ниже --- не понятно зачем это было написано, и к теме вообще не > относиться. Конечно, я уже понял - аргументов опять не будет. -- SY, Alex > > > > > > А иногда бывает полезно иметь общий пул данных > > Так вот, те, кто работают с базами данных, знают слова вроде > "оптимистичная блокировка", "MVCC". > Есть еще такая вещь, как STM. > > Опять не все, и не всегда. > > Да я уже понял, что не все и не всегда. > > Даже если блокировка самая быстрая, это не значит что на неё не используются > ресурсы процессора вообще. > > Где я это утверждал? > > А поход в базу данных это совсем не дешевая альтернатива. > > Где я говорил, что это альтернатива? > > 100-200 циклов процессора минимум на одном примитиве. > > compare-and-swap это 100-200 циклов процессора минимум? > Но на что? O_O > > А вы читали Intel Design Manual для IE-32 и IE-64? > > А Вы читали Orange Book? > > А про POSIX ? А про > примитивы синхронизации, как они устроены? > > Да не - ну куда мне? > > А про spin lock, что вам известно? > > А какая связь между spinlock и CAS? > > Почитайте, погуглите. > Может оказаться, что на CAS 100-200 циклов и уходит. > > Мне интересно другое - с чего Вы вообще про эти 100-200 циклов речь завели? > У Вас что, профайлер в это место в коде показал, или что? > Или Вам жалко эти 100-200 циклов? > Ну вот же все на поверхности лежит: > http://stackoverflow.com/questions/2972389/why-is-compareandswap-instruction-considered-expensive > Какие спинлоки, какой позикс, какой интел дизайн? > Где факты, где основания, где показания профайлера? > А то то, что для одного expensive, для другого может быть не expensive > - тут вон учаснеги на динамически типизированном языке годами пишут, и > норм им. > > А одной блокировкой как правило, дело обычно не заканчивается. > > > -- > SY, > Alex > > > Слегка не в тему, но для полноты > 5) forkи проще концептуально и приводят к меньшему количеству ошибок в > программировании, значит отлаживать будет меньше. > > > > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > > > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > From ruslan.zakirov на gmail.com Tue Feb 10 01:11:50 2015 From: ruslan.zakirov на gmail.com (Ruslan Zakirov) Date: Tue, 10 Feb 2015 13:11:50 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: References: Message-ID: 2015-02-08 21:35 GMT+03:00 Daniel Podolsky : > о! собеседник! > > >> > Ага. В этом смысле асинхронный подход ближе к реальности. > >> вам ближе к реальности или деньги зарабатывать? > > Смотря чем зарабатывать. Есть много задач, где асинхронный код позволяет > > сильно сэкономить ресурсы серверов. > а вот давайте разберемся, какие именно ресурсы серверов позволяет > сэкономить асинхронный код, и справедливо ли это утверждение для > асинхронного кода на перле. > > изложите, пожалуйста, тезис об экономии подробнее. а то я так много об > этом думал, что мгновенно начинаю с демонами в своей голове > разговаривать, как об асинхронном перле речь заходит :( > Экономия по сравнению с prefork моделями в Perl. Если задач "io-bound", а не cpu bound. Просто один процесс блокирующий может обрабатывать 1 заброс в данный конкретный момент времени, а неблокирующий сколько вашей душе угодно (пока не уперлись в лимиты). Так или иначе вес процесса в perl достаточно высокий, а также после fork расшареные страницы клонируются может и не все, но многие, то есть шарим не так много (были тесты еще в mod_perl1 сообществе). Если у вас задача обрабатывать 10000 параллельных соединений с малой нагрузкой на CPU, то в prefork модели вам понадобиться 10000 worker'ов, а в событийной N CPU*1 (или 2, 4, 6 - не считал потери). Если у вас задача CPU bound, то вам событийная модель мало чем поможет. Единственное, что вы можете сделать, так это распараллелить один таск на несколько ядер (тредами, горутинами, сторонней либой, Си+треды, ...). Не важно как вы это сделаете, но если у вас 64 ядра и вы можете за разумное время на них исполнять только 64 параллельные задачи одновременно, то какая разница на какой это модели. Если задача memory bound, то опять число обработчиков ограничено памятью системы и как вы не старайтесь, но на N задача нужно O(k*N) памяти и размер самого worker'а уже не имеет значения. О thread'ах в perl говорить не будем. > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > -- Best regards, Ruslan. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From ruslan.zakirov на gmail.com Tue Feb 10 01:15:05 2015 From: ruslan.zakirov на gmail.com (Ruslan Zakirov) Date: Tue, 10 Feb 2015 13:15:05 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: References: Message-ID: 2015-02-08 22:11 GMT+03:00 Alexander Lourier : > Потоки лучше, чем асинхронный код, потому что они будут выполняться на > разных ядрах. Асинхронный код лучше тем, что не надо сохранять состояние > процессора при переключении. В многопоточном коде надо заботиться о > блокировках общих ресурсов, сложно разделять данные между потоками (общие > пулы соединений к базе, общие кэши и т.д.) Стоит заметить, что давно решили проблему многоядерности простым форканием асинхронных обработчиков по числу ядер в системе. -- Best regards, Ruslan. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From ruslan.zakirov на gmail.com Tue Feb 10 01:20:18 2015 From: ruslan.zakirov на gmail.com (Ruslan Zakirov) Date: Tue, 10 Feb 2015 13:20:18 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: References: Message-ID: 2015-02-08 22:31 GMT+03:00 Daniel Podolsky : > > Экономится память, в первую очередь. > Но есть нюанс > > > Решение в > > лоб - добавить число процессов. Но каждый из них потребляет память, > которая > > не резиновая. > Если мы правильно написали программу - у нас на fork происходит CoW. в > результате - свои у каждого процесса только буфера, которые все равно > свои на каждое соединение. > CoW у вас там где даные не меняются, а в Perl даже интроспекция может поменять данные. > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > -- Best regards, Ruslan. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From alexclear на gmail.com Tue Feb 10 01:21:46 2015 From: alexclear на gmail.com (Alex Chistyakov) Date: Tue, 10 Feb 2015 13:21:46 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: References: <4313772.nGeHKfApF6@rawen> Message-ID: 2015-02-08 22:13 GMT+03:00 Daniel Podolsky : >> Реализация асинхронной модели приложением >> позволяет использовать более эффективную в плане ресурсов процессора и памяти >> кооперативную многозадачность. > вот как раз этот тезис я и прошу развернуть! > > большая эффективность в плане ресурсов процессора - это только то > самое переключение контекста? или что-то еще? > > большая эффективность в плане ресурсов памяти - откуда она берется? В моменты, когда воркеры заблокированы на взаимодействии с внешними ресурсами, они все еще занимают память, но ничего полезного же не делают. > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org From onokonem на gmail.com Tue Feb 10 01:24:30 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Tue, 10 Feb 2015 13:24:30 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: References: Message-ID: > Стоит заметить, что давно решили проблему многоядерности простым форканием > асинхронных обработчиков по числу ядер в системе. а что за "проблема многоядерности"? и почему ее решает многопроцессная модель? межпроцессное взаимодействие как было проблемой - так и остается. многотредная программа - да, способна эффективно утилизировать все наличные ядра. а многопроцессная - только если наша задача масштабируется горизонтально без проблем... From ruslan.zakirov на gmail.com Tue Feb 10 01:30:24 2015 From: ruslan.zakirov на gmail.com (Ruslan Zakirov) Date: Tue, 10 Feb 2015 13:30:24 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: <6A76C1C0-12AC-4E28-8F29-A26967AC9FDE@gmail.com> References: <936264802.20150208214721@softsearch.ru> <39967E84-8DCC-49E3-9121-85FDDBA25078@gmail.com> <6A76C1C0-12AC-4E28-8F29-A26967AC9FDE@gmail.com> Message-ID: 2015-02-08 22:34 GMT+03:00 Eugene Toropov : > Согласен, просто хотел привести красивый пример :) Чем больше IO - тем > больше выигрыш > > On 08 Feb 2015, at 22:26, Daniel Podolsky wrote: > > >> Да ни фига там не быстрее, просто экономится память (и больше ничего, > насколько я знаю), а в результате у nginx ?На 10 000 неактивных HTTP > keep-alive соединений расходуется около 2.5M памяти? > > nginx - это очень для нашего разговора плохой пример. > > > > nginx это программа, которая ничего не делает! фактически, только > > передает указатели на буфера между системными вызовами... > > > > если нам нужна еще одна такая программа - да, асинхронное > > программирование рулит. если нет - нет. > Примеров много: * online чаты, уведомления пользователей о новых событиях * очереди, обработка сообщений очередей * большинство стриминг задач * .... > > -- > > Moscow.pm mailing list > > moscow-pm на pm.org | http://moscow.pm.org > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > -- Best regards, Ruslan. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From onokonem на gmail.com Tue Feb 10 01:38:45 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Tue, 10 Feb 2015 13:38:45 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: References: <4313772.nGeHKfApF6@rawen> Message-ID: > В моменты, когда воркеры заблокированы на взаимодействии с внешними > ресурсами, они все еще занимают память, но ничего полезного же не > делают. все мы в курсе, под какую задачу были сделаны mod_accel и nginx :) From ruslan.zakirov на gmail.com Tue Feb 10 01:39:58 2015 From: ruslan.zakirov на gmail.com (Ruslan Zakirov) Date: Tue, 10 Feb 2015 13:39:58 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: References: Message-ID: 2015-02-10 12:24 GMT+03:00 Daniel Podolsky : > > Стоит заметить, что давно решили проблему многоядерности простым > форканием > > асинхронных обработчиков по числу ядер в системе. > а что за "проблема многоядерности"? и почему ее решает многопроцессная > модель? > > межпроцессное взаимодействие как было проблемой - так и остается. > > многотредная программа - да, способна эффективно утилизировать все > наличные ядра. а многопроцессная - только если наша задача > масштабируется горизонтально без проблем... > Какие задачи требуют такого взаимодействия между процессами? Если у вас одна атомарная задача требует несколько CPU. Использование одного CPU для нее не подходит из-за времени исполнения, то задача приближается к категории CPU bound или уже в ней. Тут идем в мой первый ответ в этой теме и используем более подходящий язык (с встроенной утилизацией многих ядер над одним пулом данных), треды системные, сторонние инструменты или еще чего. > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > -- Best regards, Ruslan. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From alexclear на gmail.com Tue Feb 10 01:45:46 2015 From: alexclear на gmail.com (Alex Chistyakov) Date: Tue, 10 Feb 2015 13:45:46 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: References: <4313772.nGeHKfApF6@rawen> Message-ID: 2015-02-10 12:38 GMT+03:00 Daniel Podolsky : >> В моменты, когда воркеры заблокированы на взаимодействии с внешними >> ресурсами, они все еще занимают память, но ничего полезного же не >> делают. > все мы в курсе, под какую задачу были сделаны mod_accel и nginx :) При этом "внешним ресурсом" является даже наша собственная база данных - и тут никакой nginx не спасает. > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org From 0body0 на rambler.ru Tue Feb 10 01:46:12 2015 From: 0body0 на rambler.ru (=?KOI8-R?Q?=E1=CE=C1=D4=CF=CC=C9=CA_=E7=D2=C9=DB=C1=C5=D7?=) Date: Tue, 10 Feb 2015 12:46:12 +0300 Subject: [Moscow.pm] =?koi8-r?b?9MXN2SDEzNEgxM/LzMHEz9c=?= In-Reply-To: References: <19923524.20150208131028@softsearch.ru> <1448301.L8bfyLT0Ar@rawen> <54D8657A.2050202@rambler.ru> <54D87696.6090201@rambler.ru> <54D9A6AB.5080902@rambler.ru> <54D9C081.1040101@rambler.ru> Message-ID: <54D9D364.80208@rambler.ru> 10.02.2015 12:01, Alex Chistyakov пишет: > 2015-02-10 11:25 GMT+03:00 Анатолий Гришаев <0body0 на rambler.ru>: >> 10.02.2015 10:41, Alex Chistyakov пишет: >> >> Это утверждение вопиюще неверно. >> >> Ага так и поверил, где аргументы? И что собственно неверно? >> >> Значит, вот как мы теперь будем делать: один из нас напишет лютую >> чушь, а второй ему на это укажет, первый попросит у второго аргументы. >> То есть, чушь нести будет можно без аргументов - ну, это прекрасно же. >> >> Ну прекрасно на вопрос "О чем это вы?" Вы говорите "А что вы вообще себе >> позволяете!!!" >> Вот и прекрасно поговорили. > Стало быть - аргументов Вы не предоставите. > Хорошо, тогда я их предоставлю. > В данный момент в индустрии существует представление о том, что > асинхронный код сложнее для понимания человеком, чем синхронный. > Речь идет о понимании средним человеком, а не профессионалом, который > два десятка лет на такие вещи смотрит. > Вы сейчас можете, конечно, начать утверждать, что Вы и есть тот > профессионал (да и все здесь), но я уже давно перестал верить в Деда > Мороза и другие сказки. Естественно что однопоточный синхронный код проще однопоточного асинхронного кода и я с этим утверждением не оспаривал. В контексте я сравнивал многопоточный синхронный и однопоточный асинхронный код. С моей точки зрения всегда многопоточная модель сложнее чем любая однопоточная асинхронная. 1) С точки зрения отладки, а имено использования отладчика, а не использования print ... однопоточные приложения сильно проще, потому легче понять когда у тебя один поток насилует одну структуру чем когда 20 нитей одну структуру. 2) Вообще отладчики для многонитевых программ появились позже обычных (Про отладчик perl я вообще молчу (его съедобно запускать только в однопоточном режиме, кмк) 3) Программы в которых несколько потоков делают одну работу просто сложнее, чем там где туже работу делает один поток, хотя бы из-за необходимости синхронизации. Пример: перемножение матрицы. 4) Мой препод --- профессор всю жизнь занимался вычислительными методами на многопроцессорными системами и программировал на суперкомпьютерах, так говорил и мне кажется ему можно верить. Естественно, если потокам не нужно кооперироваться( нету общих данных), то разницы большой между однопоточной и многопоточной программой нет. > >> Во первых не все, и не всегда. Можно пользоваться redis и memcached и не >> думать о базах данных. >> >> А у memcached внутри не MVCC? O_O >> >> >> Скорее всего нет. > Не "скорее всего нет", а "точно да". А какой примитив системы отвечает за MVCC. Можно реализовать memcached на основе мьютекса. MVCC это оverkill для такой задачи. > >> MVCC(MultiVersion Concurrency Control) это относится к базам данных и то не >> ко всем. > Когда я писал про STM, Вы это предпочли проигнорировать - это потому, > что Вы перловик? Вот веди я дискуссию, скажем, с лиспером, он бы > взглядом зацепился бы. Но еще не поздно - давайте все вернем, как > было, и Вы мне объясните, чем Вам STM не MVCC. Вы хотите сказать что при использовании STM издержек не больше, чем при использовании обычной памяти? Или что Вы имели в виду? И причем тут обсуждаемая тема? Если про издержки, то собственно стоимость блокировок и складывается из этих издержек в частности. (зачем же обсуждать очевидные вещи, если они входят в тему, а с моей точки зрения не входят) (Как бы я и на лиспе и scheme программирую еще разбавляю C, XS, Oracle, SmallTalk. Но зачем за все цепляться, жизни не хватит) >> То написано ниже --- не понятно зачем это было написано, и к теме вообще не >> относиться. > Конечно, я уже понял - аргументов опять не будет. > > -- > SY, > Alex > >> >> >> >> >> А иногда бывает полезно иметь общий пул данных >> >> Так вот, те, кто работают с базами данных, знают слова вроде >> "оптимистичная блокировка", "MVCC". >> Есть еще такая вещь, как STM. >> >> Опять не все, и не всегда. >> >> Да я уже понял, что не все и не всегда. >> >> Даже если блокировка самая быстрая, это не значит что на неё не используются >> ресурсы процессора вообще. >> >> Где я это утверждал? >> >> А поход в базу данных это совсем не дешевая альтернатива. >> >> Где я говорил, что это альтернатива? >> >> 100-200 циклов процессора минимум на одном примитиве. >> >> compare-and-swap это 100-200 циклов процессора минимум? >> Но на что? O_O >> >> А вы читали Intel Design Manual для IE-32 и IE-64? >> >> А Вы читали Orange Book? >> >> А про POSIX ? А про >> примитивы синхронизации, как они устроены? >> >> Да не - ну куда мне? >> >> А про spin lock, что вам известно? >> >> А какая связь между spinlock и CAS? >> >> Почитайте, погуглите. >> Может оказаться, что на CAS 100-200 циклов и уходит. >> >> Мне интересно другое - с чего Вы вообще про эти 100-200 циклов речь завели? >> У Вас что, профайлер в это место в коде показал, или что? >> Или Вам жалко эти 100-200 циклов? >> Ну вот же все на поверхности лежит: >> http://stackoverflow.com/questions/2972389/why-is-compareandswap-instruction-considered-expensive >> Какие спинлоки, какой позикс, какой интел дизайн? >> Где факты, где основания, где показания профайлера? >> А то то, что для одного expensive, для другого может быть не expensive >> - тут вон учаснеги на динамически типизированном языке годами пишут, и >> норм им. >> >> А одной блокировкой как правило, дело обычно не заканчивается. >> >> >> -- >> SY, >> Alex >> >> >> Слегка не в тему, но для полноты >> 5) forkи проще концептуально и приводят к меньшему количеству ошибок в >> программировании, значит отлаживать будет меньше. >> >> >> >> >> -- >> Moscow.pm mailing list >> moscow-pm на pm.org | http://moscow.pm.org >> >> -- >> Moscow.pm mailing list >> moscow-pm на pm.org | http://moscow.pm.org >> >> >> >> -- >> Moscow.pm mailing list >> moscow-pm на pm.org | http://moscow.pm.org >> From onokonem на gmail.com Tue Feb 10 01:51:44 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Tue, 10 Feb 2015 13:51:44 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: References: <936264802.20150208214721@softsearch.ru> <39967E84-8DCC-49E3-9121-85FDDBA25078@gmail.com> <6A76C1C0-12AC-4E28-8F29-A26967AC9FDE@gmail.com> Message-ID: > Примеров много: > * online чаты, уведомления пользователей о новых событиях > * очереди, обработка сообщений очередей > * большинство стриминг задач > * .... задача типа "прокси", да, спасибо. почему в этом ряду оказались очереди - я не очень понимаю, ну да и хрен с ним. Вот какой вопрос меня мучит: почему бытует мнение, что эту задачу эффективно решать на perl? Пусть даже и с применением AnyEvent... From onokonem на gmail.com Tue Feb 10 01:59:05 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Tue, 10 Feb 2015 13:59:05 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: References: <4313772.nGeHKfApF6@rawen> Message-ID: > При этом "внешним ресурсом" является даже наша собственная база данных > - и тут никакой nginx не спасает. а?! если мы обработку запроса не закончили - как ты хочешь выделенную на эту обработку память отдать? хоть бы и в асинхронном приложении? а если закончили - чего мы в базу-то полезли? From 0body0 на rambler.ru Tue Feb 10 02:02:54 2015 From: 0body0 на rambler.ru (=?KOI8-R?Q?=E1=CE=C1=D4=CF=CC=C9=CA_=E7=D2=C9=DB=C1=C5=D7?=) Date: Tue, 10 Feb 2015 13:02:54 +0300 Subject: [Moscow.pm] =?koi8-r?b?wdPJzsjSz87O2cogy8/EINDP2tfPzNHF1CDTyczY?= =?koi8-r?b?zs8g09zLz87PzcnU2CDSxdPV0tPZINPF0tfF0s/X?= In-Reply-To: References: <936264802.20150208214721@softsearch.ru> <39967E84-8DCC-49E3-9121-85FDDBA25078@gmail.com> <6A76C1C0-12AC-4E28-8F29-A26967AC9FDE@gmail.com> Message-ID: <54D9D74E.1020100@rambler.ru> 10.02.2015 12:51, Daniel Podolsky пишет: >> Примеров много: >> * online чаты, уведомления пользователей о новых событиях >> * очереди, обработка сообщений очередей >> * большинство стриминг задач >> * .... > задача типа "прокси", да, спасибо. почему в этом ряду оказались > очереди - я не очень понимаю, ну да и хрен с ним. > > Вот какой вопрос меня мучит: почему бытует мнение, что эту задачу > эффективно решать на perl? Пусть даже и с применением AnyEvent... Это mons рассказывал на moscow.pm как эту задачу эффективно решать. Проведенные в нашей фирме эксперементы показали, если правильно сделать, то программа на perl + AE также эффективна, как написанная на C, а пишется и отлаживается быстрее. Но это лучше mons расскажет, заодно про инструменты которыми он пользуется. Я то почти все "на глаз" меряю, надо исправлятся.:) From mialinx на gmail.com Tue Feb 10 02:04:12 2015 From: mialinx на gmail.com (Dmitry Smal) Date: Tue, 10 Feb 2015 13:04:12 +0300 Subject: [Moscow.pm] =?koi8-r?b?wdPJzsjSz87O2cogy8/EINDP2tfPzNHF1CDTyczY?= =?koi8-r?b?zs8g09zLz87PzcnU2CDSxdPV0tPZINPF0tfF0s/X?= In-Reply-To: References: <4313772.nGeHKfApF6@rawen> Message-ID: <54D9D79C.9030402@gmail.com> On 02/10/2015 12:59 PM, Daniel Podolsky wrote: >> При этом "внешним ресурсом" является даже наша собственная база данных >> - и тут никакой nginx не спасает. > а?! > > если мы обработку запроса не закончили - как ты хочешь выделенную на > эту обработку память отдать? хоть бы и в асинхронном приложении? В ассинхронном приложение все данные которые висят в памяти это занятый хендл к базе и пара десятков хешей/массивов который представляют собой "запрос". В синхронном коде - весь процесс воркера. Который через пару-тройку лет разработки может дорасти до 100M RES. > > а если закончили - чего мы в базу-то полезли? From ilvin на mail.ru Tue Feb 10 02:08:57 2015 From: ilvin на mail.ru (=?UTF-8?B?0JjQu9GM0Y8g0JLQuNC90L7QutGD0YDQvtCy?=) Date: Tue, 10 Feb 2015 13:08:57 +0300 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= In-Reply-To: References: <19510226719.20150209161121@softsearch.ru> Message-ID: <1423562937.522290480@f30.i.mail.ru> Марку процессора укажите пожалуйста... :) С почтением,   Илья Винокуров. Вторник, 10 февраля 2015, 5:22 +03:00 от Mons Anderson : >int main ( int argc, char **argv) { >        long int S = atoi(argv[ 1 ]); >        long int i,z; >        clock_t start = clock(); >        long int sum = 0 ; >        for (z = 0 ; z < 1000 ; z++ ){ >                sum = 0 ; >                for (i= 0 ;i < S - S % 16 ; i+= 16 ) { >                        sum += i   + i+ 1 + i+ 2   + i+ 3   + i+ 4   + i+ 5   + i+ 6  + i+ 7 >                            +  i+ 8 + i+ 9 + i+ 10 + i+ 11 + i+ 12 + i+ 13 + i+ 14 + i+ 15 >                        ; >                } >                for (i; i < S; i++ ) { >                        sum += i; >                } >        } >        clock_t end = clock(); >        printf( " %lu ( %0.8f ) \n " ,sum,(( double )end-start)/ 1e6 /z); >} > > >1.5 ms > >gcc --std=c99 -O3 -march=native > > >--  >Mons Anderson >< mons на cpan.org > > > >>On 9 февр. 2015 г., at 16:11, Михаил Монашёв < postmaster на softsearch.ru > wrote: >>Здравствуйте, Mons. >> >>>Народ, я не осилил дочитать это всё до конца. >>>А давайте-ка соберёмся и померяемся. >>>Не в плане теории, а в плане конкретных чисел >>>сравним разные языки, подходы и т.п. >> >>А  собираться  обязательно?  Можно ведь и удалённо. Я на Go пишу всего >>месяц  и  мне было бы сложно придти и что-то нормально на нём написать >>за малое время. Но сравнить языки было бы интересно. >> >>Предложу  простую  задачку,  которая  покажет,  насколько  хорошо язык >>работает  с  памятью:  сложить  все  значения  массива,  состоящего из >>10000000  целых чисел. Код там простой: создаём массив, заполняем его, >>замеряем  время,  потом  в  цикле  складываем  элементы массива, снова >>замеряем время и выдаём результат. Вот мой вариант на Go: >>https://play.golang.org/p/iHGG3nV10L >> >>Тонкости:  в песочнице код съедает много процессора и время там всегда >>одно  и  то  же, поэтому его надо сохранить в файл, например main.go и >>потом запустить вот так: go run main.go >>Скомпилировать  в исполняемый файл можно вот так: go build main.go >>А вот так выйдет более быстрая версия: go build -gcflags="-B" main.go >>Скачать Go можно вот тут: http://golang.org/ >> >>-- >>С уважением, >>Михаил                          mailto:postmaster на softsearch.ru >> >>-- >>Moscow.pm mailing list >>moscow-pm на pm.org | http://moscow.pm.org > >-- >Moscow.pm mailing list >moscow-pm на pm.org | http://moscow.pm.org ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From onokonem на gmail.com Tue Feb 10 02:14:03 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Tue, 10 Feb 2015 14:14:03 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: <54D9D79C.9030402@gmail.com> References: <4313772.nGeHKfApF6@rawen> <54D9D79C.9030402@gmail.com> Message-ID: > В синхронном коде - весь процесс воркера. Который через пару-тройку лет > разработки может дорасти до 100M RES. асинхронный код у тебя за пару-тройку лет разработки в конфетку превратится, ага... From mialinx на gmail.com Tue Feb 10 02:36:33 2015 From: mialinx на gmail.com (Dmitry Smal) Date: Tue, 10 Feb 2015 13:36:33 +0300 Subject: [Moscow.pm] =?koi8-r?b?wdPJzsjSz87O2cogy8/EINDP2tfPzNHF1CDTyczY?= =?koi8-r?b?zs8g09zLz87PzcnU2CDSxdPV0tPZINPF0tfF0s/X?= In-Reply-To: References: <4313772.nGeHKfApF6@rawen> <54D9D79C.9030402@gmail.com> Message-ID: <54D9DF31.5000704@gmail.com> On 02/10/2015 01:14 PM, Daniel Podolsky wrote: >> В синхронном коде - весь процесс воркера. Который через пару-тройку лет >> разработки может дорасти до 100M RES. > асинхронный код у тебя за пару-тройку лет разработки в конфетку > превратится, ага... Не превратится. Но будет занимать 100М * число ядер. Префорк будет занимать 100М * число форков. From onokonem на gmail.com Tue Feb 10 02:37:05 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Tue, 10 Feb 2015 14:37:05 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: <54D9D74E.1020100@rambler.ru> References: <936264802.20150208214721@softsearch.ru> <39967E84-8DCC-49E3-9121-85FDDBA25078@gmail.com> <6A76C1C0-12AC-4E28-8F29-A26967AC9FDE@gmail.com> <54D9D74E.1020100@rambler.ru> Message-ID: > Проведенные в нашей фирме эксперементы показали, если правильно сделать, то > программа на perl + AE также эффективна, как написанная на C, а пишется и > отлаживается быстрее. о! это уже ближе к делу! а какой методикой пользовались для оценки эффективности? по моим наблюдениям - все эти программы "делают ничего". как сравнивать эффективность программ, которые "делают ничего" - я в свое время не придумал... From pef-secure на yandex.ru Tue Feb 10 02:39:00 2015 From: pef-secure на yandex.ru (PEF Secure) Date: Tue, 10 Feb 2015 11:39 +0100 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: References: <54D9D79C.9030402@gmail.com> Message-ID: <12954902.LD5Ien2SHu@rawen> On Tuesday, February 10, 2015 14:14:03 Daniel Podolsky wrote: > асинхронный код у тебя за пару-тройку лет разработки в конфетку > превратится, ага... При правильном подходе, проблемы с кодом нет. Правда, у меня пока только опыт с POE, но я переношу это на EV с полным сохранением инфраструктуры. Определяется API бэкенда и он работает. Никакого особого хакинга. Вопрос с DB или другими блокирующимися процессами решается "оффлоадом" тяжёлых обработчиков. -- PEF Developer From sergle.ua на gmail.com Tue Feb 10 02:43:59 2015 From: sergle.ua на gmail.com (Sergey Leschenko) Date: Tue, 10 Feb 2015 12:43:59 +0200 Subject: [Moscow.pm] =?utf-8?b?0KLQtdC80Ysg0LTQu9GPINC00L7QutC70LDQtNC+?= =?utf-8?b?0LI=?= In-Reply-To: References: <19923524.20150208131028@softsearch.ru> <1448301.L8bfyLT0Ar@rawen> <54D8657A.2050202@rambler.ru> <54D87696.6090201@rambler.ru> Message-ID: 2015-02-10 4:27 GMT+02:00 Alex Chistyakov : > Так вот, те, кто работают с базами данных, знают слова вроде "оптимистичная блокировка", Это утверждение слишком оптимистично, к сожалению. -- Sergey From ilvin на mail.ru Tue Feb 10 02:48:55 2015 From: ilvin на mail.ru (=?UTF-8?B?0JjQu9GM0Y8g0JLQuNC90L7QutGD0YDQvtCy?=) Date: Tue, 10 Feb 2015 13:48:55 +0300 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= In-Reply-To: <1423562937.522290480@f30.i.mail.ru> References: <19510226719.20150209161121@softsearch.ru> <1423562937.522290480@f30.i.mail.ru> Message-ID: <1423565335.303272506@f105.i.mail.ru> Здравствуйте! По поводу производительности Perl... Привожу свой тестовый пример на Perl вместе с контрольным вариантом на C++. CPU0: AMD Opteron 23xx (Gen 3 Class Opteron) stepping 01 perl -e 'use Benchmark qw/ timethese /; use List::Util qw/ sum /; use integer; my @arr = 0 .. 10_000_000 - 1; timethese(10, { FUNC => sub { sum @arr } });' Benchmark: timing 10 iterations of FUNC...       FUNC:  2 wallclock secs ( 1.75 usr +  0.01 sys =  1.76 CPU) @  5.68/s (n=10) Т.е. 1/5.68 = 176ms На том же процессоре такой код: #include #include #include #define ARR_DIM 10000000 #define COUNT 100 using namespace std; int main(void) {     __uint32_t * arr = new __uint32_t[ARR_DIM];     __uint64_t sum;     int i;     for( i = ARR_DIM-1; i >= 0; i--) {         arr[i] = i;     }     clock_t start = clock();     for (int count = COUNT; count > 0; count--) {         sum = 0;         for( i = ARR_DIM - 1; i >= 0; i--) {             sum+=arr[i];         }     }     clock_t end = clock();     cout << "Time:(" << ((double)end-start)/(COUNT*CLOCKS_PER_SEC)*1000 << ")ms . Sum: " << sum << endl;     delete arr;     return 0; } g++ -O3 -march=native test.c -o test.exe && ./test.exe Time:(13.4)ms . Sum: 49999995000000 Т.е. на данной конкретной задаче Perl в 13 раз медленнее C++. С почтением,   Илья Винокуров. Вторник, 10 февраля 2015, 13:08 +03:00 от Илья Винокуров : >Марку процессора укажите пожалуйста... :) > >С почтением, >  Илья Винокуров. > > >Вторник, 10 февраля 2015, 5:22 +03:00 от Mons Anderson : >>int main ( int argc, char **argv) { >>        long int S = atoi(argv[ 1 ]); >>        long int i,z; >>        clock_t start = clock(); >>        long int sum = 0 ; >>        for (z = 0 ; z < 1000 ; z++ ){ >>                sum = 0 ; >>                for (i= 0 ;i < S - S % 16 ; i+= 16 ) { >>                        sum += i   + i+ 1 + i+ 2   + i+ 3   + i+ 4   + i+ 5   + i+ 6  + i+ 7 >>                            +  i+ 8 + i+ 9 + i+ 10 + i+ 11 + i+ 12 + i+ 13 + i+ 14 + i+ 15 >>                        ; >>                } >>                for (i; i < S; i++ ) { >>                        sum += i; >>                } >>        } >>        clock_t end = clock(); >>        printf( " %lu ( %0.8f ) \n " ,sum,(( double )end-start)/ 1e6 /z); >>} >> >> >>1.5 ms >> >>gcc --std=c99 -O3 -march=native >> >> >>--  >>Mons Anderson >>< mons на cpan.org > >> >> >>>On 9 февр. 2015 г., at 16:11, Михаил Монашёв < postmaster на softsearch.ru > wrote: >>>Здравствуйте, Mons. >>> >>>>Народ, я не осилил дочитать это всё до конца. >>>>А давайте-ка соберёмся и померяемся. >>>>Не в плане теории, а в плане конкретных чисел >>>>сравним разные языки, подходы и т.п. >>> >>>А  собираться  обязательно?  Можно ведь и удалённо. Я на Go пишу всего >>>месяц  и  мне было бы сложно придти и что-то нормально на нём написать >>>за малое время. Но сравнить языки было бы интересно. >>> >>>Предложу  простую  задачку,  которая  покажет,  насколько  хорошо язык >>>работает  с  памятью:  сложить  все  значения  массива,  состоящего из >>>10000000  целых чисел. Код там простой: создаём массив, заполняем его, >>>замеряем  время,  потом  в  цикле  складываем  элементы массива, снова >>>замеряем время и выдаём результат. Вот мой вариант на Go: >>>https://play.golang.org/p/iHGG3nV10L >>> >>>Тонкости:  в песочнице код съедает много процессора и время там всегда >>>одно  и  то  же, поэтому его надо сохранить в файл, например main.go и >>>потом запустить вот так: go run main.go >>>Скомпилировать  в исполняемый файл можно вот так: go build main.go >>>А вот так выйдет более быстрая версия: go build -gcflags="-B" main.go >>>Скачать Go можно вот тут: http://golang.org/ >>> >>>-- >>>С уважением, >>>Михаил                          mailto:postmaster на softsearch.ru >>> >>>-- >>>Moscow.pm mailing list >>>moscow-pm на pm.org | http://moscow.pm.org >> >>-- >>Moscow.pm mailing list >>moscow-pm на pm.org | http://moscow.pm.org > >-- >Moscow.pm mailing list >moscow-pm на pm.org | http://moscow.pm.org ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From postmaster на softsearch.ru Tue Feb 10 03:04:12 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 10 Feb 2015 14:04:12 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: <54D9A9F1.30408@rambler.ru> References: <19510226719.20150209161121@softsearch.ru> <1825727633.20150210092847@softsearch.ru> <54D9A9F1.30408@rambler.ru> Message-ID: <100927409.20150210140412@softsearch.ru> Здравствуйте, Анатолий. > Linux i386 >> gcc -O3 -march=native 3.c -o 3.out && ./3.out > Time:(0.00000000)ms . Sum: 49999995000000 Это из-за того, что низкая точность у clock(). > Кстати лучше считать с нуля тогда процесор может использовать prefetch Да, действительно, стало чуть быстрее. Вот доработанный вод: #include #include #include int main() { unsigned __int32 *arr; arr = (unsigned __int32 *) malloc(10000000 * sizeof(unsigned __int32)); int i,z; for( i=0; i<10000000; i++) { arr[i] = i; } clock_t start = clock(); unsigned __int64 sum; for(z = 0; z < 100; z++ ){ sum = 0; for( i=0; i<10000000; i++) { sum+=arr[i]; } } clock_t end = clock(); printf("Time:(%0.8f)ms . Sum: %llu", ((double)end-start)*1000/CLOCKS_PER_SEC/z, sum); return 0; } C:\Temp>gcc -O3 -march=native 3.c -o 3.exe C:\Temp>3.exe Time:(8.96000000)ms . Sum: 49999995000000 Мой проц: Number of cores 2 (max 2) Number of threads 2 (max 2) Name Intel Mobile Core 2 Duo T8100 Codename Penryn Specification Intel(R) Core(TM)2 Duo CPU T8100 @ 2.10GHz Package (platform ID) Socket P (478) (0x7) CPUID 6.7.6 Extended CPUID 6.17 Core Stepping M0 Technology 45 nm Core Speed 2094.6 MHz Multiplier x Bus Speed 10.5 x 199.5 MHz Rated Bus speed 798.0 MHz Stock frequency 2100 MHz Instructions sets MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, EM64T, VT-x L1 Data cache 2 x 32 KBytes, 8-way set associative, 64-byte line size L1 Instruction cache 2 x 32 KBytes, 8-way set associative, 64-byte line size L2 cache 3072 KBytes, 12-way set associative, 64-byte line size Chipset: Northbridge Intel PM965 rev. C0 Southbridge Intel 82801HBM (ICH8-ME) rev. B1 Graphic Interface PCI-Express PCI-E Link Width x16 PCI-E Max Link Width x16 Memory Type DDR2 Memory Size 4 GBytes Channels Dual, (Symmetric) Memory Frequency 332.5 MHz (3:5) CAS# latency (CL) 5.0 RAS# to CAS# delay (tRCD) 5 RAS# Precharge (tRP) 5 Cycle Time (tRAS) 15 MCHBAR I/O Base address 0x0FED14000 MCHBAR I/O Size 4096 Память: DIMM # 1 SMBus address 0x50 Memory type DDR2 Module format SO-DIMM Manufacturer (ID) Hyundai Electronics (AD000000000000000000) Size 2048 MBytes Max bandwidth PC2-5300 (333 MHz) Part number HYMP125S64CP8-Y5 Serial number 00002120 Manufacturing date Week 14/Year 08 Number of banks 2 Data width 64 bits Correction None Nominal Voltage 1.80 Volts EPP no XMP no AMP no JEDEC timings table CL-tRCD-tRP-tRAS-tRC @ frequency JEDEC #1 3.0-3-3-9-12 @ 200 MHz JEDEC #2 4.0-4-4-12-16 @ 266 MHz JEDEC #3 5.0-5-5-15-20 @ 333 MHz DIMM # 2 SMBus address 0x52 Memory type DDR2 Module format SO-DIMM Manufacturer (ID) Hyundai Electronics (AD000000000000000000) Size 2048 MBytes Max bandwidth PC2-5300 (333 MHz) Part number HYMP125S64CP8-Y5 Serial number 00001123 Manufacturing date Week 14/Year 08 Number of banks 2 Data width 64 bits Correction None Nominal Voltage 1.80 Volts EPP no XMP no AMP no JEDEC timings table CL-tRCD-tRP-tRAS-tRC @ frequency JEDEC #1 3.0-3-3-9-12 @ 200 MHz JEDEC #2 4.0-4-4-12-16 @ 266 MHz JEDEC #3 5.0-5-5-15-20 @ 333 MHz -- С уважением, Михаил mailto:postmaster на softsearch.ru From onokonem на gmail.com Tue Feb 10 03:07:05 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Tue, 10 Feb 2015 15:07:05 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: <54D9DF31.5000704@gmail.com> References: <4313772.nGeHKfApF6@rawen> <54D9D79C.9030402@gmail.com> <54D9DF31.5000704@gmail.com> Message-ID: > Но будет занимать 100М * число ядер. я правильно понял, что мы написали кода на 100M RES, и надеемся, что он будет эффективно работать в асинхронной модели? а что дает нам основания для оптимизма? по моему опыту, ситуация, когда колбеки конкурируют с евент-лупом за процессор, выглядит и ощущается как "сервер не работает!!!" или мы написали кода на 100M RES, который не ест процессор? тогда, может быть, и из синхронной версии его можно выкинуть? From ruslan.zakirov на gmail.com Tue Feb 10 03:09:04 2015 From: ruslan.zakirov на gmail.com (Ruslan Zakirov) Date: Tue, 10 Feb 2015 15:09:04 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: References: <936264802.20150208214721@softsearch.ru> <39967E84-8DCC-49E3-9121-85FDDBA25078@gmail.com> <6A76C1C0-12AC-4E28-8F29-A26967AC9FDE@gmail.com> Message-ID: 2015-02-10 12:51 GMT+03:00 Daniel Podolsky : > > Примеров много: > > * online чаты, уведомления пользователей о новых событиях > > * очереди, обработка сообщений очередей > > * большинство стриминг задач > > * .... > задача типа "прокси", да, спасибо. почему в этом ряду оказались > очереди - я не очень понимаю, ну да и хрен с ним. > > Вот какой вопрос меня мучит: почему бытует мнение, что эту задачу > эффективно решать на perl? Пусть даже и с применением AnyEvent... > У кого бытует? У меня нет такого мнения. Можно на Go, Python или даже PHP. Я сам лично, если сейчас сяду писать это дело на Go, то мне понадобится X времени для прототипа c сомнительным качеством, а за эти X времени я на Perl напишу отдельный модуль приложение который сам ставит зависимости, собирается в пакет, содержит тесты, запускается под uwsgi, код будет лаконичный, понятный через год и два, поддерживаемый... Возьмем опытного программиста на Python он сделает тоже самое в Python за X времени. Эффективность наших решений будет в рамках ТЗ, а если нет, то какие мы "опытные" если не учли возможности инструментария и решение не выдерживает требований. Если задача (ТЗ) ставит под сомнение возможности ЯП, то нужно провести тесты, опять же в Perl я проведу тесты за X времени и скажу, что да мы справимся или нет не справимся, но я за X времени не смогу оценить Go ибо не знаю всех потенциальных тонкостей и мой тестовый стенд может не учесть всех особеностей. Далее вопрос в кадрах и экспертизе. Для бизнеса возможно будет выгоднее нанять еще человека или пойти на компромис в ТЗ. Дальше пошли тонкие материи финансовых потоков.... > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > -- Best regards, Ruslan. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mialinx на gmail.com Tue Feb 10 03:28:52 2015 From: mialinx на gmail.com (Dmitry Smal) Date: Tue, 10 Feb 2015 14:28:52 +0300 Subject: [Moscow.pm] =?koi8-r?b?wdPJzsjSz87O2cogy8/EINDP2tfPzNHF1CDTyczY?= =?koi8-r?b?zs8g09zLz87PzcnU2CDSxdPV0tPZINPF0tfF0s/X?= In-Reply-To: References: <4313772.nGeHKfApF6@rawen> <54D9D79C.9030402@gmail.com> <54D9DF31.5000704@gmail.com> Message-ID: <54D9EB74.5050609@gmail.com> On 02/10/2015 02:07 PM, Daniel Podolsky wrote: >> Но будет занимать 100М * число ядер. > я правильно понял, что мы написали кода на 100M RES, и надеемся, что > он будет эффективно работать в асинхронной модели? а что дает нам > основания для оптимизма? > > по моему опыту, ситуация, когда колбеки конкурируют с евент-лупом за > процессор, выглядит и ощущается как "сервер не работает!!!" > > или мы написали кода на 100M RES, который не ест процессор? тогда, > может быть, и из синхронной версии его можно выкинуть? Нет, не правильно. 1) Объем кода в общем не мешает ему быть эффективным 2) 100Мб может быть не рукописный код, а скажем кеш шаблонизатора в памяти. From ilvin на mail.ru Tue Feb 10 02:06:59 2015 From: ilvin на mail.ru (=?UTF-8?B?0JjQu9GM0Y8g0JLQuNC90L7QutGD0YDQvtCy?=) Date: Tue, 10 Feb 2015 13:06:59 +0300 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= In-Reply-To: <54D91FFE.6040004@gmail.com> References: <19510226719.20150209161121@softsearch.ru> <54D91FFE.6040004@gmail.com> Message-ID: <1423562819.427489324@f30.i.mail.ru> Я немного по-другому посчитал: CPU0: AMD Opteron 23xx (Gen 3 Class Opteron) stepping 01 perl -e 'use Benchmark qw/ timethese /; use List::Util qw/ sum /; use integer; my @arr = 0 .. 10_000_000 - 1; timethese(10, { FUNC => sub { sum @arr } });' Benchmark: timing 10 iterations of FUNC...       FUNC:  2 wallclock secs ( 1.75 usr +  0.01 sys =  1.76 CPU) @  5.68/s (n=10) Конечно, мой вариант является троллингом, но все же... :) С почтением,   Илья Винокуров. Вторник, 10 февраля 2015, 0:00 +03:00 от vividsnow : >perl+pdl: > >~$ /usr/bin/time -f 'mem: %MKb' perl -MPDL::LiteF -MBenchmark=countit -e ' >my $s = sequence long, 1e7; >printf "time: %dms sum: %d\n", 1e3/countit(1, sub { $s->dsum })->iters, $s->dsum' > >time: 19ms sum: 49999995000000 >mem: 48516Kb > >p.s. intel core2duo t7400 > >On 02/09/2015 11:45 PM, Daniel Podolsky wrote: >> я тут подумал, и гоняю не один раз этот расчет, а 10 тысяч. исходники, >> если нужны, готов предоставить. >> >> получил вот такие результаты: >> COMMAND %CPU #TH MEM avg time >> go 100.5 2/1 122M 7ms >> go-rt 160.6 15/1 123M 2ms >> java 109.6 20/1 3008M 4ms >> groovy 112.2 20/1 1837M 5ms >> >> чет эта развлекуха мне поднадоела :) да и очевидно уже, какие шишки в лесу чьи. >> >> наблюдал ленивые вычисления в действии - забыл добавить печать суммы в >> диагностику. время на java тут же упало до нуля. >> >> скажите, коллеги, то, что никто из нас даже не подумал потестить перл >> - это из уважения к сообществу? >> >-- >Moscow.pm mailing list >moscow-pm на pm.org | http://moscow.pm.org ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From onokonem на gmail.com Tue Feb 10 03:32:15 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Tue, 10 Feb 2015 15:32:15 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: References: <936264802.20150208214721@softsearch.ru> <39967E84-8DCC-49E3-9121-85FDDBA25078@gmail.com> <6A76C1C0-12AC-4E28-8F29-A26967AC9FDE@gmail.com> Message-ID: > У кого бытует? У меня нет такого мнения. Можно на Go, Python или даже PHP. Вот-вот... "Можно" - это же и есть "эффективно", правда? "Все языки программирования одинаковые", правда? ладно, это флуд уже с моей стороны начался. From postmaster на softsearch.ru Tue Feb 10 03:36:39 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 10 Feb 2015 14:36:39 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: <54D9A9F1.30408@rambler.ru> References: <19510226719.20150209161121@softsearch.ru> <1825727633.20150210092847@softsearch.ru> <54D9A9F1.30408@rambler.ru> Message-ID: <1053838236.20150210143639@softsearch.ru> Здравствуйте, Анатолий. > Кстати лучше считать с нуля тогда процесор может использовать > prefetch Ещё в С можно как-то задать выравнивание массива. Не знаю, правда, поможет ли это, но мне кажется, что всё упирается в скорость чтения из памяти. Ещё возможно попытаться задать выравнивание для тела цикла. -- С уважением, Михаил mailto:postmaster на softsearch.ru From 0body0 на rambler.ru Tue Feb 10 03:48:33 2015 From: 0body0 на rambler.ru (=?KOI8-R?Q?=E1=CE=C1=D4=CF=CC=C9=CA_=E7=D2=C9=DB=C1=C5=D7?=) Date: Tue, 10 Feb 2015 14:48:33 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: <1053838236.20150210143639@softsearch.ru> References: <19510226719.20150209161121@softsearch.ru> <1825727633.20150210092847@softsearch.ru> <54D9A9F1.30408@rambler.ru> <1053838236.20150210143639@softsearch.ru> Message-ID: <54D9F011.6090205@rambler.ru> 10.02.2015 14:36, Михаил Монашёв пишет: > Здравствуйте, Анатолий. > >> Кстати лучше считать с нуля тогда процесор может использовать >> prefetch > Ещё в С можно как-то задать выравнивание массива. Не знаю, правда, > поможет ли это, но мне кажется, что всё упирается в скорость чтения из > памяти. Ещё возможно попытаться задать выравнивание для тела цикла. > В POSIX написано, что результат вызова malloc всегда выровнен, а всякие массивы объявленные статично компилятор выравнивает. Можно поэтому не волноваться :) Конечно, если ты сам адрес массива не посчитаешь/укажешь типа 0x...7f. From onokonem на gmail.com Tue Feb 10 03:54:13 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Tue, 10 Feb 2015 15:54:13 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: <54D9EB74.5050609@gmail.com> References: <4313772.nGeHKfApF6@rawen> <54D9D79C.9030402@gmail.com> <54D9DF31.5000704@gmail.com> <54D9EB74.5050609@gmail.com> Message-ID: > Нет, не правильно. "Не надеемся" или "не понаписали"? > 1) Объем кода в общем не мешает ему быть эффективным "Эффективно" в асинхронной модели это "быстро отдать управление обратно эвент-лупу". Объем кода мешает этому, да. > 2) 100Мб может быть не рукописный код, а скажем кеш шаблонизатора в памяти. Ну вот да. Разделяемые данные большого объема в памяти. Ради них можно начать писать асинхронный код на perl+AnyEvent, а можно уйти на другую платформу, с нормальными тредами. Я, собственно, всю дискуссию затеял ради сравнительного анализа перспективности этих подходов. From postmaster на softsearch.ru Tue Feb 10 04:17:36 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 10 Feb 2015 15:17:36 +0300 Subject: [Moscow.pm] =?koi8-r?b?9MXN2SDEzNEgxM/LzMHEz9c=?= In-Reply-To: <54D9D364.80208@rambler.ru> References: <19923524.20150208131028@softsearch.ru> <1448301.L8bfyLT0Ar@rawen> <54D8657A.2050202@rambler.ru> <54D87696.6090201@rambler.ru> <54D9A6AB.5080902@rambler.ru> <54D9C081.1040101@rambler.ru> <54D9D364.80208@rambler.ru> Message-ID: <62191627.20150210151736@softsearch.ru> Здравствуйте, Анатолий. > 3) Программы в которых несколько потоков делают одну работу просто > сложнее, чем там где туже работу делает один поток, хотя бы из-за > необходимости синхронизации. > Пример: перемножение матрицы. А какая нужна синхронизация при перемножении матриц? У каждого процесса свой кусок одной из перемножаемых матриц и по этому куску он бегает. Т.е. данные заранее поделены на равные части и не надо ничего синхронизировать. -- С уважением, Михаил mailto:postmaster на softsearch.ru From 0body0 на rambler.ru Tue Feb 10 04:20:38 2015 From: 0body0 на rambler.ru (=?KOI8-R?Q?=E1=CE=C1=D4=CF=CC=C9=CA_=E7=D2=C9=DB=C1=C5=D7?=) Date: Tue, 10 Feb 2015 15:20:38 +0300 Subject: [Moscow.pm] =?koi8-r?b?wdPJzsjSz87O2cogy8/EINDP2tfPzNHF1CDTyczY?= =?koi8-r?b?zs8g09zLz87PzcnU2CDSxdPV0tPZINPF0tfF0s/X?= In-Reply-To: References: <936264802.20150208214721@softsearch.ru> <39967E84-8DCC-49E3-9121-85FDDBA25078@gmail.com> <6A76C1C0-12AC-4E28-8F29-A26967AC9FDE@gmail.com> <54D9D74E.1020100@rambler.ru> Message-ID: <54D9F796.9080107@rambler.ru> 10.02.2015 13:37, Daniel Podolsky пишет: >> Проведенные в нашей фирме эксперементы показали, если правильно сделать, то >> программа на perl + AE также эффективна, как написанная на C, а пишется и >> отлаживается быстрее. > о! это уже ближе к делу! > > а какой методикой пользовались для оценки эффективности? Я собственно только запросы в секунду + использование памяти. И желательно 1) долбить с другой машины 2) Чтобы в фоне не было работающих процессов, 3) и на реальном железе(на виртуалке получаются немного случайные/"смазанные" результаты) Кое-кто еще меряет время на запрос, распределение, но это не ко мне. :) > > по моим наблюдениям - все эти программы "делают ничего". как > сравнивать эффективность программ, которые "делают ничего" - я в свое > время не придумал... Собственно как "ничего" --- можно fcgi протокол реализовать. В конце концов весь веб это преобразование информации из хранимой формы в HTML, где-то красивее, а где-то похуже. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From akovbovich на gmail.com Tue Feb 10 04:29:24 2015 From: akovbovich на gmail.com (Andrey Kovbovich) Date: Tue, 10 Feb 2015 16:29:24 +0400 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= In-Reply-To: <100927409.20150210140412@softsearch.ru> References: <19510226719.20150209161121@softsearch.ru> <1825727633.20150210092847@softsearch.ru> <54D9A9F1.30408@rambler.ru> <100927409.20150210140412@softsearch.ru> Message-ID: А зачем 100 раз вычислять сумму? 2015-02-10 14:04 GMT+03:00 Михаил Монашёв : > for(z = 0; z < 100; z++ ){ ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From v.perepelitsa на corp.mail.ru Tue Feb 10 04:31:34 2015 From: v.perepelitsa на corp.mail.ru (Mons Anderson) Date: Tue, 10 Feb 2015 15:31:34 +0300 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= In-Reply-To: References: <19510226719.20150209161121@softsearch.ru> <1825727633.20150210092847@softsearch.ru> <54D9A9F1.30408@rambler.ru> <100927409.20150210140412@softsearch.ru> Message-ID: <551B5D4A-332C-422B-9FE7-AFDA3009E574@corp.mail.ru> точность времени выше -- Mons Anderson > On 10 февр. 2015 г., at 15:29, Andrey Kovbovich wrote: > > А зачем 100 раз вычислять сумму? > > 2015-02-10 14:04 GMT+03:00 Михаил Монашёв >: > for(z = 0; z < 100; z++ ){ > > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From ilvin на mail.ru Tue Feb 10 04:32:52 2015 From: ilvin на mail.ru (=?UTF-8?B?0JjQu9GM0Y8g0JLQuNC90L7QutGD0YDQvtCy?=) Date: Tue, 10 Feb 2015 15:32:52 +0300 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= In-Reply-To: References: <19510226719.20150209161121@softsearch.ru> <100927409.20150210140412@softsearch.ru> Message-ID: <1423571572.769007134@f216.i.mail.ru> Код получился слишком быстрый - разрешения таймера не хватает для замера одного вычисления суммы. А вообще измерение производительности кода - это целая наука... С почтением,   Илья Винокуров. Вторник, 10 февраля 2015, 16:29 +04:00 от Andrey Kovbovich : >А зачем 100 раз вычислять сумму? > >2015-02-10 14:04 GMT+03:00 Михаил Монашёв < postmaster на softsearch.ru > : >>for(z = 0; z < 100; z++ ){ > >-- >Moscow.pm mailing list >moscow-pm на pm.org | http://moscow.pm.org ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From akovbovich на gmail.com Tue Feb 10 04:33:33 2015 From: akovbovich на gmail.com (Andrey Kovbovich) Date: Tue, 10 Feb 2015 16:33:33 +0400 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= In-Reply-To: <54D9F011.6090205@rambler.ru> References: <19510226719.20150209161121@softsearch.ru> <1825727633.20150210092847@softsearch.ru> <54D9A9F1.30408@rambler.ru> <1053838236.20150210143639@softsearch.ru> <54D9F011.6090205@rambler.ru> Message-ID: Потестил на более менее современной тачке... вариант Монса у меня сегфолтится почему-то, прогнал слегка модифицированный из пред комментов #include #include #include #include #include int main() { uint32_t *arr; arr = (uint32_t *) malloc(10000000 * sizeof(uint32_t)); int i,z; for( i=0; i<10000000; i++) { arr[i] = i; } clock_t start = clock(); uint64_t sum; for(z = 0; z < 100; z++ ){ sum = 0; for( i=0; i<10000000; i++) { sum+=arr[i]; } } clock_t end = clock(); printf("Time:(%0.8f)ms . Sum: %" PRIu64, ((double)end-start)*1000/CLOCKS_PER_SEC/z, sum); return 0; } $ cat /proc/cpuinfo model name : Intel(R) Core(TM) i7 CPU X 980 @ 3.33GHz $ gcc --std=c99 -O3 -march=native 3.c -o 3.native $ ./3.native Time:(5.20000000)ms . Sum: 49999995000000$ еще раз на скриптовом J $ ./jconsole.sh x =: i.10000000 6!:2 's =: +/x' 0.009537 s 49999995000000 9+ ms 10 февраля 2015 г., 14:48 пользователь Анатолий Гришаев <0body0 на rambler.ru> написал: > 10.02.2015 14:36, Михаил Монашёв пишет: > >> Здравствуйте, Анатолий. >> >> Кстати лучше считать с нуля тогда процесор может использовать >>> prefetch >>> >> Ещё в С можно как-то задать выравнивание массива. Не знаю, правда, >> поможет ли это, но мне кажется, что всё упирается в скорость чтения из >> памяти. Ещё возможно попытаться задать выравнивание для тела цикла. >> >> В POSIX написано, что результат вызова malloc всегда выровнен, а всякие > массивы объявленные статично компилятор выравнивает. > Можно поэтому не волноваться :) > Конечно, если ты сам адрес массива не посчитаешь/укажешь типа 0x...7f. > > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From postmaster на softsearch.ru Tue Feb 10 04:33:37 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 10 Feb 2015 15:33:37 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: <54D91FFE.6040004@gmail.com> References: <19510226719.20150209161121@softsearch.ru> <678779427.20150209163633@softsearch.ru> <1009399030.20150209165019@softsearch.ru> <1243981472.20150209221019@softsearch.ru> <1763475480.20150209225603@softsearch.ru> <54D91FFE.6040004@gmail.com> Message-ID: <435914602.20150210153337@softsearch.ru> Здравствуйте, vividsnow. > perl+pdl: > ~$ /usr/bin/time -f 'mem: %MKb' perl -MPDL::LiteF -MBenchmark=countit -e ' > my $s = sequence long, 1e7; > printf "time: %dms sum: %d\n", 1e3/countit(1, sub { $s->dsum })->iters, $s->dsum' Поставил Strawberry Perl с PDL и запустил вот этот код: #!/usr/bin/perl use strict; use warnings; use PDL::LiteF; use Benchmark; my $s = sequence long, 1e7; printf "time: %dms sum: %d\n", 1e3/Benchmark::countit(1, sub { $s->dsum })->iters, $s->dsum; C:\Temp>perl 1.pl time: 26ms sum: 49999995000000 занимает 47.7Mb оперативки и грузит только одно ядро. И второй вариант затестил: #!/usr/bin/perl use strict; use warnings; use Benchmark qw/ timethese /; use List::Util qw/ sum /; use integer; my @arr = 0 .. 10_000_000 - 1; timethese(10, { FUNC => sub { sum @arr } }); C:\Temp>perl 2.pl Benchmark: timing 10 iterations of FUNC... FUNC: 2 wallclock secs ( 2.00 usr + 0.00 sys = 2.00 CPU) @ 5.01/s (n=10) т.е. где-то 200ms Памяти занимает 641Mb и грузит только одно ядро. -- С уважением, Михаил mailto:postmaster на softsearch.ru From shafiev на gmail.com Tue Feb 10 04:37:36 2015 From: shafiev на gmail.com (Naim Sh) Date: Tue, 10 Feb 2015 16:37:36 +0400 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: References: <19510226719.20150209161121@softsearch.ru> <1825727633.20150210092847@softsearch.ru> <54D9A9F1.30408@rambler.ru> <1053838236.20150210143639@softsearch.ru> <54D9F011.6090205@rambler.ru> Message-ID: <54D9FB90.5040804@gmail.com> Коллеги , а что вы не юзаете тот же интеловский компилятор, он то именно на такой синтетики должен давать максимальные результаты. On 02/10/2015 04:33 PM, Andrey Kovbovich wrote: > > Потестил на более менее современной тачке... вариант Монса у меня > сегфолтится почему-то, прогнал слегка модифицированный из пред комментов > > #include > #include > #include > #include > #include > > int main() > { > uint32_t *arr; > arr = (uint32_t *) malloc(10000000 * sizeof(uint32_t)); > > int i,z; > for( i=0; i<10000000; i++) { > arr[i] = i; > } > > clock_t start = clock(); > uint64_t sum; > > for(z = 0; z < 100; z++ ){ > sum = 0; > for( i=0; i<10000000; i++) { > sum+=arr[i]; > } > } > > clock_t end = clock(); > printf("Time:(%0.8f)ms . Sum: %" PRIu64, > ((double)end-start)*1000/CLOCKS_PER_SEC/z, sum); > > return 0; > } > > $ cat /proc/cpuinfo > model name: Intel(R) Core(TM) i7 CPU X 980 @ 3.33GHz > > $ gcc --std=c99 -O3 -march=native 3.c -o 3.native > $ ./3.native > Time:(5.20000000)ms . Sum: 49999995000000$ > > > еще раз на скриптовом J > > $ ./jconsole.sh > x =: i.10000000 > 6!:2 's =: +/x' > 0.009537 > s > 49999995000000 > > 9+ ms > > 10 февраля 2015 г., 14:48 пользователь Анатолий Гришаев > <0body0 на rambler.ru > написал: > > 10.02.2015 14:36, Михаил Монашёв пишет: > > Здравствуйте, Анатолий. > > Кстати лучше считать с нуля тогда процесор может > использовать > prefetch > > Ещё в С можно как-то задать выравнивание массива. Не знаю, > правда, > поможет ли это, но мне кажется, что всё упирается в скорость > чтения из > памяти. Ещё возможно попытаться задать выравнивание для тела > цикла. > > В POSIX написано, что результат вызова malloc всегда выровнен, а > всякие массивы объявленные статично компилятор выравнивает. > Можно поэтому не волноваться :) > Конечно, если ты сам адрес массива не посчитаешь/укажешь типа > 0x...7f. > > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > > > > -- ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From postmaster на softsearch.ru Tue Feb 10 04:37:46 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 10 Feb 2015 15:37:46 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: References: <19510226719.20150209161121@softsearch.ru> <1825727633.20150210092847@softsearch.ru> <54D9A9F1.30408@rambler.ru> <1053838236.20150210143639@softsearch.ru> <54D9F011.6090205@rambler.ru> Message-ID: <738817086.20150210153746@softsearch.ru> Здравствуйте, Andrey. > $ gcc --std=c99 -O3 -march=native 3.c -o 3.native у меня без --std=c99 бинарник быстрее работает. -- С уважением, Михаил mailto:postmaster на softsearch.ru From ruslan.zakirov на gmail.com Tue Feb 10 04:38:53 2015 From: ruslan.zakirov на gmail.com (Ruslan Zakirov) Date: Tue, 10 Feb 2015 16:38:53 +0400 Subject: [Moscow.pm] =?utf-8?b?0LDRgdC40L3RhdGA0L7QvdC90YvQuSDQutC+0LQg?= =?utf-8?b?0L/QvtC30LLQvtC70Y/QtdGCINGB0LjQu9GM0L3QviDRgdGN0LrQvtC9?= =?utf-8?b?0L7QvNC40YLRjCDRgNC10YHRg9GA0YHRiyDRgdC10YDQstC10YDQvtCy?= In-Reply-To: References: <936264802.20150208214721@softsearch.ru> <39967E84-8DCC-49E3-9121-85FDDBA25078@gmail.com> <6A76C1C0-12AC-4E28-8F29-A26967AC9FDE@gmail.com> Message-ID: 2015-02-10 14:32 GMT+03:00 Daniel Podolsky : > > У кого бытует? У меня нет такого мнения. Можно на Go, Python или даже > PHP. > Вот-вот... "Можно" - это же и есть "эффективно", правда? "Все языки > программирования одинаковые", правда? > Эффективно в каких понятиях? Я Вас не понимаю. Все зависит от задачи. Я уверен, что есть задачи, где идеальное решение с точки зрения эффективного раходования ресурсов (IO, Memory и CPU) подойдет только один ЯП и для достижения идеала нужно будет использовать треды. Вопрос в том на сколько компромисные решения отстают от идеала по отмеченным ресурсам. Если вы хотите найти пример, то наверное нужно его синтезировать из реальной жизни. Давайте вместе синтезируем какой-то пример. Я не силен в тредах и мне будет сложно. ладно, это флуд уже с моей стороны начался. > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > -- Best regards, Ruslan. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From 0body0 на rambler.ru Tue Feb 10 04:38:09 2015 From: 0body0 на rambler.ru (=?KOI8-R?Q?=E1=CE=C1=D4=CF=CC=C9=CA_=E7=D2=C9=DB=C1=C5=D7?=) Date: Tue, 10 Feb 2015 15:38:09 +0300 Subject: [Moscow.pm] =?koi8-r?b?wdPJzsjSz87O2cogy8/EINDP2tfPzNHF1CDTyczY?= =?koi8-r?b?zs8g09zLz87PzcnU2CDSxdPV0tPZINPF0tfF0s/X?= In-Reply-To: References: <4313772.nGeHKfApF6@rawen> <54D9D79C.9030402@gmail.com> <54D9DF31.5000704@gmail.com> <54D9EB74.5050609@gmail.com> Message-ID: <54D9FBB1.8050001@rambler.ru> 10.02.2015 14:54, Daniel Podolsky пишет: >> Нет, не правильно. > "Не надеемся" или "не понаписали"? > >> 1) Объем кода в общем не мешает ему быть эффективным > "Эффективно" в асинхронной модели это "быстро отдать управление > обратно эвент-лупу". Объем кода мешает этому, да. > >> 2) 100Мб может быть не рукописный код, а скажем кеш шаблонизатора в памяти. > Ну вот да. Разделяемые данные большого объема в памяти. Ради них можно > начать писать асинхронный код на perl+AnyEvent, а можно уйти на другую > платформу, с нормальными тредами. > > Я, собственно, всю дискуссию затеял ради сравнительного анализа > перспективности этих подходов. Если коротко: 1) В начале AnyEvent совсем не шел, и я его не понимал, программы не работали, потом прошло время и количество перешло в качество и сейчас я свой код и немножко на СPAN читаю... и мне этот процесс и результат нравиться. 2) С потоками я уже давно познакомился, писал на них, отлаживал, сейчас это понимаю, но не нравится ни результат ни процесс. Ощущения такие, что получаешь твердую тройку, когда можешь написать на 5+. Т.е. ты в теме не очень разбираешься, а срочно надо что-то показать, а потом мучиться, то конечно лучше threads. А если время есть почитать и поразмыслить, то лучше попробовать для себя оба варианта --- нельзя забывать, что первый блин комом. From postmaster на softsearch.ru Tue Feb 10 04:42:28 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 10 Feb 2015 15:42:28 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: <54D9FB90.5040804@gmail.com> References: <19510226719.20150209161121@softsearch.ru> <1825727633.20150210092847@softsearch.ru> <54D9A9F1.30408@rambler.ru> <1053838236.20150210143639@softsearch.ru> <54D9F011.6090205@rambler.ru> <54D9FB90.5040804@gmail.com> Message-ID: <1002075813.20150210154228@softsearch.ru> Здравствуйте, Naim. > Коллеги , а что вы не юзаете тот же интеловский компилятор, он то > именно на такой синтетики должен давать максимальные результаты. Он разве не платный? https://software.intel.com/en-us/c-compilers -- С уважением, Михаил mailto:postmaster на softsearch.ru From 0body0 на rambler.ru Tue Feb 10 04:48:30 2015 From: 0body0 на rambler.ru (=?KOI8-R?Q?=E1=CE=C1=D4=CF=CC=C9=CA_=E7=D2=C9=DB=C1=C5=D7?=) Date: Tue, 10 Feb 2015 15:48:30 +0300 Subject: [Moscow.pm] =?koi8-r?b?9MXN2SDEzNEgxM/LzMHEz9c=?= In-Reply-To: <62191627.20150210151736@softsearch.ru> References: <19923524.20150208131028@softsearch.ru> <1448301.L8bfyLT0Ar@rawen> <54D8657A.2050202@rambler.ru> <54D87696.6090201@rambler.ru> <54D9A6AB.5080902@rambler.ru> <54D9C081.1040101@rambler.ru> <54D9D364.80208@rambler.ru> <62191627.20150210151736@softsearch.ru> Message-ID: <54D9FE1E.2070601@rambler.ru> 10.02.2015 15:17, Михаил Монашёв пишет: > Здравствуйте, Анатолий. > >> 3) Программы в которых несколько потоков делают одну работу просто >> сложнее, чем там где туже работу делает один поток, хотя бы из-за >> необходимости синхронизации. >> Пример: перемножение матрицы. > А какая нужна синхронизация при перемножении матриц? У каждого > процесса свой кусок одной из перемножаемых матриц и по этому куску он > бегает. Т.е. данные заранее поделены на равные части и не надо ничего > синхронизировать. > 1) Для того, чтобы дождаться когда все потоки закончат работу 2) В реальной задаче еще данные можно загрузить/выгрузить а это тоже можно делать параллельно 3) Нужно разбить на подзадачи чтобы числа не попадали на одну страницу кэша у разных процов(иначе кэш сбрасывается и core duo становиться i486) 4) Если разбить на слишком больше куски, то какие-то процессы начинают простаивать 5) А если слишком маленькие, то теряется время на переключение задач. 6) Матриц может быть несколько и нужно считать в определенном порядке. From me на ryvasy.net Tue Feb 10 04:53:21 2015 From: me на ryvasy.net (=?KOI8-R?Q?=F7=C1=D3=C9=CC=C9=CA_=F2=D1=C2=CF=D7?=) Date: Tue, 10 Feb 2015 15:53:21 +0300 Subject: [Moscow.pm] =?koi8-r?b?0sHCz9TVIM7Jy9TPIM7FIMndxdQ/?= In-Reply-To: References: <54D8F69D.9010805@ryvasy.net> Message-ID: <54D9FF41.7030201@ryvasy.net> Москва, офис Спасибо всем откликнувшимся, изучаем резюме On 02/09/2015 09:40 PM, Александр Фокскул wrote: > Удаленка? > > 09.02.2015 21:04 пользователь "Василий Рябов" > написал: > > Всем привет > > Мы, интернет-кинотеатр Zoomby.ru, ищем perl-разработчика. > > Кто заинтересован - присылайте резюме, пообщаемся. > -- > Василий Рябов, > me на ryvasy.net > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > > > -- Василий Рябов, me на ryvasy.net From postmaster на softsearch.ru Tue Feb 10 09:39:58 2015 From: postmaster на softsearch.ru (=?Windows-1251?B?zOj14OjrIMzu7eD4uOI=?=) Date: Tue, 10 Feb 2015 20:39:58 +0300 Subject: [Moscow.pm] =?windows-1251?b?0fDg4u3l7ejlIP/n++ru4g==?= In-Reply-To: References: <19510226719.20150209161121@softsearch.ru> Message-ID: <734502797.20150210203958@softsearch.ru> Здравствуйте, Mons. > Пожалуй в данном вопросе стоит начать с того, что CPU-арифметика > никак не сильный конёк перла. (Кстати, удивлён, что никто не > затестил CUDA) > Во вторых - CPU-intensive задачи выгоднее решать именно в синхронной > модели. Асинхрон рулит только тогда, когда переключение контекста > планировщиком OS становится дороже, чем ?ручное" управление > контекстами при помощи event-машины. > Ну и в третьих, хотелось бы спросить: какое отношение данная задача > имеет к реальной жизни? Можно затестить работу по http 1.1 с keep-alive. Например, на GET-запрос к /ping?r=12345 всегда выдавать ответ в теле "pong: 12346" , т.е. на единицу больше, чем было в параметре r. А на все остальные запросы отвечать 404-ой ошибкой. Парсить url обязательно, т.е. просто выкусывать из урла параметр r нельзя. Парсить http-заголовки тоже обязательно. Вместо эталонной реализации на С подойдёт nginx, где через return и map можно реализовать отдачу нужного тела (для уменьшения размера конфига nginx-а можно ограничить значения r от 0 до 1000). В идеале взять какой-нить современный сервер, где ядер побольше, например Core i7, с современным 64-битным Лунуксом или Фрёй и гигабитной сетевухой. И было б вообще идеально запускать запросы по сети с другого сервера. Но можно и какой-нить попроще сервер/сервера найти. Есть у кого-нить 2 ненагруженных сервера? Результаты измерять с десятой секунды, если конечно такое конечно возможно, чтобы реализации с форками успели подстроиться под нагрузку и нафоркать нужное им количество воркеров. Измерять то, что умеет измерять тестирующая тулза. Такая задача легко реализуема и больше похожа на реальную. Можно было б ещё к БД или мемкешеду ходить, но ИМХО от них будет много шума в измерениях, особенно от БД. Хотя можно мемкешедом ограничиться, например, читать 10 ключей key1-10 и когда они все прочитаны (успешно или нет, не важно), сохранять в мемкешед текущее значение r и после успешного сохранения выдавать ответ. В nginx-е чтение ключей наверное можно через ssi сделать, а запись в мемкешед только через встроенный перл, но это не чистый С тогда выйдет. -- С уважением, Михаил mailto:postmaster на softsearch.ru From onokonem на gmail.com Tue Feb 10 10:06:05 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Tue, 10 Feb 2015 22:06:05 +0400 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= In-Reply-To: <734502797.20150210203958@softsearch.ru> References: <19510226719.20150209161121@softsearch.ru> <734502797.20150210203958@softsearch.ru> Message-ID: > Можно затестить работу по http 1.1 с keep-alive. Например, на c выключенным - тоже интересно. я вписываюсь за жабу и груви. > Есть у кого-нить 2 ненагруженных сервера? есть лю у кого хецнер активный? у меня вот нет сейчас. На две недели можно брать сервера без оплаты - типа потестить. я готов насетапить там что надо за день. только надо не забыть дополнительный сетевой адабтер, и сконнектить их вместе гигабитом. > Измерять то, что умеет измерять тестирующая тулза. Или tank, или siege. Танк навороченный, умеет плавный рост-снижение нагрузки, заданное количество rps, отсылает данные на лоадсофию для графиков. siege просто долбит указанное количество запросов в указанное количество потоков, и рассказывает статистику по окончании > Такая задача легко реализуема и больше похожа на реальную. на реальную задачу для асинхронного сервера :) > Можно было б ещё к БД или мемкешеду ходить, но ИМХО от них будет много по-моему - лишнее. From aml на rulezz.ru Tue Feb 10 10:27:56 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Tue, 10 Feb 2015 18:27:56 +0000 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= References: <19510226719.20150209161121@softsearch.ru> <734502797.20150210203958@softsearch.ru> Message-ID: К бэкендам лучше ходить. Иначе это опять какая-то синтетика, которая проверяет производительность парсера HTTP, генератора ответов. On Tue Feb 10 2015 at 7:06:16 PM Daniel Podolsky wrote: > > Можно затестить работу по http 1.1 с keep-alive. Например, на > c выключенным - тоже интересно. я вписываюсь за жабу и груви. > > > Есть у кого-нить 2 ненагруженных сервера? > есть лю у кого хецнер активный? у меня вот нет сейчас. На две недели > можно брать сервера без оплаты - типа потестить. я готов насетапить > там что надо за день. > > только надо не забыть дополнительный сетевой адабтер, и сконнектить их > вместе гигабитом. > > > Измерять то, что умеет измерять тестирующая тулза. > Или tank, или siege. Танк навороченный, умеет плавный рост-снижение > нагрузки, заданное количество rps, отсылает данные на лоадсофию для > графиков. > > siege просто долбит указанное количество запросов в указанное > количество потоков, и рассказывает статистику по окончании > > > Такая задача легко реализуема и больше похожа на реальную. > на реальную задачу для асинхронного сервера :) > > > Можно было б ещё к БД или мемкешеду ходить, но ИМХО от них будет много > по-моему - лишнее. > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From postmaster на softsearch.ru Tue Feb 10 10:57:15 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 10 Feb 2015 21:57:15 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: References: <19510226719.20150209161121@softsearch.ru> <734502797.20150210203958@softsearch.ru> Message-ID: <142864133.20150210215715@softsearch.ru> Здравствуйте, Alexander. > К бэкендам лучше ходить. Иначе это опять какая-то синтетика, которая > проверяет производительность парсера HTTP, генератора ответов. А так добавится парсер ответов от мемкешеда и генератор запросов к нему. :-) Ты ещё подумай, как сильно это усложнит написание кода на разных языках. Чтобы не спорить можно 2 варианта сделать: с и без запросов к мемкешеду. Так пойдёт? -- С уважением, Михаил mailto:postmaster на softsearch.ru From aml на rulezz.ru Tue Feb 10 11:19:21 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Tue, 10 Feb 2015 19:19:21 +0000 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= References: <19510226719.20150209161121@softsearch.ru> <734502797.20150210203958@softsearch.ru> <142864133.20150210215715@softsearch.ru> Message-ID: Я предлагаю взять более-менее реалистичную задачу и погонять её под более-менее реалистичными тестами. Например: Архитектура: приложение, memcached, mysql. Задача: показывать рассказы из базы данных (каждый порядка 100 килобайт), кэшируя их в memcached (небольшого объёма). Входной урл: "/$id". Ключ в memcached: "$id". Запрос к базе: "select data from stories where id=$id". Ответ оборачивается в простенький HTML-шаблон. Все спецсимволы заменяются на HTML entities, как положено. Новые строки - на
. Результат возвращается клиенту. Как тестируем: 1. запросы по небольшому подмножеству случайных ID (чтобы всё заведомо влезало в memcached) 2. запросы по всему множеству ID (чтобы всё не влезало в memcached и приходилось дёргать базу) 3. запросы по всему множеству ID, параллельно начинаем затормаживать базу данных (lock tables write, sleep, unlock tables) Замеряется количество запросов в секунду, которые сервер смог обслужить, количество ошибок в секунду, ну и latency. Этот тест более-менее приближен к реальным условиям и проверяет разные возможности - интенсивный сетевой обмен, вычислительную работу (процессинг HTML), эффективность использования ресурсов машины. Причём в пропорциях, обычных для веб-приложений. Что скажете? Есть у кого время написать такие приложения на разных языках? On Tue Feb 10 2015 at 19:57:44 Михаил Монашёв wrote: > Здравствуйте, Alexander. > > > К бэкендам лучше ходить. Иначе это опять какая-то синтетика, которая > > проверяет производительность парсера HTTP, генератора ответов. > > А так добавится парсер ответов от мемкешеда и генератор запросов к > нему. :-) Ты ещё подумай, как сильно это усложнит написание кода на > разных языках. > > Чтобы не спорить можно 2 варианта сделать: с и без запросов к > мемкешеду. Так пойдёт? > > > -- > С уважением, > Михаил mailto:postmaster на softsearch.ru > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From postmaster на softsearch.ru Tue Feb 10 11:27:55 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 10 Feb 2015 22:27:55 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: References: <19510226719.20150209161121@softsearch.ru> <734502797.20150210203958@softsearch.ru> Message-ID: <1428443069.20150210222755@softsearch.ru> Здравствуйте, Daniel. >> Можно затестить работу по http 1.1 с keep-alive. Например, на > c выключенным - тоже интересно. Так в клиенте заголовок Connection: keep-alive не отправляй и всё. > я вписываюсь за жабу и груви. Вот первый работающий вариант на Go: https://play.golang.org/p/oxbAQSwOLS . Вот думаю, чем бы на винде его теперь потестить на производительность... -- С уважением, Михаил mailto:postmaster на softsearch.ru From akovbovich на gmail.com Tue Feb 10 12:19:38 2015 From: akovbovich на gmail.com (Andrey Kovbovich) Date: Wed, 11 Feb 2015 00:19:38 +0400 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= In-Reply-To: <1428443069.20150210222755@softsearch.ru> References: <19510226719.20150209161121@softsearch.ru> <734502797.20150210203958@softsearch.ru> <1428443069.20150210222755@softsearch.ru> Message-ID: По моему и так понятно, что в выигрыше будут языки для которых есть оптимизирующий компилятор или поддержка JIT в vm. И производительность будет плюс/минус одинаковой, с различием лишь в latency из-за особенностей мусорщика. Может что-то придумать поинтереснее? Например, небольшой гейм-сервер, я кажется видел у mozilla foundation пример похожий. 10 февраля 2015 г., 22:27 пользователь Михаил Монашёв < postmaster на softsearch.ru> написал: > Здравствуйте, Daniel. > > >> Можно затестить работу по http 1.1 с keep-alive. Например, на > > c выключенным - тоже интересно. > Так в клиенте заголовок Connection: keep-alive не отправляй и всё. > > > я вписываюсь за жабу и груви. > > Вот первый работающий вариант на Go: > https://play.golang.org/p/oxbAQSwOLS . Вот думаю, чем бы на винде его > теперь потестить на производительность... > > -- > С уважением, > Михаил mailto:postmaster на softsearch.ru > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From postmaster на softsearch.ru Tue Feb 10 12:34:22 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Tue, 10 Feb 2015 23:34:22 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: References: <19510226719.20150209161121@softsearch.ru> <734502797.20150210203958@softsearch.ru> <142864133.20150210215715@softsearch.ru> Message-ID: <782634433.20150210233422@softsearch.ru> Здравствуйте, Alexander. > Я предлагаю взять более-менее реалистичную задачу и погонять её под > более-менее реалистичными тестами. Например: > > Архитектура: приложение, memcached, mysql. > Задача: показывать рассказы из базы данных (каждый порядка 100 > килобайт), кэшируя их в memcached (небольшого объёма). > Входной урл: "/$id". > Ключ в memcached: "$id". > Запрос к базе: "select data from stories where id=$id". > Ответ оборачивается в простенький HTML-шаблон. Все спецсимволы заменяются на HTML entities, как положено. Новые строки - на
. > Результат возвращается клиенту. > > Как тестируем: > 1. запросы по небольшому подмножеству случайных ID (чтобы всё заведомо влезало в memcached) > 2. запросы по всему множеству ID (чтобы всё не влезало в memcached и приходилось дёргать базу) > 3. запросы по всему множеству ID, параллельно начинаем затормаживать базу данных (lock tables write, sleep, unlock tables) > > Замеряется количество запросов в секунду, которые сервер смог обслужить, количество ошибок в секунду, ну и latency. > > Этот тест более-менее приближен к реальным условиям и проверяет разные возможности - интенсивный сетевой обмен, вычислительную работу (процессинг HTML), эффективность использования ресурсов машины. Причём в пропорциях, обычных для веб-приложений. > > Что скажете? Есть у кого время написать такие приложения на разных языках? Писать тут не много. И более реалистичнее тест, согласен. Больше писанины с тестами и настройками тестового окружения ИМХО. Давай может входной урл вынесем в отдельную директорию, чтобы можно было легко при необходимости новые тесты добавлять? Например, в /story/ и урлы будут /story/123 соответственно. -- С уважением, Михаил mailto:postmaster на softsearch.ru From aml на rulezz.ru Tue Feb 10 12:47:39 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Tue, 10 Feb 2015 20:47:39 +0000 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= References: <19510226719.20150209161121@softsearch.ru> <734502797.20150210203958@softsearch.ru> <1428443069.20150210222755@softsearch.ru> Message-ID: > > По моему и так понятно, что в выигрыше будут языки для которых есть > оптимизирующий компилятор или поддержка JIT в vm. И производительность > будет плюс/минус одинаковой, с различием лишь в latency из-за особенностей > мусорщика. Может что-то придумать поинтереснее? Например, небольшой > гейм-сервер, я кажется видел у mozilla foundation пример похожий. > Можно и гейм-сервер. Задание придумаете? ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From postmaster на softsearch.ru Tue Feb 10 15:02:50 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Wed, 11 Feb 2015 02:02:50 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: References: <19510226719.20150209161121@softsearch.ru> <734502797.20150210203958@softsearch.ru> Message-ID: <663125714.20150211020250@softsearch.ru> Здравствуйте, Daniel. > siege просто долбит указанное количество запросов в указанное > количество потоков, и рассказывает статистику по окончании Он не крут совсем. Ест кучу процессора, а тестируемый им сервер в 30 раз меньше: PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 90195 michael 1002 27 0 1298M 124M sigwai 1 5:24 325.98% siege 90027 michael 17 20 0 86020K 12712K RUN 0 0:09 10.64% main4 -- С уважением, Михаил mailto:postmaster на softsearch.ru From onokonem на gmail.com Tue Feb 10 15:17:43 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Wed, 11 Feb 2015 03:17:43 +0400 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= In-Reply-To: <663125714.20150211020250@softsearch.ru> References: <19510226719.20150209161121@softsearch.ru> <734502797.20150210203958@softsearch.ru> <663125714.20150211020250@softsearch.ru> Message-ID: >> siege просто долбит указанное количество запросов в указанное >> количество потоков, и рассказывает статистику по окончании > Он не крут совсем. Ест кучу процессора, а тестируемый им сервер в 30 > раз меньше: думаю - ты что-то делаешь не так. я им вполне успешно многое тестил. From postmaster на softsearch.ru Tue Feb 10 15:29:03 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Wed, 11 Feb 2015 02:29:03 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: References: <19510226719.20150209161121@softsearch.ru> <734502797.20150210203958@softsearch.ru> <663125714.20150211020250@softsearch.ru> Message-ID: <1901840291.20150211022903@softsearch.ru> Здравствуйте, Daniel. >>> siege просто долбит указанное количество запросов в указанное >>> количество потоков, и рассказывает статистику по окончании >> Он не крут совсем. Ест кучу процессора, а тестируемый им сервер в 30 >> раз меньше: > думаю - ты что-то делаешь не так. я им вполне успешно многое тестил. Попробовал httperf httperf --client=0/1 --server=89.208.146.221 --port=12345 --uri=/ping?r=123 --send-buffer=1024 --recv-buffer=1024 --num-conns=50000 --num-calls=50 Нагрузка вот такая выходит: PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 51665 michael 1 103 0 18232K 3092K CPU2 2 2:11 100.00% httperf 51171 michael 11 25 0 56296K 7912K uwait 2 4:32 60.11% main4 Maximum connect burst length: 1 Total: connections 50000 requests 2500000 replies 2500000 test-duration 303.758 s Connection rate: 164.6 conn/s (6.1 ms/conn, <=1 concurrent connections) Connection time [ms]: min 3.3 avg 6.1 max 381.8 median 5.5 stddev 5.8 Connection time [ms]: connect 0.1 Connection length [replies/conn]: 50.000 Request rate: 8230.2 req/s (0.1 ms/req) Request size [B]: 77.0 Reply rate [replies/s]: min 7377.9 avg 8238.5 max 8659.6 stddev 346.6 (60 samples) Reply time [ms]: response 0.1 transfer 0.0 Reply size [B]: header 101.0 content 9.0 footer 0.0 (total 110.0) Reply status: 1xx=0 2xx=2500000 3xx=0 4xx=0 5xx=0 CPU time [s]: user 32.87 system 269.61 (user 10.8% system 88.8% total 99.6%) Net I/O: 1503.0 KB/s (12.3*10^6 bps) Errors: total 0 client-timo 0 socket-timo 0 connrefused 0 connreset 0 Errors: fd-unavail 0 addrunavail 0 ftab-full 0 other 0 Если я ничего не напутал, то гигабитной карточки будет мало. -- С уважением, Михаил mailto:postmaster на softsearch.ru From postmaster на softsearch.ru Tue Feb 10 15:42:34 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Wed, 11 Feb 2015 02:42:34 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: References: <19510226719.20150209161121@softsearch.ru> <734502797.20150210203958@softsearch.ru> <663125714.20150211020250@softsearch.ru> Message-ID: <744013881.20150211024234@softsearch.ru> Здравствуйте, Daniel. Вы писали 11 февраля 2015 г., 2:17:43: >>> siege просто долбит указанное количество запросов в указанное >>> количество потоков, и рассказывает статистику по окончании >> Он не крут совсем. Ест кучу процессора, а тестируемый им сервер в 30 >> раз меньше: > думаю - ты что-то делаешь не так. я им вполне успешно многое тестил. Вот это стресс-лоадер первый оказался быстрее демона: 51171 michael 17 31 0 90632K 17764K CPU4 4 14:01 162.21% main4 52312 michael 1 52 0 18508K 3468K select 2 1:16 89.70% http_load >http_load -parallel 1000 -seconds 120 1 1125620 fetches, 1000 max parallel, 1.01306e+07 bytes, in 120 seconds 9 mean bytes/connection 9380.15 fetches/sec, 84421.3 bytes/sec msecs/connect: 29.5105 mean, 3032.59 max, 0.083 min msecs/first-response: 59.6158 mean, 331.582 max, 0.46 min HTTP response codes: code 200 -- 1125620 -- С уважением, Михаил mailto:postmaster на softsearch.ru From ilvin на mail.ru Tue Feb 10 12:47:05 2015 From: ilvin на mail.ru (=?UTF-8?B?0JjQu9GM0Y8g0JLQuNC90L7QutGD0YDQvtCy?=) Date: Tue, 10 Feb 2015 23:47:05 +0300 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= In-Reply-To: References: <19510226719.20150209161121@softsearch.ru> Message-ID: <1423601225.349596975@f359.i.mail.ru> Все давно уже сделано... http://www.techempower.com/benchmarks/#section=data-r9&hw=i7&test=query С почтением,   Илья Винокуров Вторник, 10 февраля 2015, 19:19 UTC от Alexander Lourier : >Я предлагаю взять более-менее реалистичную задачу и погонять её под более-менее реалистичными тестами. Например: > >Архитектура: приложение, memcached, mysql. >Задача: показывать рассказы из базы данных (каждый порядка 100 килобайт), кэшируя их в memcached (небольшого объёма). >Входной урл: "/$id". >Ключ в memcached: "$id". >Запрос к базе: "select data from stories where id=$id". >Ответ оборачивается в простенький HTML-шаблон. Все спецсимволы заменяются на HTML entities, как положено. Новые строки - на
. >Результат возвращается клиенту. > >Как тестируем: >1. запросы по небольшому подмножеству случайных ID (чтобы всё заведомо влезало в memcached) >2. запросы по всему множеству ID (чтобы всё не влезало в memcached и приходилось дёргать базу) >3. запросы по всему множеству ID, параллельно начинаем затормаживать базу данных (lock tables write, sleep, unlock tables) > >Замеряется количество запросов в секунду, которые сервер смог обслужить, количество ошибок в секунду, ну и latency. > >Этот тест более-менее приближен к реальным условиям и проверяет разные возможности - интенсивный сетевой обмен, вычислительную работу (процессинг HTML), эффективность использования ресурсов машины. Причём в пропорциях, обычных для веб-приложений. > >Что скажете? Есть у кого время написать такие приложения на разных языках? > > > >On Tue Feb 10 2015 at 19:57:44 Михаил Монашёв < postmaster на softsearch.ru > wrote: >>Здравствуйте, Alexander. >> >>> К бэкендам лучше ходить. Иначе это опять какая-то синтетика, которая >>> проверяет производительность парсера HTTP, генератора ответов. >> >>А  так  добавится  парсер  ответов от мемкешеда и генератор запросов к >>нему.  :-)  Ты  ещё подумай, как сильно это усложнит написание кода на >>разных языках. >> >>Чтобы  не  спорить  можно  2  варианта  сделать:  с  и  без запросов к >>мемкешеду. Так пойдёт? >> >> >>-- >>С уважением, >> Михаил                          mailto: postmaster на softsearch. ru >> >>-- >>Moscow.pm mailing list >>moscow-pm на pm.org | http://moscow.pm.org >-- >Moscow.pm mailing list >moscow-pm на pm.org | http://moscow.pm.org ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From postmaster на softsearch.ru Wed Feb 11 11:18:27 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Wed, 11 Feb 2015 22:18:27 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: References: <19510226719.20150209161121@softsearch.ru> <734502797.20150210203958@softsearch.ru> <142864133.20150210215715@softsearch.ru> Message-ID: <828039509.20150211221827@softsearch.ru> Здравствуйте, Alexander. > Я предлагаю взять более-менее реалистичную задачу и погонять её под > более-менее реалистичными тестами. Например: > > Архитектура: приложение, memcached, mysql. > Задача: показывать рассказы из базы данных (каждый порядка 100 > килобайт), кэшируя их в memcached (небольшого объёма). > Входной урл: "/$id". > Ключ в memcached: "$id". > Запрос к базе: "select data from stories where id=$id". > Ответ оборачивается в простенький HTML-шаблон. Все спецсимволы > заменяются на HTML entities, как положено. Новые строки - на
. > Результат возвращается клиенту. > > Как тестируем: > 1. запросы по небольшому подмножеству случайных ID (чтобы всё > заведомо влезало в memcached) > 2. запросы по всему множеству ID (чтобы всё не влезало в memcached и > приходилось дёргать базу) > 3. запросы по всему множеству ID, параллельно начинаем затормаживать > базу данных (lock tables write, sleep, unlock tables) > > Замеряется количество запросов в секунду, которые сервер смог > обслужить, количество ошибок в секунду, ну и latency. > > Этот тест более-менее приближен к реальным условиям и проверяет > разные возможности - интенсивный сетевой обмен, вычислительную > работу (процессинг HTML), эффективность использования ресурсов > машины. Причём в пропорциях, обычных для веб-приложений. > > Что скажете? Есть у кого время написать такие приложения на разных > языках? Тестирую сейчас твою задачу. Надо под memcached отдельный сервер, а то он много процессора кушает. У меня их 6 шт. и каждый по 25% процессора потребляет. И под БД тоже наверное не помешает, если данных будет так много, что перестанет в мемкешед влезать, то БД станет узким местом. Хотя с другой стороны можно всё на один сервер засунуть и пусть там демон, memcached и mysql вместе живут, так в реальности часто и бывает, но тогда все быстрые демоны покажут одинаковый результат. И хорошо бы где-то иметь общий для всех дамп БД, чтобы на нём можно было тестить. -- С уважением, Михаил mailto:postmaster на softsearch.ru From aml на rulezz.ru Wed Feb 11 14:33:45 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Wed, 11 Feb 2015 22:33:45 +0000 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= References: <19510226719.20150209161121@softsearch.ru> <734502797.20150210203958@softsearch.ru> <142864133.20150210215715@softsearch.ru> <828039509.20150211221827@softsearch.ru> Message-ID: Илья Винокуров ссылку дал на сайт, где тесты разных платформ делают. У них вся тестовая среда на github выложена. Мне кажется, того, что там есть, вполне достаточно. On Wed Feb 11 2015 at 20:18:44 Михаил Монашёв wrote: > Здравствуйте, Alexander. > > > Я предлагаю взять более-менее реалистичную задачу и погонять её под > > более-менее реалистичными тестами. Например: > > > > Архитектура: приложение, memcached, mysql. > > Задача: показывать рассказы из базы данных (каждый порядка 100 > > килобайт), кэшируя их в memcached (небольшого объёма). > > Входной урл: "/$id". > > Ключ в memcached: "$id". > > Запрос к базе: "select data from stories where id=$id". > > Ответ оборачивается в простенький HTML-шаблон. Все спецсимволы > > заменяются на HTML entities, как положено. Новые строки - на
. > > Результат возвращается клиенту. > > > > Как тестируем: > > 1. запросы по небольшому подмножеству случайных ID (чтобы всё > > заведомо влезало в memcached) > > 2. запросы по всему множеству ID (чтобы всё не влезало в memcached и > > приходилось дёргать базу) > > 3. запросы по всему множеству ID, параллельно начинаем затормаживать > > базу данных (lock tables write, sleep, unlock tables) > > > > Замеряется количество запросов в секунду, которые сервер смог > > обслужить, количество ошибок в секунду, ну и latency. > > > > Этот тест более-менее приближен к реальным условиям и проверяет > > разные возможности - интенсивный сетевой обмен, вычислительную > > работу (процессинг HTML), эффективность использования ресурсов > > машины. Причём в пропорциях, обычных для веб-приложений. > > > > Что скажете? Есть у кого время написать такие приложения на разных > > языках? > > Тестирую сейчас твою задачу. Надо под memcached отдельный сервер, а то > он много процессора кушает. У меня их 6 шт. и каждый по 25% процессора > потребляет. И под БД тоже наверное не помешает, если данных будет так > много, что перестанет в мемкешед влезать, то БД станет узким местом. > Хотя с другой стороны можно всё на один сервер засунуть и пусть там > демон, memcached и mysql вместе живут, так в реальности часто и > бывает, но тогда все быстрые демоны покажут одинаковый результат. > > И хорошо бы где-то иметь общий для всех дамп БД, чтобы на нём можно > было тестить. > > -- > С уважением, > Михаил mailto:postmaster на softsearch.ru > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mialinx на gmail.com Thu Feb 12 00:22:47 2015 From: mialinx на gmail.com (Dmitry Smal) Date: Thu, 12 Feb 2015 11:22:47 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: References: <19510226719.20150209161121@softsearch.ru> <734502797.20150210203958@softsearch.ru> <142864133.20150210215715@softsearch.ru> <828039509.20150211221827@softsearch.ru> Message-ID: <54DC62D7.6080401@gmail.com> Там perl (+plack) обгоняет Go. Что слегка не реалистично. On 02/12/2015 01:33 AM, Alexander Lourier wrote: > Илья Винокуров ссылку дал на сайт, где тесты разных платформ делают. У > них вся тестовая среда на github выложена. Мне кажется, того, что там > есть, вполне достаточно. > > On Wed Feb 11 2015 at 20:18:44 Михаил Монашёв > > wrote: > > Здравствуйте, Alexander. > > > Я предлагаю взять более-менее реалистичную задачу и погонять её под > > более-менее реалистичными тестами. Например: > > > > Архитектура: приложение, memcached, mysql. > > Задача: показывать рассказы из базы данных (каждый порядка 100 > > килобайт), кэшируя их в memcached (небольшого объёма). > > Входной урл: "/$id". > > Ключ в memcached: "$id". > > Запрос к базе: "select data from stories where id=$id". > > Ответ оборачивается в простенький HTML-шаблон. Все спецсимволы > > заменяются на HTML entities, как положено. Новые строки - на
. > > Результат возвращается клиенту. > > > > Как тестируем: > > 1. запросы по небольшому подмножеству случайных ID (чтобы всё > > заведомо влезало в memcached) > > 2. запросы по всему множеству ID (чтобы всё не влезало в memcached и > > приходилось дёргать базу) > > 3. запросы по всему множеству ID, параллельно начинаем затормаживать > > базу данных (lock tables write, sleep, unlock tables) > > > > Замеряется количество запросов в секунду, которые сервер смог > > обслужить, количество ошибок в секунду, ну и latency. > > > > Этот тест более-менее приближен к реальным условиям и проверяет > > разные возможности - интенсивный сетевой обмен, вычислительную > > работу (процессинг HTML), эффективность использования ресурсов > > машины. Причём в пропорциях, обычных для веб-приложений. > > > > Что скажете? Есть у кого время написать такие приложения на разных > > языках? > > Тестирую сейчас твою задачу. Надо под memcached отдельный сервер, а то > он много процессора кушает. У меня их 6 шт. и каждый по 25% процессора > потребляет. И под БД тоже наверное не помешает, если данных будет так > много, что перестанет в мемкешед влезать, то БД станет узким местом. > Хотя с другой стороны можно всё на один сервер засунуть и пусть там > демон, memcached и mysql вместе живут, так в реальности часто и > бывает, но тогда все быстрые демоны покажут одинаковый результат. > > И хорошо бы где-то иметь общий для всех дамп БД, чтобы на нём можно > было тестить. > > -- > С уважением, > Михаил mailto:postmaster на softsearch.ru > > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > > > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From eugene.toropov на gmail.com Thu Feb 12 00:28:48 2015 From: eugene.toropov на gmail.com (Eugene Toropov) Date: Thu, 12 Feb 2015 11:28:48 +0300 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= In-Reply-To: <54DC62D7.6080401@gmail.com> References: <19510226719.20150209161121@softsearch.ru> <734502797.20150210203958@softsearch.ru> <142864133.20150210215715@softsearch.ru> <828039509.20150211221827@softsearch.ru> <54DC62D7.6080401@gmail.com> Message-ID: Не нашел такого. Скрин? > On Feb 12, 2015, at 11:22 AM, Dmitry Smal wrote: > > Там perl (+plack) обгоняет Go. > Что слегка не реалистично. > > On 02/12/2015 01:33 AM, Alexander Lourier wrote: >> Илья Винокуров ссылку дал на сайт, где тесты разных платформ делают. У них вся тестовая среда на github выложена. Мне кажется, того, что там есть, вполне достаточно. >> >> On Wed Feb 11 2015 at 20:18:44 Михаил Монашёв > wrote: >> Здравствуйте, Alexander. >> >> > Я предлагаю взять более-менее реалистичную задачу и погонять её под >> > более-менее реалистичными тестами. Например: >> > >> > Архитектура: приложение, memcached, mysql. >> > Задача: показывать рассказы из базы данных (каждый порядка 100 >> > килобайт), кэшируя их в memcached (небольшого объёма). >> > Входной урл: "/$id". >> > Ключ в memcached: "$id". >> > Запрос к базе: "select data from stories where id=$id". >> > Ответ оборачивается в простенький HTML-шаблон. Все спецсимволы >> > заменяются на HTML entities, как положено. Новые строки - на
. >> > Результат возвращается клиенту. >> > >> > Как тестируем: >> > 1. запросы по небольшому подмножеству случайных ID (чтобы всё >> > заведомо влезало в memcached) >> > 2. запросы по всему множеству ID (чтобы всё не влезало в memcached и >> > приходилось дёргать базу) >> > 3. запросы по всему множеству ID, параллельно начинаем затормаживать >> > базу данных (lock tables write, sleep, unlock tables) >> > >> > Замеряется количество запросов в секунду, которые сервер смог >> > обслужить, количество ошибок в секунду, ну и latency. >> > >> > Этот тест более-менее приближен к реальным условиям и проверяет >> > разные возможности - интенсивный сетевой обмен, вычислительную >> > работу (процессинг HTML), эффективность использования ресурсов >> > машины. Причём в пропорциях, обычных для веб-приложений. >> > >> > Что скажете? Есть у кого время написать такие приложения на разных >> > языках? >> >> Тестирую сейчас твою задачу. Надо под memcached отдельный сервер, а то >> он много процессора кушает. У меня их 6 шт. и каждый по 25% процессора >> потребляет. И под БД тоже наверное не помешает, если данных будет так >> много, что перестанет в мемкешед влезать, то БД станет узким местом. >> Хотя с другой стороны можно всё на один сервер засунуть и пусть там >> демон, memcached и mysql вместе живут, так в реальности часто и >> бывает, но тогда все быстрые демоны покажут одинаковый результат. >> >> И хорошо бы где-то иметь общий для всех дамп БД, чтобы на нём можно >> было тестить. >> >> -- >> С уважением, >> Михаил mailto:postmaster на softsearch.ru >> >> -- >> Moscow.pm mailing list >> moscow-pm на pm.org | http://moscow.pm.org >> >> > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From 0body0 на rambler.ru Thu Feb 12 00:37:58 2015 From: 0body0 на rambler.ru (=?KOI8-R?Q?=E1=CE=C1=D4=CF=CC=C9=CA_=E7=D2=C9=DB=C1=C5=D7?=) Date: Thu, 12 Feb 2015 11:37:58 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: <54DC62D7.6080401@gmail.com> References: <19510226719.20150209161121@softsearch.ru> <734502797.20150210203958@softsearch.ru> <142864133.20150210215715@softsearch.ru> <828039509.20150211221827@softsearch.ru> <54DC62D7.6080401@gmail.com> Message-ID: <54DC6666.4090208@rambler.ru> 12.02.2015 11:22, Dmitry Smal пишет: > Там perl (+plack) обгоняет Go. > Что слегка не реалистично. > А почему не реалистично сравнивать надо соответственно Например там Go обгоняет mojolicious, это треды, а plack это асинхронщина. Что доказывает, что язык на быстродействие оказывает минимальное влияние. P.S. Plack там идет под kelp-raw. > On 02/12/2015 01:33 AM, Alexander Lourier wrote: >> Илья Винокуров ссылку дал на сайт, где тесты разных платформ делают. >> У них вся тестовая среда на github выложена. Мне кажется, того, что >> там есть, вполне достаточно. >> >> On Wed Feb 11 2015 at 20:18:44 Михаил Монашёв >> > wrote: >> >> Здравствуйте, Alexander. >> >> > Я предлагаю взять более-менее реалистичную задачу и погонять >> её под >> > более-менее реалистичными тестами. Например: >> > >> > Архитектура: приложение, memcached, mysql. >> > Задача: показывать рассказы из базы данных (каждый порядка 100 >> > килобайт), кэшируя их в memcached (небольшого объёма). >> > Входной урл: "/$id". >> > Ключ в memcached: "$id". >> > Запрос к базе: "select data from stories where id=$id". >> > Ответ оборачивается в простенький HTML-шаблон. Все спецсимволы >> > заменяются на HTML entities, как положено. Новые строки - на
. >> > Результат возвращается клиенту. >> > >> > Как тестируем: >> > 1. запросы по небольшому подмножеству случайных ID (чтобы всё >> > заведомо влезало в memcached) >> > 2. запросы по всему множеству ID (чтобы всё не влезало в >> memcached и >> > приходилось дёргать базу) >> > 3. запросы по всему множеству ID, параллельно начинаем >> затормаживать >> > базу данных (lock tables write, sleep, unlock tables) >> > >> > Замеряется количество запросов в секунду, которые сервер смог >> > обслужить, количество ошибок в секунду, ну и latency. >> > >> > Этот тест более-менее приближен к реальным условиям и >> проверяет >> > разные возможности - интенсивный сетевой обмен, вычислительную >> > работу (процессинг HTML), эффективность использования ресурсов >> > машины. Причём в пропорциях, обычных для веб-приложений. >> > >> > Что скажете? Есть у кого время написать такие приложения на >> разных >> > языках? >> >> Тестирую сейчас твою задачу. Надо под memcached отдельный сервер, >> а то >> он много процессора кушает. У меня их 6 шт. и каждый по 25% >> процессора >> потребляет. И под БД тоже наверное не помешает, если данных >> будет так >> много, что перестанет в мемкешед влезать, то БД станет узким >> местом. >> Хотя с другой стороны можно всё на один сервер засунуть и >> пусть там >> демон, memcached и mysql вместе живут, так в реальности >> часто и >> бывает, но тогда все быстрые демоны покажут одинаковый результат. >> >> И хорошо бы где-то иметь общий для всех дамп БД, чтобы на нём можно >> было тестить. >> >> -- >> С уважением, >> Михаил mailto:postmaster на softsearch.ru >> >> >> -- >> Moscow.pm mailing list >> moscow-pm на pm.org | http://moscow.pm.org >> >> >> > > > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From onokonem на gmail.com Thu Feb 12 01:00:43 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Thu, 12 Feb 2015 13:00:43 +0400 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= In-Reply-To: <54DC6666.4090208@rambler.ru> References: <19510226719.20150209161121@softsearch.ru> <734502797.20150210203958@softsearch.ru> <142864133.20150210215715@softsearch.ru> <828039509.20150211221827@softsearch.ru> <54DC62D7.6080401@gmail.com> <54DC6666.4090208@rambler.ru> Message-ID: > А почему не реалистично сравнивать надо соответственно потому, что противоречит всему личному опыту > Например там Go обгоняет mojolicious, это треды, а plack это асинхронщина. и? > Что доказывает, что язык на быстродействие оказывает минимальное влияние. а что Вы называете "языком"? vm, на которой программа исполняется - вот что оказывает максимальное влияние. можно ли vm отделить от языка? (jvm -можно) From mialinx на gmail.com Thu Feb 12 01:07:33 2015 From: mialinx на gmail.com (Dmitry Smal) Date: Thu, 12 Feb 2015 12:07:33 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: <54DC6666.4090208@rambler.ru> References: <19510226719.20150209161121@softsearch.ru> <734502797.20150210203958@softsearch.ru> <142864133.20150210215715@softsearch.ru> <828039509.20150211221827@softsearch.ru> <54DC62D7.6080401@gmail.com> <54DC6666.4090208@rambler.ru> Message-ID: <54DC6D55.4080802@gmail.com> Потому что Go быстрее Perl. Внутри работает тотже epoll, поэтому Go так же асинхронный. Если по тестам получилось медленнее - значит в Go просто отрабатывает больше кода (тесты не эквиваленты). On 02/12/2015 11:37 AM, Анатолий Гришаев wrote: > 12.02.2015 11:22, Dmitry Smal пишет: >> Там perl (+plack) обгоняет Go. >> Что слегка не реалистично. >> > А почему не реалистично сравнивать надо соответственно > Например там Go обгоняет mojolicious, это треды, а plack это > асинхронщина. > Что доказывает, что язык на быстродействие оказывает минимальное влияние. > > P.S. Plack там идет под kelp-raw. > > > >> On 02/12/2015 01:33 AM, Alexander Lourier wrote: >>> Илья Винокуров ссылку дал на сайт, где тесты разных платформ делают. >>> У них вся тестовая среда на github выложена. Мне кажется, того, что >>> там есть, вполне достаточно. >>> >>> On Wed Feb 11 2015 at 20:18:44 Михаил Монашёв >>> > wrote: >>> >>> Здравствуйте, Alexander. >>> >>> > Я предлагаю взять более-менее реалистичную задачу и погонять >>> её под >>> > более-менее реалистичными тестами. Например: >>> > >>> > Архитектура: приложение, memcached, mysql. >>> > Задача: показывать рассказы из базы данных (каждый >>> порядка 100 >>> > килобайт), кэшируя их в memcached (небольшого объёма). >>> > Входной урл: "/$id". >>> > Ключ в memcached: "$id". >>> > Запрос к базе: "select data from stories where id=$id". >>> > Ответ оборачивается в простенький HTML-шаблон. Все >>> спецсимволы >>> > заменяются на HTML entities, как положено. Новые строки - на
. >>> > Результат возвращается клиенту. >>> > >>> > Как тестируем: >>> > 1. запросы по небольшому подмножеству случайных ID >>> (чтобы всё >>> > заведомо влезало в memcached) >>> > 2. запросы по всему множеству ID (чтобы всё не влезало в >>> memcached и >>> > приходилось дёргать базу) >>> > 3. запросы по всему множеству ID, параллельно начинаем >>> затормаживать >>> > базу данных (lock tables write, sleep, unlock tables) >>> > >>> > Замеряется количество запросов в секунду, которые сервер >>> смог >>> > обслужить, количество ошибок в секунду, ну и latency. >>> > >>> > Этот тест более-менее приближен к реальным условиям и >>> проверяет >>> > разные возможности - интенсивный сетевой обмен, >>> вычислительную >>> > работу (процессинг HTML), эффективность использования >>> ресурсов >>> > машины. Причём в пропорциях, обычных для веб-приложений. >>> > >>> > Что скажете? Есть у кого время написать такие приложения на >>> разных >>> > языках? >>> >>> Тестирую сейчас твою задачу. Надо под memcached отдельный >>> сервер, а то >>> он много процессора кушает. У меня их 6 шт. и каждый по 25% >>> процессора >>> потребляет. И под БД тоже наверное не помешает, если данных >>> будет так >>> много, что перестанет в мемкешед влезать, то БД станет узким >>> местом. >>> Хотя с другой стороны можно всё на один сервер засунуть и >>> пусть там >>> демон, memcached и mysql вместе живут, так в реальности >>> часто и >>> бывает, но тогда все быстрые демоны покажут одинаковый результат. >>> >>> И хорошо бы где-то иметь общий для всех дамп БД, чтобы на нём можно >>> было тестить. >>> >>> -- >>> С уважением, >>> Михаил mailto:postmaster на softsearch.ru >>> >>> >>> -- >>> Moscow.pm mailing list >>> moscow-pm на pm.org | http://moscow.pm.org >>> >>> >>> >> >> >> > > > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From postmaster на softsearch.ru Thu Feb 12 01:18:47 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Thu, 12 Feb 2015 12:18:47 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: <54DC6D55.4080802@gmail.com> References: <19510226719.20150209161121@softsearch.ru> <734502797.20150210203958@softsearch.ru> <142864133.20150210215715@softsearch.ru> <828039509.20150211221827@softsearch.ru> <54DC62D7.6080401@gmail.com> <54DC6666.4090208@rambler.ru> <54DC6D55.4080802@gmail.com> Message-ID: <394695122.20150212121847@softsearch.ru> Здравствуйте. Ну что опять спорить, кто быстрее, почему, что эффективнее. Напишите код теста и сравним, делов то. -- С уважением, Михаил mailto:postmaster на softsearch.ru From eugene.toropov на gmail.com Thu Feb 12 01:23:54 2015 From: eugene.toropov на gmail.com (Eugene Toropov) Date: Thu, 12 Feb 2015 12:23:54 +0300 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= In-Reply-To: <54DC6D55.4080802@gmail.com> References: <19510226719.20150209161121@softsearch.ru> <734502797.20150210203958@softsearch.ru> <142864133.20150210215715@softsearch.ru> <828039509.20150211221827@softsearch.ru> <54DC62D7.6080401@gmail.com> <54DC6666.4090208@rambler.ru> <54DC6D55.4080802@gmail.com> Message-ID: <625B0F2D-5346-4C26-9588-8224ADEA5372@gmail.com> http://www.techempower.com/benchmarks/#section=data-r9&hw=i7&test=query - если это JSON serialization (время которой является определяющим фактором скорее всего), то вполне допускаю, что JSON::XS может быть круче (пока). Пока нет кода тестов - сложно говорить. > On Feb 12, 2015, at 12:07 PM, Dmitry Smal wrote: > > Потому что Go быстрее Perl. Внутри работает тотже epoll, поэтому Go так же асинхронный. > Если по тестам получилось медленнее - значит в Go просто отрабатывает больше кода (тесты не эквиваленты). > > > On 02/12/2015 11:37 AM, Анатолий Гришаев wrote: >> 12.02.2015 11:22, Dmitry Smal пишет: >>> Там perl (+plack) обгоняет Go. >>> Что слегка не реалистично. >>> >> А почему не реалистично сравнивать надо соответственно >> Например там Go обгоняет mojolicious, это треды, а plack это асинхронщина. >> Что доказывает, что язык на быстродействие оказывает минимальное влияние. >> >> P.S. Plack там идет под kelp-raw. >> >> >> >>> On 02/12/2015 01:33 AM, Alexander Lourier wrote: >>>> Илья Винокуров ссылку дал на сайт, где тесты разных платформ делают. У них вся тестовая среда на github выложена. Мне кажется, того, что там есть, вполне достаточно. >>>> >>>> On Wed Feb 11 2015 at 20:18:44 Михаил Монашёв > wrote: >>>> Здравствуйте, Alexander. >>>> >>>> > Я предлагаю взять более-менее реалистичную задачу и погонять её под >>>> > более-менее реалистичными тестами. Например: >>>> > >>>> > Архитектура: приложение, memcached, mysql. >>>> > Задача: показывать рассказы из базы данных (каждый порядка 100 >>>> > килобайт), кэшируя их в memcached (небольшого объёма). >>>> > Входной урл: "/$id". >>>> > Ключ в memcached: "$id". >>>> > Запрос к базе: "select data from stories where id=$id". >>>> > Ответ оборачивается в простенький HTML-шаблон. Все спецсимволы >>>> > заменяются на HTML entities, как положено. Новые строки - на
. >>>> > Результат возвращается клиенту. >>>> > >>>> > Как тестируем: >>>> > 1. запросы по небольшому подмножеству случайных ID (чтобы всё >>>> > заведомо влезало в memcached) >>>> > 2. запросы по всему множеству ID (чтобы всё не влезало в memcached и >>>> > приходилось дёргать базу) >>>> > 3. запросы по всему множеству ID, параллельно начинаем затормаживать >>>> > базу данных (lock tables write, sleep, unlock tables) >>>> > >>>> > Замеряется количество запросов в секунду, которые сервер смог >>>> > обслужить, количество ошибок в секунду, ну и latency. >>>> > >>>> > Этот тест более-менее приближен к реальным условиям и проверяет >>>> > разные возможности - интенсивный сетевой обмен, вычислительную >>>> > работу (процессинг HTML), эффективность использования ресурсов >>>> > машины. Причём в пропорциях, обычных для веб-приложений. >>>> > >>>> > Что скажете? Есть у кого время написать такие приложения на разных >>>> > языках? >>>> >>>> Тестирую сейчас твою задачу. Надо под memcached отдельный сервер, а то >>>> он много процессора кушает. У меня их 6 шт. и каждый по 25% процессора >>>> потребляет. И под БД тоже наверное не помешает, если данных будет так >>>> много, что перестанет в мемкешед влезать, то БД станет узким местом. >>>> Хотя с другой стороны можно всё на один сервер засунуть и пусть там >>>> демон, memcached и mysql вместе живут, так в реальности часто и >>>> бывает, но тогда все быстрые демоны покажут одинаковый результат. >>>> >>>> И хорошо бы где-то иметь общий для всех дамп БД, чтобы на нём можно >>>> было тестить. >>>> >>>> -- >>>> С уважением, >>>> Михаил mailto:postmaster на softsearch.ru >>>> >>>> -- >>>> Moscow.pm mailing list >>>> moscow-pm на pm.org | http://moscow.pm.org >>>> >>>> >>> >>> >>> >> >> >> > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From 0body0 на rambler.ru Thu Feb 12 02:09:45 2015 From: 0body0 на rambler.ru (=?KOI8-R?Q?=E1=CE=C1=D4=CF=CC=C9=CA_=E7=D2=C9=DB=C1=C5=D7?=) Date: Thu, 12 Feb 2015 13:09:45 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: References: <19510226719.20150209161121@softsearch.ru> <734502797.20150210203958@softsearch.ru> <142864133.20150210215715@softsearch.ru> <828039509.20150211221827@softsearch.ru> <54DC62D7.6080401@gmail.com> <54DC6666.4090208@rambler.ru> Message-ID: <54DC7BE9.2030406@rambler.ru> 12.02.2015 12:00, Daniel Podolsky пишет: >> А почему не реалистично сравнивать надо соответственно > потому, что противоречит всему личному опыту Про какой личный опыт ты говоришь? Я говорю про свой когда некоторое время назад я поспорил с профессиональным сишником, что на задаче web server + возможно + база С и perl в плане производительности одинаково. Мы написали по программе он на С, а я на Perl. Получилось одинаково с разницей ~5-10%. Причем он не поверил и продолжил её оптимизировать и угробил кучу времени но улучшить результат сильно у него не получилось. >> Например там Go обгоняет mojolicious, это треды, а plack это асинхронщина. > и? А когда я переписал свою перловую программу на async я получил существенный прирост "попугаев" и показав своему оппоненту программу и результаты спор выиграл. > >> Что доказывает, что язык на быстродействие оказывает минимальное влияние. > а что Вы называете "языком"? А вы можете запустить java без jvm? А для чего нужно разделять язык и jvm на которой оно исполняется? Вы можете показать как запустить Perl на jvm? или java на pvm? В perl есть такая штука как XS и если в программе есть узкое место можно переписать эту маленькую часть получить большой выигрыш производительности. И это на 100% работает, а данном случае имееть более 3000 "попугаев" это явный оверкилл для подавляющего числа проэктов. А для AnyEvent этого может даже не понадобиться. Скорее всего Вы упретесь раньше в базу, в архитектуру, в сеть гораздо раньше, чем в производительность Perl как языка и его pvm. > > vm, на которой программа исполняется - вот что оказывает максимальное влияние. > > можно ли vm отделить от языка? (jvm -можно) А какой опыт? Всякие вычисления я проделываю через XS и мне необходимость в этом возникает гораздо гораздо реже, чем мне хочется. А переплюнуть XS с помощью jvm уже не получиться. А если хочеться острых ощущений в Perl есть возможность переопределить все операции на уровне расширения и это почти тривиально. Т.е. можно для перла написать свою pvm, если хочется. А вы можете написать свою jvm для java, чтобы это работало и было быстро? From eugene.toropov на gmail.com Thu Feb 12 02:23:09 2015 From: eugene.toropov на gmail.com (Eugene Toropov) Date: Thu, 12 Feb 2015 13:23:09 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: <54DC7BE9.2030406@rambler.ru> References: <19510226719.20150209161121@softsearch.ru> <734502797.20150210203958@softsearch.ru> <142864133.20150210215715@softsearch.ru> <828039509.20150211221827@softsearch.ru> <54DC62D7.6080401@gmail.com> <54DC6666.4090208@rambler.ru> <54DC7BE9.2030406@rambler.ru> Message-ID: <0AD1C019-7802-4888-BA4C-85B90715537D@gmail.com> > On Feb 12, 2015, at 1:09 PM, Анатолий Гришаев <0body0 на rambler.ru> wrote: > > 12.02.2015 12:00, Daniel Podolsky пишет: >>> А почему не реалистично сравнивать надо соответственно >> потому, что противоречит всему личному опыту > Про какой личный опыт ты говоришь? > > Я говорю про свой когда некоторое время назад я поспорил с профессиональным сишником, что на задаче web server + возможно + база > С и perl в плане производительности одинаково. > Мы написали по программе он на С, а я на Perl. > Получилось одинаково с разницей ~5-10%. > Причем он не поверил и продолжил её оптимизировать и угробил кучу времени но улучшить результат сильно у него не получилось. Я тоже не верю :) Конечно при условии, что веб-сервер делает что-нибудь полезное. Код можно посмотреть? Евгений From 0body0 на rambler.ru Thu Feb 12 02:32:41 2015 From: 0body0 на rambler.ru (=?KOI8-R?Q?=E1=CE=C1=D4=CF=CC=C9=CA_=E7=D2=C9=DB=C1=C5=D7?=) Date: Thu, 12 Feb 2015 13:32:41 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: <0AD1C019-7802-4888-BA4C-85B90715537D@gmail.com> References: <19510226719.20150209161121@softsearch.ru> <734502797.20150210203958@softsearch.ru> <142864133.20150210215715@softsearch.ru> <828039509.20150211221827@softsearch.ru> <54DC62D7.6080401@gmail.com> <54DC6666.4090208@rambler.ru> <54DC7BE9.2030406@rambler.ru> <0AD1C019-7802-4888-BA4C-85B90715537D@gmail.com> Message-ID: <54DC8149.1020207@rambler.ru> 12.02.2015 13:23, Eugene Toropov пишет: >> On Feb 12, 2015, at 1:09 PM, Анатолий Гришаев <0body0 на rambler.ru> wrote: >> >> 12.02.2015 12:00, Daniel Podolsky пишет: >>>> А почему не реалистично сравнивать надо соответственно >>> потому, что противоречит всему личному опыту >> Про какой личный опыт ты говоришь? >> >> Я говорю про свой когда некоторое время назад я поспорил с профессиональным сишником, что на задаче web server + возможно + база >> С и perl в плане производительности одинаково. >> Мы написали по программе он на С, а я на Perl. >> Получилось одинаково с разницей ~5-10%. >> Причем он не поверил и продолжил её оптимизировать и угробил кучу времени но улучшить результат сильно у него не получилось. > Я тоже не верю :) Конечно при условии, что веб-сервер делает что-нибудь полезное. Код можно посмотреть? Cишный код точно нет --- он остался у сишника. Свой код я выбросил --- я потратил на него 1-2 часа времени и было не жалко. Задача была рабочей нужно было следить за пользователеми с помощью нашего плагина, который отправлял на эту инфу и мы складывали её в базу. Также какая инфа была нужна нашему плагину, т.е. была выборка из базы и оправка ответа. > > Евгений From eugene.toropov на gmail.com Thu Feb 12 02:36:55 2015 From: eugene.toropov на gmail.com (Eugene Toropov) Date: Thu, 12 Feb 2015 13:36:55 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: <54DC8149.1020207@rambler.ru> References: <19510226719.20150209161121@softsearch.ru> <734502797.20150210203958@softsearch.ru> <142864133.20150210215715@softsearch.ru> <828039509.20150211221827@softsearch.ru> <54DC62D7.6080401@gmail.com> <54DC6666.4090208@rambler.ru> <54DC7BE9.2030406@rambler.ru> <0AD1C019-7802-4888-BA4C-85B90715537D@gmail.com> <54DC8149.1020207@rambler.ru> Message-ID: <47DD6800-F471-486D-817E-8AFE3B96B8F2@gmail.com> > > On Feb 12, 2015, at 1:32 PM, Анатолий Гришаев <0body0 на rambler.ru> wrote: > > 12.02.2015 13:23, Eugene Toropov пишет: >>> On Feb 12, 2015, at 1:09 PM, Анатолий Гришаев <0body0 на rambler.ru> wrote: >>> >>> 12.02.2015 12:00, Daniel Podolsky пишет: >>>>> А почему не реалистично сравнивать надо соответственно >>>> потому, что противоречит всему личному опыту >>> Про какой личный опыт ты говоришь? >>> >>> Я говорю про свой когда некоторое время назад я поспорил с профессиональным сишником, что на задаче web server + возможно + база >>> С и perl в плане производительности одинаково. >>> Мы написали по программе он на С, а я на Perl. >>> Получилось одинаково с разницей ~5-10%. >>> Причем он не поверил и продолжил её оптимизировать и угробил кучу времени но улучшить результат сильно у него не получилось. >> Я тоже не верю :) Конечно при условии, что веб-сервер делает что-нибудь полезное. Код можно посмотреть? > Cишный код точно нет --- он остался у сишника. Свой код я выбросил --- я потратил на него 1-2 часа времени и было не жалко. > Задача была рабочей нужно было следить за пользователеми с помощью нашего плагина, который отправлял на эту инфу и мы складывали её в базу. > Также какая инфа была нужна нашему плагину, т.е. была выборка из базы и оправка ответа. > > >> >> Евгений > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org Жаль, что не осталось, ну да ладно. Тут так и так собираются сравнивать более-менее приближенный к реальности функционал. Посмотрим,что выйдет. From 0body0 на rambler.ru Thu Feb 12 02:39:00 2015 From: 0body0 на rambler.ru (=?KOI8-R?Q?=E1=CE=C1=D4=CF=CC=C9=CA_=E7=D2=C9=DB=C1=C5=D7?=) Date: Thu, 12 Feb 2015 13:39:00 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: <0AD1C019-7802-4888-BA4C-85B90715537D@gmail.com> References: <19510226719.20150209161121@softsearch.ru> <734502797.20150210203958@softsearch.ru> <142864133.20150210215715@softsearch.ru> <828039509.20150211221827@softsearch.ru> <54DC62D7.6080401@gmail.com> <54DC6666.4090208@rambler.ru> <54DC7BE9.2030406@rambler.ru> <0AD1C019-7802-4888-BA4C-85B90715537D@gmail.com> Message-ID: <54DC82C4.1010502@rambler.ru> 12.02.2015 13:23, Eugene Toropov пишет: > > Я тоже не верю :) Конечно при условии, что веб-сервер делает что-нибудь полезное. Код можно посмотреть? У меня есть встречное предожение --- с какими нагрузками вообще живете: сколько запросов на динамику в секунду, сколько серверов это переваривают, какие базы используете и сколько, во что упираетесь? > > Евгений From mialinx на gmail.com Thu Feb 12 02:48:53 2015 From: mialinx на gmail.com (Dmitry Smal) Date: Thu, 12 Feb 2015 13:48:53 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: <54DC7BE9.2030406@rambler.ru> References: <19510226719.20150209161121@softsearch.ru> <734502797.20150210203958@softsearch.ru> <142864133.20150210215715@softsearch.ru> <828039509.20150211221827@softsearch.ru> <54DC62D7.6080401@gmail.com> <54DC6666.4090208@rambler.ru> <54DC7BE9.2030406@rambler.ru> Message-ID: <54DC8515.7070300@gmail.com> Ну если у нас perl работает на С (XS) web-сервере, использует XS драйвер для доступа в базу, не делает ничего сложно и не выделяет память.. Тогда да. Взять параметр из Plack::Request и приклеить его к SQL запросу - дают те самые 5-10%. On 02/12/2015 01:09 PM, Анатолий Гришаев wrote: > 12.02.2015 12:00, Daniel Podolsky пишет: >>> А почему не реалистично сравнивать надо соответственно >> потому, что противоречит всему личному опыту > Про какой личный опыт ты говоришь? > > Я говорю про свой когда некоторое время назад я поспорил с > профессиональным сишником, что на задаче web server + возможно + база > С и perl в плане производительности одинаково. > Мы написали по программе он на С, а я на Perl. > Получилось одинаково с разницей ~5-10%. > Причем он не поверил и продолжил её оптимизировать и угробил кучу > времени но улучшить результат сильно у него не получилось. > >>> Например там Go обгоняет mojolicious, это треды, а plack это >>> асинхронщина. >> и? > А когда я переписал свою перловую программу на async я получил > существенный прирост "попугаев" и показав своему оппоненту > программу и результаты спор выиграл. >> >>> Что доказывает, что язык на быстродействие оказывает минимальное >>> влияние. >> а что Вы называете "языком"? > > А вы можете запустить java без jvm? > > А для чего нужно разделять язык и jvm на которой оно исполняется? > Вы можете показать как запустить Perl на jvm? или java на pvm? > > В perl есть такая штука как XS и если в программе есть узкое место > можно переписать эту маленькую часть получить большой выигрыш > производительности. > > И это на 100% работает, а данном случае имееть более 3000 "попугаев" > это явный оверкилл для подавляющего числа проэктов. > А для AnyEvent этого может даже не понадобиться. > Скорее всего Вы упретесь раньше в базу, в архитектуру, в сеть гораздо > раньше, чем в производительность Perl как языка и его pvm. > >> >> vm, на которой программа исполняется - вот что оказывает максимальное >> влияние. >> >> можно ли vm отделить от языка? (jvm -можно) > > А какой опыт? Всякие вычисления я проделываю через XS и мне > необходимость в этом возникает гораздо гораздо реже, чем мне хочется. > А переплюнуть XS с помощью jvm уже не получиться. > > А если хочеться острых ощущений в Perl есть возможность переопределить > все операции на уровне расширения и это почти тривиально. > Т.е. можно для перла написать свою pvm, если хочется. > А вы можете написать свою jvm для java, чтобы это работало и было быстро? > > From eugene.toropov на gmail.com Thu Feb 12 02:54:28 2015 From: eugene.toropov на gmail.com (Eugene Toropov) Date: Thu, 12 Feb 2015 13:54:28 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: <54DC82C4.1010502@rambler.ru> References: <19510226719.20150209161121@softsearch.ru> <734502797.20150210203958@softsearch.ru> <142864133.20150210215715@softsearch.ru> <828039509.20150211221827@softsearch.ru> <54DC62D7.6080401@gmail.com> <54DC6666.4090208@rambler.ru> <54DC7BE9.2030406@rambler.ru> <0AD1C019-7802-4888-BA4C-85B90715537D@gmail.com> <54DC82C4.1010502@rambler.ru> Message-ID: <01A3ED6A-7C88-4981-BB7D-54972480509E@gmail.com> > > On Feb 12, 2015, at 1:39 PM, Анатолий Гришаев <0body0 на rambler.ru> wrote: > > 12.02.2015 13:23, Eugene Toropov пишет: >> >> Я тоже не верю :) Конечно при условии, что веб-сервер делает что-нибудь полезное. Код можно посмотреть? > > У меня есть встречное предожение --- с какими нагрузками вообще живете: > сколько запросов на динамику в секунду, сколько серверов это переваривают, какие базы используете и сколько, > во что упираетесь? >> >> Евгений > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org У нас 95% нагрузки - это поиск-агрегатор. Полтора миллиона поисков в день. Не бог весть что, но все-таки. Скоро будет больше. До 15 секунд на поиск в ожидании партнеров. Сейчас Coro/AnyEvent под мод_перлом (переписывание на чистый Coro/AnyEvent - слишком дорогое удовольствие, ибо в in-house фреймворке есть несколько глобальных переменных, на которых все держится). Переводим поиск на Go или Java (Go версия почти готова, так что сначала скорее всего на нее, там посмотрим). Остальное останется на перле. В текущей схеме - префорк + Coro/AnyEvent внутри процесса - упираемся и в процессор, и в память :) From onokonem на gmail.com Thu Feb 12 02:54:37 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Thu, 12 Feb 2015 14:54:37 +0400 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= In-Reply-To: <0AD1C019-7802-4888-BA4C-85B90715537D@gmail.com> References: <19510226719.20150209161121@softsearch.ru> <734502797.20150210203958@softsearch.ru> <142864133.20150210215715@softsearch.ru> <828039509.20150211221827@softsearch.ru> <54DC62D7.6080401@gmail.com> <54DC6666.4090208@rambler.ru> <54DC7BE9.2030406@rambler.ru> <0AD1C019-7802-4888-BA4C-85B90715537D@gmail.com> Message-ID: >> Причем он не поверил и продолжил её оптимизировать и угробил кучу времени но улучшить результат сильно у него не получилось. > Я тоже не верю :) Конечно при условии, что веб-сервер делает что-нибудь полезное. Код можно посмотреть? И боги, и смертные в одном солидарны. Две вещи сомненью они подвергают: байки рыбацкие да женскую добродетель. (С) ну ниче. вот сейчас появится референс-дизайн тестовой апликухи, что здесь обсуждается, и мы посмотрим, чьи таки шишки в лесу. From postmaster на softsearch.ru Thu Feb 12 03:23:12 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Thu, 12 Feb 2015 14:23:12 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: References: <19510226719.20150209161121@softsearch.ru> <734502797.20150210203958@softsearch.ru> <142864133.20150210215715@softsearch.ru> <828039509.20150211221827@softsearch.ru> <54DC62D7.6080401@gmail.com> <54DC6666.4090208@rambler.ru> <54DC7BE9.2030406@rambler.ru> <0AD1C019-7802-4888-BA4C-85B90715537D@gmail.com> Message-ID: <28214393.20150212142312@softsearch.ru> Здравствуйте, Daniel. >>> Причем он не поверил и продолжил её оптимизировать и угробил >>> кучу времени но улучшить результат сильно у него не получилось. >> Я тоже не верю :) Конечно при условии, что веб-сервер делает >> что-нибудь полезное. Код можно посмотреть? > И боги, и смертные в одном солидарны. Две вещи сомненью они > подвергают: байки рыбацкие да женскую добродетель. (С) > ну ниче. вот сейчас появится референс-дизайн тестовой апликухи, что > здесь обсуждается, и мы посмотрим, чьи таки шишки в лесу. Вот рабочий, но не оптимизированный по скорости вариант http://pastebin.com/YTfpfQDB Он включает в себя и ping-pong и story. Надеюсь, что Александр Лурье поможет с доработкой кода, ибо писал подобное впервые, вышло криво. Также в полтора раза ускорен ping-pong. -- С уважением, Михаил mailto:postmaster на softsearch.ru From onokonem на gmail.com Thu Feb 12 03:28:32 2015 From: onokonem на gmail.com (Daniel Podolsky) Date: Thu, 12 Feb 2015 15:28:32 +0400 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= In-Reply-To: <28214393.20150212142312@softsearch.ru> References: <19510226719.20150209161121@softsearch.ru> <734502797.20150210203958@softsearch.ru> <142864133.20150210215715@softsearch.ru> <828039509.20150211221827@softsearch.ru> <54DC62D7.6080401@gmail.com> <54DC6666.4090208@rambler.ru> <54DC7BE9.2030406@rambler.ru> <0AD1C019-7802-4888-BA4C-85B90715537D@gmail.com> <28214393.20150212142312@softsearch.ru> Message-ID: о, спасибо! вечером постараюсь сбацать на jetty. 2015-02-12 14:23 GMT+03:00 Михаил Монашёв : > Здравствуйте, Daniel. > >>>> Причем он не поверил и продолжил её оптимизировать и угробил >>>> кучу времени но улучшить результат сильно у него не получилось. >>> Я тоже не верю :) Конечно при условии, что веб-сервер делает >>> что-нибудь полезное. Код можно посмотреть? >> И боги, и смертные в одном солидарны. Две вещи сомненью они >> подвергают: байки рыбацкие да женскую добродетель. (С) > >> ну ниче. вот сейчас появится референс-дизайн тестовой апликухи, что >> здесь обсуждается, и мы посмотрим, чьи таки шишки в лесу. > > Вот рабочий, но не оптимизированный по скорости вариант http://pastebin.com/YTfpfQDB > Он включает в себя и ping-pong и story. Надеюсь, что Александр Лурье > поможет с доработкой кода, ибо писал подобное впервые, вышло криво. > Также в полтора раза ускорен ping-pong. > > -- > С уважением, > Михаил mailto:postmaster на softsearch.ru > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org From aml на rulezz.ru Thu Feb 12 03:43:01 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Thu, 12 Feb 2015 11:43:01 +0000 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= References: <19510226719.20150209161121@softsearch.ru> <734502797.20150210203958@softsearch.ru> <142864133.20150210215715@softsearch.ru> <828039509.20150211221827@softsearch.ru> <54DC62D7.6080401@gmail.com> <54DC6666.4090208@rambler.ru> <54DC7BE9.2030406@rambler.ru> <0AD1C019-7802-4888-BA4C-85B90715537D@gmail.com> <28214393.20150212142312@softsearch.ru> Message-ID: > > Вот рабочий, но не оптимизированный по скорости вариант > http://pastebin.com/YTfpfQDB > Он включает в себя и ping-pong и story. Надеюсь, что Александр Лурье > поможет с доработкой кода, ибо писал подобное впервые, вышло криво. > Также в полтора раза ускорен ping-pong. > Залей, пожалуйста, на github. Я там комменты оставлю. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From postmaster на softsearch.ru Thu Feb 12 04:59:15 2015 From: postmaster на softsearch.ru (=?koi8-r?B?7cnIwcnMIO3PzsHbo9c=?=) Date: Thu, 12 Feb 2015 15:59:15 +0300 Subject: [Moscow.pm] =?koi8-r?b?89LB187FzsnFINHa2cvP1w==?= In-Reply-To: References: <19510226719.20150209161121@softsearch.ru> <734502797.20150210203958@softsearch.ru> <142864133.20150210215715@softsearch.ru> <828039509.20150211221827@softsearch.ru> <54DC62D7.6080401@gmail.com> <54DC6666.4090208@rambler.ru> <54DC7BE9.2030406@rambler.ru> <0AD1C019-7802-4888-BA4C-85B90715537D@gmail.com> <28214393.20150212142312@softsearch.ru> Message-ID: <869511668.20150212155915@softsearch.ru> Здравствуйте, Alexander. > Залей, пожалуйста, на github. Я там комменты оставлю. https://github.com/softsearch/test_go/blob/master/main.go -- С уважением, Михаил mailto:postmaster на softsearch.ru From foxcool333 на gmail.com Thu Feb 12 12:22:18 2015 From: foxcool333 на gmail.com (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCk0L7QutGB0LrRg9C7?=) Date: Fri, 13 Feb 2015 00:22:18 +0400 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= In-Reply-To: <869511668.20150212155915@softsearch.ru> References: <19510226719.20150209161121@softsearch.ru> <734502797.20150210203958@softsearch.ru> <142864133.20150210215715@softsearch.ru> <828039509.20150211221827@softsearch.ru> <54DC62D7.6080401@gmail.com> <54DC6666.4090208@rambler.ru> <54DC7BE9.2030406@rambler.ru> <0AD1C019-7802-4888-BA4C-85B90715537D@gmail.com> <28214393.20150212142312@softsearch.ru> <869511668.20150212155915@softsearch.ru> Message-ID: http://rosettacode.org/wiki/Rosetta_Code вам может пригодиться в этом нелегком деле? ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From i.petro.77.00 на gmail.com Sun Feb 15 01:29:03 2015 From: i.petro.77.00 на gmail.com (Ivan Petrov) Date: Sun, 15 Feb 2015 12:29:03 +0300 Subject: [Moscow.pm] =?utf-8?b?0JjQvdC+0LPQtNCwINC/0YDQvtCy0LDQu9C40LI=?= =?utf-8?b?0LDQtdGC0YHRjyDRgdC60LLQvtC30YwgZXZhbA==?= Message-ID: <20150215092903.GM17407@vdsl.uvw.ru> вот такой код 32 eval { utf8::downgrade $str } if utf8::is_utf8 $str; 33 warn $@ if $@; Изредка (очень редко) но падает в строке 1 то есть глобальный eval ловит ошибку Wide character in subroutine entry at FILE line 32 в глобальном eval мы в лог кладем полностью все входные данные и далее на тех же входных данных тест не падает уже. все происходит в вебсервере. пользователь повторяет тот же самый ввод и после 500-ки которую он получил на прошлом падении он получает уже работающую страницу. как подиагностировать подобную багу? From victor на vsespb.ru Sun Feb 15 04:11:48 2015 From: victor на vsespb.ru (Victor Efimov) Date: Sun, 15 Feb 2015 16:11:48 +0400 Subject: [Moscow.pm] =?utf-8?b?0JjQvdC+0LPQtNCwINC/0YDQvtCy0LDQu9C40LI=?= =?utf-8?b?0LDQtdGC0YHRjyDRgdC60LLQvtC30YwgZXZhbA==?= In-Reply-To: <20150215092903.GM17407@vdsl.uvw.ru> References: <20150215092903.GM17407@vdsl.uvw.ru> Message-ID: Навзвание темы создала впечатление что что-то с perl и eval не так работаел ;) utf8::downgrade и должен падать если в сроке есть символы с кодом больше 255: === Fails if the original UTF-X sequence cannot be represented in the native 8 bit encoding. On failure dies or, if the value of $fail_ok is true, returns false. === Как продиагностировать - так и продиагностировать - если падает - сам символы с кодом больше 255. Сдампить их можно Devel::Peek. Сам код eval { utf8::downgrade $str } if utf8::is_utf8 $str; бессмысленен и эквивалентен eval { utf8::downgrade $str } 15 февраля 2015 г., 12:29 пользователь Ivan Petrov написал: > вот такой код > > 32 eval { utf8::downgrade $str } if utf8::is_utf8 $str; > 33 warn $@ if $@; > > Изредка (очень редко) но падает в строке 1 > то есть глобальный eval ловит ошибку > > Wide character in subroutine entry at FILE line 32 > > в глобальном eval мы в лог кладем полностью все входные данные > и далее на тех же входных данных тест не падает уже. > > все происходит в вебсервере. > пользователь повторяет тот же самый ввод и после 500-ки которую он > получил на прошлом падении он получает уже работающую страницу. > > как подиагностировать подобную багу? > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org From maxim.vuets на gmail.com Sun Feb 15 10:14:18 2015 From: maxim.vuets на gmail.com (Maxim Vuets) Date: Sun, 15 Feb 2015 19:14:18 +0100 Subject: [Moscow.pm] =?utf-8?b?0JjQvdC+0LPQtNCwINC/0YDQvtCy0LDQu9C40LI=?= =?utf-8?b?0LDQtdGC0YHRjyDRgdC60LLQvtC30YwgZXZhbA==?= In-Reply-To: <20150215092903.GM17407@vdsl.uvw.ru> References: <20150215092903.GM17407@vdsl.uvw.ru> Message-ID: 2015-02-15 10:29 GMT+01:00 Ivan Petrov : > вот такой код > > 32 eval { utf8::downgrade $str } if utf8::is_utf8 $str; > 33 warn $@ if $@; > > Изредка (очень редко) но падает в строке 1 > то есть глобальный eval ловит ошибку > > Wide character in subroutine entry at FILE line 32 Подозреваю, что у вас что-то неладно с локализацией $@. Грубый пример: (1) mvuets на ilosonaloje:~$ cat -n doubleeval.pl 1 use v5.20; 2 use warnings; 3 eval { 4 eval { die "shenanigans!" }; 5 die $@; 6 }; 7 say "$@"; (1) mvuets на ilosonaloje:~$ perl doubleeval.pl shenanigans! at doubleeval.pl line 4. Сообщение говорит о строке 4, но фактически выброс был на строке 5. Кстати, такие eval-ы безопаснее писать так: не опирайтесь на значение $@, а явно проверяйте, что возвращает eval. 1 use v5.20; 2 use warnings; 3 eval { die "shenanigans!"; 1 } 4 or warn "$@"; From alexandre на frolov.pp.ru Tue Feb 17 07:45:28 2015 From: alexandre на frolov.pp.ru (Alexandre Frolov) Date: Tue, 17 Feb 2015 18:45:28 +0300 Subject: [Moscow.pm] =?koi8-r?b?897J1NnXwdTFzNggUkZJRCAtIMvByyDTxMXMwdTY?= =?koi8-r?b?IMTP09TV0CDOwSBQZXJsPw==?= Message-ID: <02cc01d04ac8$c132c930$43985b90$@pp.ru> Осваиваем технологию RFID: Очень интересно, есть ли у кого-нибудь опыт создания программ на Perl для получения данных от считывателей RFID, такие, например, как этот: http://www.iqsklad.ru/catalog/model/22414.html? На cpan имеются модули для работы с rfid, кто-нибудь их использовал для решения этой задачи? Спасибо за ответ! С уважением, Управляющий директор ООО "АйТи-Матрикс" Александр Фролов ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From dmitry на eremeev.ru Tue Feb 17 07:56:05 2015 From: dmitry на eremeev.ru (Dmitry Eremeev) Date: Tue, 17 Feb 2015 18:56:05 +0300 Subject: [Moscow.pm] =?koi8-r?b?897J1NnXwdTFzNggUkZJRCAtIMvByyDTxMXMwdTY?= =?koi8-r?b?IMTP09TV0CDOwSBQZXJsPw==?= In-Reply-To: <02cc01d04ac8$c132c930$43985b90$@pp.ru> References: <02cc01d04ac8$c132c930$43985b90$@pp.ru> Message-ID: Рфид просто технология хранения айдишек. Айдишка может быть как на штрихкоде, так и на рфиде. На уровне торгового оборудования считыватели (сканеры штрихкода или ридеры рфида) чаще всего просто эмулируют ввод с клавы. Ну а как перлом на десктопе клаву слушать наверняка разберетесь. Yours Dmitry Eremeev CEO adPremium Russia / office: +7 499 703 32 07 UK / office: +44 870 295 24 46 Skype: eremeev.ru https://linkedin.com/in/dimkae https://facebook.com/dimkae > 17 февр. 2015 г., в 18:45, Alexandre Frolov написал(а): > > Осваиваем технологию RFID? > Очень интересно, есть ли у кого-нибудь опыт создания программ на Perl для получения данных от считывателей RFID, такие, например, как этот: http://www.iqsklad.ru/catalog/model/22414.html? На cpan имеются модули для работы с rfid, кто-нибудь их использовал для решения этой задачи? > Спасибо за ответ! > > С уважением, > Управляющий директор ООО "АйТи-Матрикс" > Александр Фролов > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From alexandre на frolov.pp.ru Tue Feb 17 08:13:44 2015 From: alexandre на frolov.pp.ru (Alexandre Frolov) Date: Tue, 17 Feb 2015 19:13:44 +0300 Subject: [Moscow.pm] =?utf-8?b?0KHRh9C40YLRi9Cy0LDRgtC10LvRjCBSRklEIC0g?= =?utf-8?b?0LrQsNC6INGB0LTQtdC70LDRgtGMINC00L7RgdGC0YPQvyDQvdCwIFBl?= =?utf-8?b?cmw/?= In-Reply-To: References: <02cc01d04ac8$c132c930$43985b90$@pp.ru> Message-ID: <02e901d04acc$b424aa70$1c6dff50$@pp.ru> Тут интереснее было бы использовать WiFi интерфейс считывателей, т.к. их может быть несколько, и с ними ходят по складу. Клавиатурный интерфейс неудобен, т.к. нужно таскать товар к столу кладовщика, а это не всегда возможно? From: Moscow-pm [mailto:moscow-pm-bounces+alexandre=frolov.pp.ru на pm.org] On Behalf Of Dmitry Eremeev Sent: Tuesday, February 17, 2015 6:56 PM To: Moscow.pm group Subject: Re: [Moscow.pm] Считыватель RFID - как сделать доступ на Perl? Рфид просто технология хранения айдишек. Айдишка может быть как на штрихкоде, так и на рфиде. На уровне торгового оборудования считыватели (сканеры штрихкода или ридеры рфида) чаще всего просто эмулируют ввод с клавы. Ну а как перлом на десктопе клаву слушать наверняка разберетесь. Yours Dmitry Eremeev CEO adPremium Russia / office: +7 499 703 32 07 UK / office: +44 870 295 24 46 Skype: eremeev.ru https://linkedin.com/in/dimkae https://facebook.com/dimkae 17 февр. 2015 г., в 18:45, Alexandre Frolov написал(а): Осваиваем технологию RFID? Очень интересно, есть ли у кого-нибудь опыт создания программ на Perl для получения данных от считывателей RFID, такие, например, как этот: http://www.iqsklad.ru/catalog/model/22414.html? На cpan имеются модули для работы с rfid, кто-нибудь их использовал для решения этой задачи? Спасибо за ответ! С уважением, Управляющий директор ООО "АйТи-Матрикс" Александр Фролов -- Moscow.pm mailing list moscow-pm на pm.org | http://moscow.pm.org ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From dmitry на eremeev.ru Tue Feb 17 08:25:22 2015 From: dmitry на eremeev.ru (Dmitry Eremeev) Date: Tue, 17 Feb 2015 19:25:22 +0300 Subject: [Moscow.pm] =?koi8-r?b?897J1NnXwdTFzNggUkZJRCAtIMvByyDTxMXMwdTY?= =?koi8-r?b?IMTP09TV0CDOwSBQZXJsPw==?= In-Reply-To: <02e901d04acc$b424aa70$1c6dff50$@pp.ru> References: <02cc01d04ac8$c132c930$43985b90$@pp.ru> <02e901d04acc$b424aa70$1c6dff50$@pp.ru> Message-ID: <3C7A81EE-42D4-4A9F-9891-FAF7A59864C2@eremeev.ru> Это все было решено уже лет 10 назад. Под терминал пишется софтина, которая считанное отправляет куда надо. Для отправки тоже уже решений вагон. Тут проще вам отловить сейла из конторы, которая продает торговое оборудование, убедитесь, что уже есть зоопарк решений. Yours Dmitry Eremeev CEO adPremium Russia / office: +7 499 703 32 07 UK / office: +44 870 295 24 46 Skype: eremeev.ru https://linkedin.com/in/dimkae https://facebook.com/dimkae > 17 февр. 2015 г., в 19:13, Alexandre Frolov написал(а): > > Тут интереснее было бы использовать WiFi интерфейс считывателей, т.к. их может быть несколько, и с ними ходят по складу. > Клавиатурный интерфейс неудобен, т.к. нужно таскать товар к столу кладовщика, а это не всегда возможно? > > From: Moscow-pm [mailto:moscow-pm-bounces+alexandre=frolov.pp.ru на pm.org] On Behalf Of Dmitry Eremeev > Sent: Tuesday, February 17, 2015 6:56 PM > To: Moscow.pm group > Subject: Re: [Moscow.pm] Считыватель RFID - как сделать доступ на Perl? > > Рфид просто технология хранения айдишек. Айдишка может быть как на штрихкоде, так и на рфиде. > > На уровне торгового оборудования считыватели (сканеры штрихкода или ридеры рфида) чаще всего просто эмулируют ввод с клавы. > > Ну а как перлом на десктопе клаву слушать наверняка разберетесь. > > > > Yours > Dmitry Eremeev > CEO adPremium > > Russia / office: +7 499 703 32 07 > UK / office: +44 870 295 24 46 > Skype: eremeev.ru > > https://linkedin.com/in/dimkae > https://facebook.com/dimkae > > > 17 февр. 2015 г., в 18:45, Alexandre Frolov написал(а): > > Осваиваем технологию RFID? > Очень интересно, есть ли у кого-нибудь опыт создания программ на Perl для получения данных от считывателей RFID, такие, например, как этот: http://www.iqsklad.ru/catalog/model/22414.html? На cpan имеются модули для работы с rfid, кто-нибудь их использовал для решения этой задачи? > Спасибо за ответ! > > С уважением, > Управляющий директор ООО "АйТи-Матрикс" > Александр Фролов > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From dzirtik на gmail.com Wed Feb 18 00:17:48 2015 From: dzirtik на gmail.com (=?UTF-8?B?0J/QsNCy0LXQuyDQqdC10YDQsdC40L3QuNC9?=) Date: Wed, 18 Feb 2015 11:17:48 +0300 Subject: [Moscow.pm] =?utf-8?b?0JLRgdGC0YDQtdGH0LAgTW9zY293LnBtIDUg0YQ=?= =?utf-8?b?0LXQstGA0LDQu9GPIDIwMTM=?= In-Reply-To: References: Message-ID: Все видео со всех митапов загружены на наш канал http://www.youtube.com/channel/UCXG2gjCfXDkvg9TfPmNXPIg/videos 6 февраля 2015 г., 12:57 пользователь Ксения Боброва < bobrovaksenia на gmail.com> написал: > А видео с предыдущих встреч?) > > 6 февраля 2015 г., 10:07 пользователь Павел Щербинин > написал: > > Видео в течение недели появится на нашем канале >> www.youtube.com/channel/UCXG2gjCfXDkvg9TfPmNXPIg/videos >> Презентации уже выложены www.slideshare.net/pavelscherbinin >> >> 6 февраля 2015 г., 7:34 пользователь Иван Соколов >> написал: >> >> Я в начале конфы говорил про генератор статики. >>> Вот ссылка http://preaction.github.io/Statocles/ >>> Это аналог популярного Jekyll, который активно используется на гитхабе >>> для отображения страничек проектов. >>> Выглядит очень достойно, мне кажется. >>> >>> 5 февраля 2015 г., 19:54 пользователь Павел Щербинин >>> написал: >>> >>>> http://corp.mail.ru/stream/MoscowPM/ >>>> >>>> прямая трансляция нашей встречи >>>> >>>> 29 января 2015 г., 19:56 пользователь Павел Щербинин >>> > написал: >>>> >>>> >>>>> - >>>>> >>>>> Perl-программисты из Moscow.pm снова собирают >>>>> единомышленников. За почти 8 лет существования Perl Mongers (от англ. >>>>> ?продавцы?) сменили формат посиделок в кафе и прочно обосновались в уютном >>>>> офисе Mail.Ru Group. В сообществе ? ветераны Moscow PM и новички, которые с >>>>> первого посещения рвутся в спикеры. Программисты приходят сюда, чтобы >>>>> поделиться действительно полезным опытом. Однажды запланированное на 40 >>>>> минут выступление о ядре Perl так увлекло участников, что дискуссия >>>>> растянулась на 3 часа, и все разошлись по домам только к полуночи. >>>>> >>>>> Предстоящая встреча заинтересует специалистов в e-commerce и тех, >>>>> кто не понаслышке знаком с очередями. А ленивым программистам и тем, кто не >>>>> любит делать лишнюю работу, будет полезен доклад о генерации кода. >>>>> >>>>> О работе с документами .xls, .xlsx, .rtf расскажет Наталья >>>>> Савенкова, ex-СТО SHOP2YOU.RU . В e-commerce >>>>> файлы формата Excel ? основной инструмент обмена данными. Они используются >>>>> везде: для документов покупателям и транспортным компаниям, для отчетов >>>>> менеджерам, для импорта и экспорта товаров в магазин, для обмена остатками >>>>> между поставщиками. Их нужно уметь читать и писать. Наталья объяснит, как >>>>> это делать с документами разной структуры, а также поговорит о сложностях и >>>>> их решениях. Доклад посвящен классическому формату Excel 1997-2003 (XLS) и >>>>> модулям: Spreadsheet::ParseExcel, Spreadsheet::WriteExcel и Excel::Template. >>>>> >>>>> ?FastQueue ? как мы сделали свою очередь на Perl и Redis? тема ? >>>>> выступления Ивана Соколова, teamlead REG.RU . >>>>> Очередь ? один из наиболее используемых механизмов в >>>>> программировании. Например, для интеграции с платежными системами или для >>>>> обработки медиа-контента, загруженного пользователем, необходимо наличие >>>>> очередей. >>>>> >>>>> В REG.RU тоже не обходятся без очередей. Поэтому потребность найти >>>>> решение появилась достаточно давно. Учитывая специфику компании как >>>>> доменного регистратора большинство существующих решений не подходило, и >>>>> программисты решили ?написать свой велосипед?. Иван расскажет об >>>>> архитектуре их очереди, ее возможностях, и в каких задачах она используется. >>>>> >>>>> ?Пластилиновый код: как перестать кодить и начать жить? ? доклад Елены >>>>> Шишкиной, ведущего программиста Деньги Mail.Ru >>>>> . Она покажет практический пример лени как >>>>> двигателя прогресса в отдельно взятом веб-проекте: >>>>> >>>>> - Надоело писать код? Будем думать, как его не писать! >>>>> >>>>> - Боремся с однотипным кодом. Боремся с неоднотипным кодом. >>>>> >>>>> - Код, которого не существует, и код, который существует. >>>>> >>>>> - Следите за руками: программируем на конфигах! >>>>> >>>>> - Как жить дальше? >>>>> >>>>> >>>>> Что бы мы могли лучше организовать наше мероприятие, пожалуйста, >>>>> зарегистрируйтесь здесь >>>>> >>>>> >>>>> -- >>>>> С Уважением, >>>>> Щербинин Павел >>>>> >>>> >>>> >>>> >>>> -- >>>> С Уважением, >>>> Щербинин Павел >>>> >>>> -- >>>> Moscow.pm mailing list >>>> moscow-pm на pm.org | http://moscow.pm.org >>>> >>>> >>> >>> >>> -- >>> С уважением, >>> Иван >>> >>> -- >>> Moscow.pm mailing list >>> moscow-pm на pm.org | http://moscow.pm.org >>> >>> >> >> >> -- >> С Уважением, >> Щербинин Павел >> >> -- >> Moscow.pm mailing list >> moscow-pm на pm.org | http://moscow.pm.org >> >> > > > -- > Ksenia Bobrova > Senior Perl Developer > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > > -- С Уважением, Щербинин Павел ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From parserpro на gmail.com Wed Feb 18 07:18:05 2015 From: parserpro на gmail.com (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0JzRi9GI0LrQuNC9?=) Date: Wed, 18 Feb 2015 19:18:05 +0400 Subject: [Moscow.pm] DBIx::SearchBuilder Message-ID: Привет всем! Возник довольно срочный вопрос - как в DBIx::SearchBuilder сделать такое (если хоть кто-то в курсе): SELECT a, b FROM t WHERE a > b Используется этот модуль в Request Tracker'e -- С уважением, Мышкин Алексей. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From greyhard на gmail.com Thu Feb 19 04:48:07 2015 From: greyhard на gmail.com (=?UTF-8?B?0JTQtdC90LjRgSDQmNC70YzQuNC90YvRhQ==?=) Date: Thu, 19 Feb 2015 16:48:07 +0400 Subject: [Moscow.pm] =?utf-8?b?0JDQtNC80LjQvdGLINGF0LXQu9C/?= Message-ID: Может вопрос не по теме. Но про Perl (^_^) Обновляю пакеты с битыми shared library через freebsd pkg пара пакетов хотят обновить перл с 5.16 на 5.18 Подскажите как указать pkg не обновлять перл. Гугление не дало результата :( Спасибо ) -- С уважением. Ильиных Денис Программист Компания "GT-Shop.ru" Телефон: +7(963) 995-7616 ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From zahatski на gmail.com Thu Feb 19 04:51:17 2015 From: zahatski на gmail.com (Aliaksandr Zahatski) Date: Thu, 19 Feb 2015 16:51:17 +0400 Subject: [Moscow.pm] =?koi8-r?b?4cTNyc7ZIMjFzNA=?= In-Reply-To: References: Message-ID: Приветствую! Вроде этого: /etc/make.conf PERL_VERSION=5.16.2 19 февраля 2015 г., 15:48 пользователь Денис Ильиных написал: > Может вопрос не по теме. Но про Perl (^_^) > > Обновляю пакеты с битыми shared library через freebsd pkg > > пара пакетов хотят обновить перл с 5.16 на 5.18 > Подскажите как указать pkg не обновлять перл. > > Гугление не дало результата :( > > Спасибо ) > > > -- > С уважением. > Ильиных Денис > Программист > Компания "GT-Shop.ru" > Телефон: +7(963) 995-7616 > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > From greyhard на gmail.com Thu Feb 19 04:59:39 2015 From: greyhard на gmail.com (=?UTF-8?B?0JTQtdC90LjRgSDQmNC70YzQuNC90YvRhQ==?=) Date: Thu, 19 Feb 2015 16:59:39 +0400 Subject: [Moscow.pm] =?utf-8?b?0JDQtNC80LjQvdGLINGF0LXQu9C/?= In-Reply-To: References: Message-ID: Это при условии ручной сборки из портов , а при бинарном обновлении через https://www.freebsd.org/doc/ru/books/handbook/pkgng-intro.html эта опция видимо не работает. 19 февраля 2015 г., 15:51 пользователь Aliaksandr Zahatski < zahatski на gmail.com> написал: > Приветствую! > > Вроде этого: > > /etc/make.conf > PERL_VERSION=5.16.2 > > 19 февраля 2015 г., 15:48 пользователь Денис Ильиных > написал: > > Может вопрос не по теме. Но про Perl (^_^) > > > > Обновляю пакеты с битыми shared library через freebsd pkg > > > > пара пакетов хотят обновить перл с 5.16 на 5.18 > > Подскажите как указать pkg не обновлять перл. > > > > Гугление не дало результата :( > > > > Спасибо ) > > > > > > -- > > С уважением. > > Ильиных Денис > > Программист > > Компания "GT-Shop.ru" > > Телефон: +7(963) 995-7616 > > > > -- > > Moscow.pm mailing list > > moscow-pm на pm.org | http://moscow.pm.org > > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > -- С уважением. Ильиных Денис Программист Компания "GT-Shop.ru" Телефон: +7(963) 995-7616 ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From zahatski на gmail.com Thu Feb 19 05:04:54 2015 From: zahatski на gmail.com (Aliaksandr Zahatski) Date: Thu, 19 Feb 2015 17:04:54 +0400 Subject: [Moscow.pm] =?koi8-r?b?4cTNyc7ZIMjFzNA=?= In-Reply-To: References: Message-ID: Да, совершенно верно: имеет смысл при использовании ports-mgmt/portmaster или ports-mgmt/portupgrade при сборке из исходников. 19 февраля 2015 г., 15:59 пользователь Денис Ильиных написал: > Это при условии ручной сборки из портов , а при бинарном обновлении через > https://www.freebsd.org/doc/ru/books/handbook/pkgng-intro.html эта опция > видимо не работает. > > 19 февраля 2015 г., 15:51 пользователь Aliaksandr Zahatski > написал: > >> Приветствую! >> >> Вроде этого: >> >> /etc/make.conf >> PERL_VERSION=5.16.2 >> >> 19 февраля 2015 г., 15:48 пользователь Денис Ильиных >> написал: >> > Может вопрос не по теме. Но про Perl (^_^) >> > >> > Обновляю пакеты с битыми shared library через freebsd pkg >> > >> > пара пакетов хотят обновить перл с 5.16 на 5.18 >> > Подскажите как указать pkg не обновлять перл. >> > >> > Гугление не дало результата :( >> > >> > Спасибо ) >> > >> > >> > -- >> > С уважением. >> > Ильиных Денис >> > Программист >> > Компания "GT-Shop.ru" >> > Телефон: +7(963) 995-7616 >> > >> > -- >> > Moscow.pm mailing list >> > moscow-pm на pm.org | http://moscow.pm.org >> > >> -- >> Moscow.pm mailing list >> moscow-pm на pm.org | http://moscow.pm.org > > > > > -- > С уважением. > Ильиных Денис > Программист > Компания "GT-Shop.ru" > Телефон: +7(963) 995-7616 > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > From citrin на citrin.ru Thu Feb 19 05:03:32 2015 From: citrin на citrin.ru (Anton Yuzhaninov) Date: Thu, 19 Feb 2015 16:03:32 +0300 Subject: [Moscow.pm] =?koi8-r?b?4cTNyc7ZIMjFzNA=?= In-Reply-To: References: Message-ID: <54E5DF24.8080501@citrin.ru> On 02/19/15 15:51, Aliaksandr Zahatski wrote: > /etc/make.conf > PERL_VERSION=5.16.2 Это уже старый способ. Сейчас нужно писать DEFAULT_VERSIONS+= perl5=5.16 Не уверен учитывает ли это pkg (я в основном по старинке, из портов собираю), но вроде бы учитывает. From snelius на tsu.ru Thu Feb 19 06:04:54 2015 From: snelius на tsu.ru (Anatoly Y) Date: Thu, 19 Feb 2015 20:04:54 +0600 Subject: [Moscow.pm] =?utf-8?b?0JDQtNC80LjQvdGLINGF0LXQu9C/?= In-Reply-To: <54E5DF24.8080501@citrin.ru> References: <54E5DF24.8080501@citrin.ru> Message-ID: можно залочить перл чтобы он не обновлялся. pkg lock perl 2015-02-19 19:03 GMT+06:00 Anton Yuzhaninov : > On 02/19/15 15:51, Aliaksandr Zahatski wrote: > >> /etc/make.conf >> PERL_VERSION=5.16.2 >> > > Это уже старый способ. Сейчас нужно писать > > DEFAULT_VERSIONS+= perl5=5.16 > > Не уверен учитывает ли это pkg (я в основном по старинке, из портов > собираю), но вроде бы учитывает. > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From greyhard на gmail.com Thu Feb 19 06:21:50 2015 From: greyhard на gmail.com (=?UTF-8?B?0JTQtdC90LjRgSDQmNC70YzQuNC90YvRhQ==?=) Date: Thu, 19 Feb 2015 18:21:50 +0400 Subject: [Moscow.pm] =?utf-8?b?0JDQtNC80LjQvdGLINGF0LXQu9C/?= In-Reply-To: References: <54E5DF24.8080501@citrin.ru> Message-ID: Спасибо ) pkg lock perl5 то что нужно 19 февраля 2015 г., 17:04 пользователь Anatoly Y написал: > можно залочить перл чтобы он не обновлялся. pkg lock perl > > 2015-02-19 19:03 GMT+06:00 Anton Yuzhaninov : > >> On 02/19/15 15:51, Aliaksandr Zahatski wrote: >> >>> /etc/make.conf >>> PERL_VERSION=5.16.2 >>> >> >> Это уже старый способ. Сейчас нужно писать >> >> DEFAULT_VERSIONS+= perl5=5.16 >> >> Не уверен учитывает ли это pkg (я в основном по старинке, из портов >> собираю), но вроде бы учитывает. >> >> -- >> Moscow.pm mailing list >> moscow-pm на pm.org | http://moscow.pm.org >> > > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > > -- С уважением. Ильиных Денис Программист Компания "GT-Shop.ru" Телефон: +7(963) 995-7616 ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From timon на timon.net.nz Thu Feb 19 05:46:27 2015 From: timon на timon.net.nz (Aleksander Matveev) Date: Thu, 19 Feb 2015 16:46:27 +0300 Subject: [Moscow.pm] =?koi8-r?b?4cTNyc7ZIMjFzNA=?= In-Reply-To: <54E5DF24.8080501@citrin.ru> References: <54E5DF24.8080501@citrin.ru> Message-ID: <54E5E933.6000700@timon.net.nz> On 19/02/2015 16:03, Anton Yuzhaninov wrote: > On 02/19/15 15:51, Aliaksandr Zahatski wrote: >> /etc/make.conf >> PERL_VERSION=5.16.2 > > Это уже старый способ. Сейчас нужно писать > > DEFAULT_VERSIONS+= perl5=5.16 > > Не уверен учитывает ли это pkg (я в основном по старинке, из портов > собираю), но вроде бы учитывает. Не учитывает, т.к. pkg ставит бинарный пакет и у него внутри в зависимостях прописан Perl версии 5.18 В данный момент, указать pkg не трогать зависимости возможности нет :( -- Aleksandr Matveev From alexandre на frolov.pp.ru Thu Feb 19 07:00:17 2015 From: alexandre на frolov.pp.ru (Alexandre Frolov) Date: Thu, 19 Feb 2015 18:00:17 +0300 Subject: [Moscow.pm] =?utf-8?b?0KHRh9C40YLRi9Cy0LDRgtC10LvRjCBSRklEIC0g?= =?utf-8?b?0LrQsNC6INGB0LTQtdC70LDRgtGMINC00L7RgdGC0YPQvyDQvdCwIFBl?= =?utf-8?b?cmw/?= In-Reply-To: <3C7A81EE-42D4-4A9F-9891-FAF7A59864C2@eremeev.ru> References: <02cc01d04ac8$c132c930$43985b90$@pp.ru> <02e901d04acc$b424aa70$1c6dff50$@pp.ru> <3C7A81EE-42D4-4A9F-9891-FAF7A59864C2@eremeev.ru> Message-ID: <034401d04c54$c61b34e0$52519ea0$@pp.ru> Дмитрий, т.е. без софта, написанного для терминала, никак? И нужно уже организовывать взаимодействие между нашим Web-сервисом и этим софтом? Получается что эти довольно дорогие терминалы не содержат в себе софта, которым мы могли бы пользоваться непосредственно в своей складской программе? С уважением, Управляющий директор ООО "АйТи-Матрикс" Александр Фролов +7 (495) 545-4921 +7 (495) 589-0759 support на itmatrix.ru www.shop2you.ru logo --------------------------------------------------- Пожалуйста, при ответе сохраняйте историю переписки. From: Moscow-pm [mailto:moscow-pm-bounces+alexandre=frolov.pp.ru на pm.org] On Behalf Of Dmitry Eremeev Sent: Tuesday, February 17, 2015 7:25 PM To: Moscow.pm group Subject: Re: [Moscow.pm] Считыватель RFID - как сделать доступ на Perl? Это все было решено уже лет 10 назад. Под терминал пишется софтина, которая считанное отправляет куда надо. Для отправки тоже уже решений вагон. Тут проще вам отловить сейла из конторы, которая продает торговое оборудование, убедитесь, что уже есть зоопарк решений. Yours Dmitry Eremeev CEO adPremium ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: ----------- следущая часть ----------- A non-text attachment was scrubbed... Name: отсутствует Type: image/jpeg Size: 2892 bytes Desc: отсутствует URL: From vadim на pushtaev.ru Sat Feb 7 00:36:11 2015 From: vadim на pushtaev.ru (Vadim Pushtaev) Date: Sat, 07 Feb 2015 11:36:11 +0300 Subject: [Moscow.pm] =?koi8-r?b?9MXN2SDEzNEgxM/LzMHEz9c=?= In-Reply-To: References: Message-ID: <261651423298171@web7o.yandex.ru> Вложение в формате HTML было извлечено… URL: From v.perepelitsa на corp.mail.ru Tue Feb 10 04:26:59 2015 From: v.perepelitsa на corp.mail.ru (Mons Anderson) Date: Tue, 10 Feb 2015 15:26:59 +0300 Subject: [Moscow.pm] =?utf-8?b?0KHRgNCw0LLQvdC10L3QuNC1INGP0LfRi9C60L4=?= =?utf-8?b?0LI=?= In-Reply-To: <1825727633.20150210092847@softsearch.ru> References: <19510226719.20150209161121@softsearch.ru> <1825727633.20150210092847@softsearch.ru> Message-ID: $ cat sum.c #include #include #include int main (int argc,char **argv) { long int S = atoi(argv[1]); int * a = (int *)malloc(S * sizeof(int)); long int i,z; for (i=0;i < S; i++) { a[i] = i; } clock_t start = clock(); long int sum = 0; for(z = 0; z < 100; z++ ){ sum = 0; for (i=0;i < S - S % 16; i+=16) { sum += a[i] + a[i+1] + a[i+2] + a[i+3] + a[i+4] + a[i+5] + a[i+6] + a[i+7] + a[i+8] + a[i+9] + a[i+10] + a[i+11] + a[i+12] + a[i+13] + a[i+14] + a[i+15] ; } for (i; i < S; i++ ) { sum += a[i]; } } clock_t end = clock(); printf("%lu: %lu (%0.8f)\n",S,sum,((double)end-start)/CLOCKS_PER_SEC/z); } $ gcc --std=c99 -O3 -march=native -o sum sum.c && ./sum 10000000 10000000: 49999995000000 (0.00660000) -- Mons Anderson > On 10 февр. 2015 г., at 9:28, Михаил Монашёв wrote: > > Здравствуйте, Mons. > > Вот код, который соответствует исходной задаче. > > #include > #include > > int main() > { > unsigned __int32 *arr; > > arr = (unsigned __int32 *) malloc(10000000 * sizeof(unsigned __int32)); > > int i; > for( i=10000000-1; i>=0; i--) { > arr[i] = i; > } > > clock_t start = clock(); > > unsigned __int64 sum; > sum = 0; > for( i=10000000-1; i>=0; i--) { > sum+=arr[i]; > } > > clock_t end = clock(); > > printf("Time:(%0.8f)ms . Sum: %llu", ((double)end-start)/CLOCKS_PER_SEC*1000, sum); > return 0; > } > > C:\Temp>gcc -O3 -march=native 3.c -o 3.exe > 3.c: In function 'main': > 3.c:8:30: warning: incompatible implicit declaration of built-in function 'malloc' [enabled by default] > arr = (unsigned __int32 *) malloc(10000000 * sizeof(unsigned __int32)); > ^ > > C:\Temp>3.exe > Time:(11.00000000)ms . Sum: 49999995000000 > > Это время в 32-битной венде. > > Как победить этот варнинг при компиляции я не разбирался пока. > > >> int main (int argc,char **argv) { >> ═ ═ ═ ═ longint S = atoi(argv[1]); >> ═ ═ ═ ═ longint i,z; >> ═ ═ ═ ═ clock_t start = clock(); >> ═ ═ ═ ═ longint sum = 0; >> ═ ═ ═ ═ for(z = 0; z < 1000; z++ ){ >> ═ ═ ═ ═ ═ ═ ═ ═ sum = 0; >> ═ ═ ═ ═ ═ ═ ═ ═ for (i=0;i < S - S % 16; i+=16) { >> ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ sum += i ═ + i+1 + i+2═ + i+3═ + i+4═ + i+5═ + i+6═ + i+7 >> ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ══+═ i+8 + i+9 + i+10 + i+11 + i+12 + i+13 + i+14 + i+15 >> ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ; >> ═ ═ ═ ═ ═ ═ ═ ═ } >> ═ ═ ═ ═ ═ ═ ═ ═ for (i; i < S; i++ ) { >> ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ sum += i; >> ═ ═ ═ ═ ═ ═ ═ ═ } >> ═ ═ ═ ═ } >> ═ ═ ═ ═ clock_t end = clock(); >> ═ ═ ═ ═ printf("%lu (%0.8f)\n",sum,((double)end-start)/1e6/z); >> } > > > > > >> 1.5 ms > > >> gcc --std=c99 -O3 -march=native > > > > >> --═ >> Mons Anderson >> > > > > > >> On 9 февр. 2015 г., at 16:11, Михаил Монашёв >> wrote: > >> Здравствуйте, Mons. > >> Народ, я не осилил дочитать это всё до конца. >> А давайте-ка соберёмся и померяемся. >> Не в плане теории, а в плане конкретных чисел >> сравним разные языки, подходы и т.п. > > > >> А ═собираться ═обязательно? ═Можно ведь и удалённо. Я на Go пишу всего >> месяц ═и ═мне было бы сложно придти и что-то нормально на нём написать >> за малое время. Но сравнить языки было бы интересно. > >> Предложу ═простую ═задачку, ═которая ═покажет, ═насколько ═хорошо язык >> работает ═с ═памятью: ═сложить ═все ═значения ═массива, ═состоящего из >> 10000000 ═целых чисел. Код там простой: создаём массив, заполняем его, >> замеряем ═время, ═потом ═в ═цикле ═складываем ═элементы массива, снова >> замеряем время и выдаём результат. Вот мой вариант на Go: >> https://play.golang.org/p/iHGG3nV10L > >> Тонкости: ═в песочнице код съедает много процессора и время там всегда >> одно ═и ═то ═же, поэтому его надо сохранить в файл, например main.go и >> потом запустить вот так: go run main.go >> Скомпилировать ═в исполняемый файл можно вот так: go build main.go >> А вот так выйдет более быстрая версия: go build -gcflags="-B" main.go >> Скачать Go можно вот тут: http://golang.org/ > >> -- >> С уважением, >> Михаил ═════════════════════════mailto:postmaster на softsearch.ru > > > > > -- > С уважением, > Михаил mailto:postmaster на softsearch.ru > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From alexandre на frolov.pp.ru Tue Feb 17 09:44:02 2015 From: alexandre на frolov.pp.ru (Alexandre Frolov) Date: Tue, 17 Feb 2015 20:44:02 +0300 Subject: [Moscow.pm] =?utf-8?b?0KHRh9C40YLRi9Cy0LDRgtC10LvRjCBSRklEIC0g?= =?utf-8?b?0LrQsNC6INGB0LTQtdC70LDRgtGMINC00L7RgdGC0YPQvyDQvdCwIFBl?= =?utf-8?b?cmw/?= In-Reply-To: <3C7A81EE-42D4-4A9F-9891-FAF7A59864C2@eremeev.ru> References: <02cc01d04ac8$c132c930$43985b90$@pp.ru> <02e901d04acc$b424aa70$1c6dff50$@pp.ru> <3C7A81EE-42D4-4A9F-9891-FAF7A59864C2@eremeev.ru> Message-ID: <031501d04ad9$51025390$f306fab0$@pp.ru> Это да, там продают всякие самописанные серверы для работы со считывателями RFID. Их надо покупать, сопровождать силами другой компании, и они вносят свой вклад в общую ненадежность системы. А нам нужно написать свое приложение на Перле, которое могло бы получать данные от считывателей RFID, желательно по сети. Которое мы могли бы сами обслуживать и развивать. Поэтому очень интересно, есть ли у кого-нибудь опыт написания таких приложений с использованием модулей CPAN, специально предназначенных для этого. Там есть несколько штук, RFID::Reader например: use RFID::Blammo::Reader::TCP; my $reader = RFID::Blammo::Reader::TCP->new(PeerAddr => 10.20.30.40, PeerPort => 4001) or die "Couldn't create Blammo reader"; my $version = $reader->get("ReaderVersion"); $reader->set(AntennaSequence => [ 4,3,2,1]); my @tags = $reader->readtags(); foreach my $tag (@tags) { print "I see tag ",$tag->type,".",$tag->id,"\n"; } From: Moscow-pm [mailto:moscow-pm-bounces+alexandre=frolov.pp.ru на pm.org] On Behalf Of Dmitry Eremeev Sent: Tuesday, February 17, 2015 7:25 PM To: Moscow.pm group Subject: Re: [Moscow.pm] Считыватель RFID - как сделать доступ на Perl? Это все было решено уже лет 10 назад. Под терминал пишется софтина, которая считанное отправляет куда надо. Для отправки тоже уже решений вагон. Тут проще вам отловить сейла из конторы, которая продает торговое оборудование, убедитесь, что уже есть зоопарк решений. Yours Dmitry Eremeev CEO adPremium Russia / office: +7 499 703 32 07 UK / office: +44 870 295 24 46 Skype: eremeev.ru https://linkedin.com/in/dimkae https://facebook.com/dimkae 17 февр. 2015 г., в 19:13, Alexandre Frolov написал(а): Тут интереснее было бы использовать WiFi интерфейс считывателей, т.к. их может быть несколько, и с ними ходят по складу. Клавиатурный интерфейс неудобен, т.к. нужно таскать товар к столу кладовщика, а это не всегда возможно? From: Moscow-pm [mailto:moscow-pm-bounces+alexandre=frolov.pp.ru на pm.org] On Behalf Of Dmitry Eremeev Sent: Tuesday, February 17, 2015 6:56 PM To: Moscow.pm group Subject: Re: [Moscow.pm] Считыватель RFID - как сделать доступ на Perl? Рфид просто технология хранения айдишек. Айдишка может быть как на штрихкоде, так и на рфиде. На уровне торгового оборудования считыватели (сканеры штрихкода или ридеры рфида) чаще всего просто эмулируют ввод с клавы. Ну а как перлом на десктопе клаву слушать наверняка разберетесь. Yours Dmitry Eremeev CEO adPremium Russia / office: +7 499 703 32 07 UK / office: +44 870 295 24 46 Skype: eremeev.ru https://linkedin.com/in/dimkae https://facebook.com/dimkae 17 февр. 2015 г., в 18:45, Alexandre Frolov написал(а): Осваиваем технологию RFID? Очень интересно, есть ли у кого-нибудь опыт создания программ на Perl для получения данных от считывателей RFID, такие, например, как этот: http://www.iqsklad.ru/catalog/model/22414.html? На cpan имеются модули для работы с rfid, кто-нибудь их использовал для решения этой задачи? Спасибо за ответ! С уважением, Управляющий директор ООО "АйТи-Матрикс" Александр Фролов -- Moscow.pm mailing list moscow-pm на pm.org | http://moscow.pm.org -- Moscow.pm mailing list moscow-pm на pm.org | http://moscow.pm.org ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From alexandre на frolov.pp.ru Tue Feb 17 22:50:04 2015 From: alexandre на frolov.pp.ru (Alexandre Frolov) Date: Wed, 18 Feb 2015 09:50:04 +0300 Subject: [Moscow.pm] =?utf-8?b?0KHRh9C40YLRi9Cy0LDRgtC10LvRjCBSRklEIC0g?= =?utf-8?b?0LrQsNC6INGB0LTQtdC70LDRgtGMINC00L7RgdGC0YPQvyDQvdCwIFBl?= =?utf-8?b?cmw/?= In-Reply-To: <3C7A81EE-42D4-4A9F-9891-FAF7A59864C2@eremeev.ru> References: <02cc01d04ac8$c132c930$43985b90$@pp.ru> <02e901d04acc$b424aa70$1c6dff50$@pp.ru> <3C7A81EE-42D4-4A9F-9891-FAF7A59864C2@eremeev.ru> Message-ID: <016401d04b47$1fe5cee0$5fb16ca0$@pp.ru> Это да, там продают всякие самописанные серверы для работы со считывателями RFID. Их надо покупать, сопровождать силами другой компании, и они вносят свой вклад в общую ненадежность системы. А нам нужно написать свое приложение на Перле, которое могло бы получать данные от считывателей RFID, желательно по сети. Которое мы могли бы сами обслуживать и развивать. Поэтому очень интересно, есть ли у кого-нибудь опыт написания таких приложений с использованием модулей CPAN, специально предназначенных для этого. Там есть несколько штук, RFID::Reader например: use RFID::Blammo::Reader::TCP; my $reader = RFID::Blammo::Reader::TCP->new(PeerAddr => 10.20.30.40, PeerPort => 4001) or die "Couldn't create Blammo reader"; my $version = $reader->get("ReaderVersion"); $reader->set(AntennaSequence => [ 4,3,2,1]); my @tags = $reader->readtags(); foreach my $tag (@tags) { print "I see tag ",$tag->type,".",$tag->id,"\n"; } From: Moscow-pm [mailto:moscow-pm-bounces+alexandre=frolov.pp.ru на pm.org] On Behalf Of Dmitry Eremeev Sent: Tuesday, February 17, 2015 7:25 PM To: Moscow.pm group Subject: Re: [Moscow.pm] Считыватель RFID - как сделать доступ на Perl? Это все было решено уже лет 10 назад. Под терминал пишется софтина, которая считанное отправляет куда надо. Для отправки тоже уже решений вагон. Тут проще вам отловить сейла из конторы, которая продает торговое оборудование, убедитесь, что уже есть зоопарк решений. Yours Dmitry Eremeev CEO adPremium Russia / office: +7 499 703 32 07 UK / office: +44 870 295 24 46 Skype: eremeev.ru https://linkedin.com/in/dimkae https://facebook.com/dimkae ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From dmitry на eremeev.ru Thu Feb 19 07:19:21 2015 From: dmitry на eremeev.ru (Dmitry Eremeev) Date: Thu, 19 Feb 2015 18:19:21 +0300 Subject: [Moscow.pm] =?koi8-r?b?897J1NnXwdTFzNggUkZJRCAtIMvByyDTxMXMwdTY?= =?koi8-r?b?IMTP09TV0CDOwSBQZXJsPw==?= In-Reply-To: <034401d04c54$c61b34e0$52519ea0$@pp.ru> References: <02cc01d04ac8$c132c930$43985b90$@pp.ru> <02e901d04acc$b424aa70$1c6dff50$@pp.ru> <3C7A81EE-42D4-4A9F-9891-FAF7A59864C2@eremeev.ru> <034401d04c54$c61b34e0$52519ea0$@pp.ru> Message-ID: Дороговизна терминалов кроется в неубиваемости корпусов и экранов, радиусе вайфая и... это же не массмаркет. Там и операционки могут быть супердревние, а цена за 1 устройство как за 10 шестых айфонов. Например, моя любимая промышленная wifi точка Spectrum24 за штуку с чемто баксов уже в 2004 году не была чем-то удивительным. Предъявлять им "так дорого, а решения нет" несколько странновато, так как обычно делается кастом-решение в зависимости от потребностей клиента. По вашему случаю: Как вариант, в браузере на мобилке работает нечто, что в нужный момент ловит данные с rfid и отправляет, но тут сразу набор критических сценариев, от наличия открытой нужной странички в мобильном браузере и наличия курсора в нужном инпуте до общей дуболомности персонала, который обычно работает с такими устройствами. В конечном итоге проще стенд-алон сделать. Мы такие решения делали для терминалов еще лет 10 назад (PalmOS/WinCE), весьма наелись кейсов про пользователей, ломающих неломаемое. Yours Dmitry Eremeev CEO adPremium Russia / office: +7 499 703 32 07 UK / office: +44 870 295 24 46 Skype: eremeev.ru https://linkedin.com/in/dimkae https://facebook.com/dimkae > 19 февр. 2015 г., в 18:00, Alexandre Frolov написал(а): > > Дмитрий, > т.е. без софта, написанного для терминала, никак? > И нужно уже организовывать взаимодействие между нашим Web-сервисом и этим софтом? > Получается что эти довольно дорогие терминалы не содержат в себе софта, которым мы могли бы пользоваться непосредственно в своей складской программе? > > С уважением, > Управляющий директор ООО "АйТи-Матрикс" > Александр Фролов > > +7 (495) 545-4921 > +7 (495) 589-0759 > support на itmatrix.ru > www.shop2you.ru > > --------------------------------------------------- > Пожалуйста, при ответе сохраняйте историю переписки. > > > > From: Moscow-pm [mailto:moscow-pm-bounces+alexandre=frolov.pp.ru на pm.org] On Behalf Of Dmitry Eremeev > Sent: Tuesday, February 17, 2015 7:25 PM > To: Moscow.pm group > Subject: Re: [Moscow.pm] Считыватель RFID - как сделать доступ на Perl? > > Это все было решено уже лет 10 назад. > Под терминал пишется софтина, которая считанное отправляет куда надо. > Для отправки тоже уже решений вагон. > Тут проще вам отловить сейла из конторы, которая продает торговое оборудование, убедитесь, что уже есть зоопарк решений. > > Yours > Dmitry Eremeev > CEO adPremium > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From timur.nozadze на gmail.com Thu Feb 19 13:08:47 2015 From: timur.nozadze на gmail.com (=?UTF-8?B?0KLQuNC80YPRgCDQndC+0LfQsNC00LfQtQ==?=) Date: Fri, 20 Feb 2015 01:08:47 +0400 Subject: [Moscow.pm] =?utf-8?b?0JLRgdGC0YDQtdGH0LAgTW9zY293LnBtIDUg0YQ=?= =?utf-8?b?0LXQstGA0LDQu9GPIDIwMTM=?= In-Reply-To: References: Message-ID: О, это мегакруто! Паша, респект! :) 18 февраля 2015 г., 11:17 пользователь Павел Щербинин написал: > Все видео со всех митапов загружены на наш канал > http://www.youtube.com/channel/UCXG2gjCfXDkvg9TfPmNXPIg/videos > > 6 февраля 2015 г., 12:57 пользователь Ксения Боброва < > bobrovaksenia на gmail.com> написал: > >> А видео с предыдущих встреч?) >> >> 6 февраля 2015 г., 10:07 пользователь Павел Щербинин >> написал: >> >> Видео в течение недели появится на нашем канале >>> www.youtube.com/channel/UCXG2gjCfXDkvg9TfPmNXPIg/videos >>> Презентации уже выложены www.slideshare.net/pavelscherbinin >>> >>> 6 февраля 2015 г., 7:34 пользователь Иван Соколов >>> написал: >>> >>> Я в начале конфы говорил про генератор статики. >>>> Вот ссылка http://preaction.github.io/Statocles/ >>>> Это аналог популярного Jekyll, который активно используется на гитхабе >>>> для отображения страничек проектов. >>>> Выглядит очень достойно, мне кажется. >>>> >>>> 5 февраля 2015 г., 19:54 пользователь Павел Щербинин >>> > написал: >>>> >>>>> http://corp.mail.ru/stream/MoscowPM/ >>>>> >>>>> прямая трансляция нашей встречи >>>>> >>>>> 29 января 2015 г., 19:56 пользователь Павел Щербинин < >>>>> dzirtik на gmail.com> написал: >>>>> >>>>> >>>>>> - >>>>>> >>>>>> Perl-программисты из Moscow.pm снова собирают >>>>>> единомышленников. За почти 8 лет существования Perl Mongers (от англ. >>>>>> ?продавцы?) сменили формат посиделок в кафе и прочно обосновались в уютном >>>>>> офисе Mail.Ru Group. В сообществе ? ветераны Moscow PM и новички, которые с >>>>>> первого посещения рвутся в спикеры. Программисты приходят сюда, чтобы >>>>>> поделиться действительно полезным опытом. Однажды запланированное на 40 >>>>>> минут выступление о ядре Perl так увлекло участников, что дискуссия >>>>>> растянулась на 3 часа, и все разошлись по домам только к полуночи. >>>>>> >>>>>> Предстоящая встреча заинтересует специалистов в e-commerce и тех, >>>>>> кто не понаслышке знаком с очередями. А ленивым программистам и тем, кто не >>>>>> любит делать лишнюю работу, будет полезен доклад о генерации кода. >>>>>> >>>>>> О работе с документами .xls, .xlsx, .rtf расскажет Наталья >>>>>> Савенкова, ex-СТО SHOP2YOU.RU . В e-commerce >>>>>> файлы формата Excel ? основной инструмент обмена данными. Они используются >>>>>> везде: для документов покупателям и транспортным компаниям, для отчетов >>>>>> менеджерам, для импорта и экспорта товаров в магазин, для обмена остатками >>>>>> между поставщиками. Их нужно уметь читать и писать. Наталья объяснит, как >>>>>> это делать с документами разной структуры, а также поговорит о сложностях и >>>>>> их решениях. Доклад посвящен классическому формату Excel 1997-2003 (XLS) и >>>>>> модулям: Spreadsheet::ParseExcel, Spreadsheet::WriteExcel и Excel::Template. >>>>>> >>>>>> ?FastQueue ? как мы сделали свою очередь на Perl и Redis? тема ? >>>>>> выступления Ивана Соколова, teamlead REG.RU . >>>>>> Очередь ? один из наиболее используемых механизмов в >>>>>> программировании. Например, для интеграции с платежными системами или для >>>>>> обработки медиа-контента, загруженного пользователем, необходимо наличие >>>>>> очередей. >>>>>> >>>>>> В REG.RU тоже не обходятся без очередей. Поэтому потребность >>>>>> найти решение появилась достаточно давно. Учитывая специфику компании как >>>>>> доменного регистратора большинство существующих решений не подходило, и >>>>>> программисты решили ?написать свой велосипед?. Иван расскажет об >>>>>> архитектуре их очереди, ее возможностях, и в каких задачах она используется. >>>>>> >>>>>> ?Пластилиновый код: как перестать кодить и начать жить? ? доклад Елены >>>>>> Шишкиной, ведущего программиста Деньги Mail.Ru >>>>>> . Она покажет практический пример лени >>>>>> как двигателя прогресса в отдельно взятом веб-проекте: >>>>>> >>>>>> - Надоело писать код? Будем думать, как его не писать! >>>>>> >>>>>> - Боремся с однотипным кодом. Боремся с неоднотипным кодом. >>>>>> >>>>>> - Код, которого не существует, и код, который существует. >>>>>> >>>>>> - Следите за руками: программируем на конфигах! >>>>>> >>>>>> - Как жить дальше? >>>>>> >>>>>> >>>>>> Что бы мы могли лучше организовать наше мероприятие, пожалуйста, >>>>>> зарегистрируйтесь здесь >>>>>> >>>>>> >>>>>> -- >>>>>> С Уважением, >>>>>> Щербинин Павел >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> С Уважением, >>>>> Щербинин Павел >>>>> >>>>> -- >>>>> Moscow.pm mailing list >>>>> moscow-pm на pm.org | http://moscow.pm.org >>>>> >>>>> >>>> >>>> >>>> -- >>>> С уважением, >>>> Иван >>>> >>>> -- >>>> Moscow.pm mailing list >>>> moscow-pm на pm.org | http://moscow.pm.org >>>> >>>> >>> >>> >>> -- >>> С Уважением, >>> Щербинин Павел >>> >>> -- >>> Moscow.pm mailing list >>> moscow-pm на pm.org | http://moscow.pm.org >>> >>> >> >> >> -- >> Ksenia Bobrova >> Senior Perl Developer >> >> -- >> Moscow.pm mailing list >> moscow-pm на pm.org | http://moscow.pm.org >> >> > > > -- > С Уважением, > Щербинин Павел > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > > -- С уважением, Тимур Нозадзе ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From alexandre на frolov.pp.ru Thu Feb 19 22:51:07 2015 From: alexandre на frolov.pp.ru (Alexandre Frolov) Date: Fri, 20 Feb 2015 09:51:07 +0300 Subject: [Moscow.pm] =?utf-8?b?0KHRh9C40YLRi9Cy0LDRgtC10LvRjCBSRklEIC0g?= =?utf-8?b?0LrQsNC6INGB0LTQtdC70LDRgtGMINC00L7RgdGC0YPQvyDQvdCwIFBl?= =?utf-8?b?cmw/?= In-Reply-To: References: <02cc01d04ac8$c132c930$43985b90$@pp.ru> <02e901d04acc$b424aa70$1c6dff50$@pp.ru> <3C7A81EE-42D4-4A9F-9891-FAF7A59864C2@eremeev.ru> <034401d04c54$c61b34e0$52519ea0$@pp.ru> Message-ID: <007901d04cd9$9a1a1840$ce4e48c0$@pp.ru> Компания ?Умный склад? предлагает свой клиент для считывателя, у которого есть интерфейс REST. Наверное, это и есть оптимальный вариант? Можете ли вы оказать нам консультацию по автоматизации склада (бизнес-процессы и оборудование)? Есть ли у вас такой опыт? From: Moscow-pm [mailto:moscow-pm-bounces+alexandre=frolov.pp.ru на pm.org] On Behalf Of Dmitry Eremeev Sent: Thursday, February 19, 2015 6:19 PM To: Moscow.pm group Subject: Re: [Moscow.pm] Считыватель RFID - как сделать доступ на Perl? Дороговизна терминалов кроется в неубиваемости корпусов и экранов, радиусе вайфая и... это же не массмаркет. Там и операционки могут быть супердревние, а цена за 1 устройство как за 10 шестых айфонов. Например, моя любимая промышленная wifi точка Spectrum24 за штуку с чемто баксов уже в 2004 году не была чем-то удивительным. Предъявлять им "так дорого, а решения нет" несколько странновато, так как обычно делается кастом-решение в зависимости от потребностей клиента. По вашему случаю: Как вариант, в браузере на мобилке работает нечто, что в нужный момент ловит данные с rfid и отправляет, но тут сразу набор критических сценариев, от наличия открытой нужной странички в мобильном браузере и наличия курсора в нужном инпуте до общей дуболомности персонала, который обычно работает с такими устройствами. В конечном итоге проще стенд-алон сделать. Мы такие решения делали для терминалов еще лет 10 назад (PalmOS/WinCE), весьма наелись кейсов про пользователей, ломающих неломаемое. Yours Dmitry Eremeev CEO adPremium ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From aml на rulezz.ru Thu Feb 19 23:12:31 2015 From: aml на rulezz.ru (Alexander Lourier) Date: Fri, 20 Feb 2015 07:12:31 +0000 Subject: [Moscow.pm] =?utf-8?b?0KHRh9C40YLRi9Cy0LDRgtC10LvRjCBSRklEIC0g?= =?utf-8?b?0LrQsNC6INGB0LTQtdC70LDRgtGMINC00L7RgdGC0YPQvyDQvdCwIFBl?= =?utf-8?b?cmw/?= References: <02cc01d04ac8$c132c930$43985b90$@pp.ru> <02e901d04acc$b424aa70$1c6dff50$@pp.ru> <3C7A81EE-42D4-4A9F-9891-FAF7A59864C2@eremeev.ru> <034401d04c54$c61b34e0$52519ea0$@pp.ru> <007901d04cd9$9a1a1840$ce4e48c0$@pp.ru> Message-ID: Я делал автоматизацию склада на умных неубиваемых терминалах. Довольно интересная техническая игрушка, между прочим. Радиосистема позволяла установить несколько "базовых станций", терминалы умели делать роуминг между ними. Код для терминала писался на навороченном диалекте бейсика. На "серверной" стороне базовые станции подключались через обычный последовательный порт, дампили туда все полученные пакеты и принимали команды на отправку пакетов обратно. Небольшой демон открывал последовательный порт и работал сервером для терминалов и клиентом для складской базы данных. Можно было довольно интересные приложения писать - доставлять "заявки на сборку" напрямую на терминалы кладовщиков, отмечать товар как собранный, перепроверять штрихкоды, чтобы минимизировать пересортицу, печатать наклейки на пакетики и т.д. Не взлетело по причине дуболомности персонала. Заставить их сканировать штрихкод в момент взятия коробочки с полки - это что-то невероятно сложное. Им проще всё сначала собрать, потом взять сканер и всё разом отсканировать. Естественно что-то при этом забывается, предупреждения системы о том, что не весь товар собран, игнорируются, и как результат цели не достигаются. Они стараются отлынить от "лишнего действия" всеми силами. Никакие штрафы и выговоры не помогают. Я сдался, в итоге. Если у вас получится, буду завидовать :) On Fri Feb 20 2015 at 7:51:37 AM Alexandre Frolov wrote: > Компания ?Умный склад? предлагает свой клиент для считывателя, у которого > есть интерфейс REST. > > Наверное, это и есть оптимальный вариант? > > Можете ли вы оказать нам консультацию по автоматизации склада > (бизнес-процессы и оборудование)? Есть ли у вас такой опыт? > > > > *From:* Moscow-pm [mailto:moscow-pm-bounces+alexandre=frolov.pp.ru на pm.org] > *On Behalf Of *Dmitry Eremeev > *Sent:* Thursday, February 19, 2015 6:19 PM > > > *To:* Moscow.pm group > *Subject:* Re: [Moscow.pm] > > Считыватель RFID - как сделать доступ на Perl? > > > > Дороговизна терминалов кроется в неубиваемости корпусов и экранов, > радиусе вайфая и... это же не массмаркет. > > Там и операционки могут быть супердревние, а цена за 1 устройство как за > 10 шестых айфонов. > > > > Например, моя любимая промышленная wifi точка Spectrum24 за штуку с чемто > баксов уже в 2004 году не была чем-то удивительным. > > > > Предъявлять им "так дорого, а решения нет" несколько странновато, так как > обычно делается кастом-решение в зависимости от потребностей клиента. > > > > > > По вашему случаю: > > Как вариант, в браузере на мобилке работает нечто, что в нужный момент > ловит данные с rfid и отправляет, но тут сразу набор критических сценариев, > от наличия открытой нужной странички в мобильном браузере и наличия курсора > в нужном инпуте до общей дуболомности персонала, который обычно работает с > такими устройствами. > > > > В конечном итоге проще стенд-алон сделать. Мы такие решения делали для > терминалов еще лет 10 назад (PalmOS/WinCE), весьма наелись кейсов про > пользователей, ломающих неломаемое. > > > > Yours > > Dmitry Eremeev > > CEO adPremium > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From greyhard на gmail.com Fri Feb 20 05:39:50 2015 From: greyhard на gmail.com (=?UTF-8?B?0JTQtdC90LjRgSDQmNC70YzQuNC90YvRhQ==?=) Date: Fri, 20 Feb 2015 17:39:50 +0400 Subject: [Moscow.pm] =?utf-8?b?0KHRh9C40YLRi9Cy0LDRgtC10LvRjCBSRklEIC0g?= =?utf-8?b?0LrQsNC6INGB0LTQtdC70LDRgtGMINC00L7RgdGC0YPQvyDQvdCwIFBl?= =?utf-8?b?cmw/?= In-Reply-To: References: <02cc01d04ac8$c132c930$43985b90$@pp.ru> <02e901d04acc$b424aa70$1c6dff50$@pp.ru> <3C7A81EE-42D4-4A9F-9891-FAF7A59864C2@eremeev.ru> <034401d04c54$c61b34e0$52519ea0$@pp.ru> <007901d04cd9$9a1a1840$ce4e48c0$@pp.ru> Message-ID: У нас для этих целей был заюзан андроид девайс с Блютус сканером , приложение на андроид тонкий клиент и сервереая част на перл. Все в восторге :) и у Нас небыло проблем с персоналом. Видимо повезло. пятница, 20 февраля 2015 г. пользователь Alexander Lourier написал: > Я делал автоматизацию склада на умных неубиваемых терминалах. Довольно > интересная техническая игрушка, между прочим. Радиосистема позволяла > установить несколько "базовых станций", терминалы умели делать роуминг > между ними. Код для терминала писался на навороченном диалекте бейсика. На > "серверной" стороне базовые станции подключались через обычный > последовательный порт, дампили туда все полученные пакеты и принимали > команды на отправку пакетов обратно. Небольшой демон открывал > последовательный порт и работал сервером для терминалов и клиентом для > складской базы данных. Можно было довольно интересные приложения писать - > доставлять "заявки на сборку" напрямую на терминалы кладовщиков, отмечать > товар как собранный, перепроверять штрихкоды, чтобы минимизировать > пересортицу, печатать наклейки на пакетики и т.д. > > Не взлетело по причине дуболомности персонала. Заставить их сканировать > штрихкод в момент взятия коробочки с полки - это что-то невероятно сложное. > Им проще всё сначала собрать, потом взять сканер и всё разом отсканировать. > Естественно что-то при этом забывается, предупреждения системы о том, что > не весь товар собран, игнорируются, и как результат цели не достигаются. > Они стараются отлынить от "лишнего действия" всеми силами. Никакие штрафы и > выговоры не помогают. Я сдался, в итоге. > > Если у вас получится, буду завидовать :) > > > On Fri Feb 20 2015 at 7:51:37 AM Alexandre Frolov > wrote: > >> Компания ?Умный склад? предлагает свой клиент для считывателя, у которого >> есть интерфейс REST. >> >> Наверное, это и есть оптимальный вариант? >> >> Можете ли вы оказать нам консультацию по автоматизации склада >> (бизнес-процессы и оборудование)? Есть ли у вас такой опыт? >> >> >> >> *From:* Moscow-pm [mailto:moscow-pm- >> bounces+alexandre= >> frolov.pp.ru на pm.org ] >> *On Behalf Of *Dmitry Eremeev >> *Sent:* Thursday, February 19, 2015 6:19 PM >> >> >> *To:* Moscow.pm group >> *Subject:* Re: [Moscow.pm] >> >> Считыватель RFID - как сделать доступ на Perl? >> >> >> >> Дороговизна терминалов кроется в неубиваемости корпусов и экранов, >> радиусе вайфая и... это же не массмаркет. >> >> Там и операционки могут быть супердревние, а цена за 1 устройство как за >> 10 шестых айфонов. >> >> >> >> Например, моя любимая промышленная wifi точка Spectrum24 за штуку с чемто >> баксов уже в 2004 году не была чем-то удивительным. >> >> >> >> Предъявлять им "так дорого, а решения нет" несколько странновато, так как >> обычно делается кастом-решение в зависимости от потребностей клиента. >> >> >> >> >> >> По вашему случаю: >> >> Как вариант, в браузере на мобилке работает нечто, что в нужный момент >> ловит данные с rfid и отправляет, но тут сразу набор критических сценариев, >> от наличия открытой нужной странички в мобильном браузере и наличия курсора >> в нужном инпуте до общей дуболомности персонала, который обычно работает с >> такими устройствами. >> >> >> >> В конечном итоге проще стенд-алон сделать. Мы такие решения делали для >> терминалов еще лет 10 назад (PalmOS/WinCE), весьма наелись кейсов про >> пользователей, ломающих неломаемое. >> >> >> >> Yours >> >> Dmitry Eremeev >> >> CEO adPremium >> -- >> Moscow.pm mailing list >> moscow-pm на pm.org | >> http://moscow.pm.org >> > -- С уважением. Ильиных Денис Программист Компания "GT-Shop.ru" Телефон: +7(963) 995-7616 ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From alexandre на frolov.pp.ru Fri Feb 20 05:45:06 2015 From: alexandre на frolov.pp.ru (Alexandre Frolov) Date: Fri, 20 Feb 2015 16:45:06 +0300 Subject: [Moscow.pm] =?utf-8?b?0KHRh9C40YLRi9Cy0LDRgtC10LvRjCBSRklEIC0g?= =?utf-8?b?0LrQsNC6INGB0LTQtdC70LDRgtGMINC00L7RgdGC0YPQvyDQvdCwIFBl?= =?utf-8?b?cmw/?= In-Reply-To: References: <02cc01d04ac8$c132c930$43985b90$@pp.ru> <02e901d04acc$b424aa70$1c6dff50$@pp.ru> <3C7A81EE-42D4-4A9F-9891-FAF7A59864C2@eremeev.ru> <034401d04c54$c61b34e0$52519ea0$@pp.ru> <007901d04cd9$9a1a1840$ce4e48c0$@pp.ru> Message-ID: <013f01d04d13$6fac61f0$4f0525d0$@pp.ru> А что это был за девайс и что за сканер? Вы приложение для Андроида сами писали или заказывали вместе со сканером? From: Moscow-pm [mailto:moscow-pm-bounces+alexandre=frolov.pp.ru на pm.org] On Behalf Of Денис Ильиных Sent: Friday, February 20, 2015 4:40 PM To: Moscow.pm group Subject: Re: [Moscow.pm] Считыватель RFID - как сделать доступ на Perl? У нас для этих целей был заюзан андроид девайс с Блютус сканером , приложение на андроид тонкий клиент и сервереая част на перл. Все в восторге :) и у Нас небыло проблем с персоналом. Видимо повезло. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From dmitry на eremeev.ru Fri Feb 20 05:53:00 2015 From: dmitry на eremeev.ru (Dmitry Eremeev) Date: Fri, 20 Feb 2015 16:53:00 +0300 Subject: [Moscow.pm] =?koi8-r?b?897J1NnXwdTFzNggUkZJRCAtIMvByyDTxMXMwdTY?= =?koi8-r?b?IMTP09TV0CDOwSBQZXJsPw==?= In-Reply-To: <013f01d04d13$6fac61f0$4f0525d0$@pp.ru> References: <02cc01d04ac8$c132c930$43985b90$@pp.ru> <02e901d04acc$b424aa70$1c6dff50$@pp.ru> <3C7A81EE-42D4-4A9F-9891-FAF7A59864C2@eremeev.ru> <034401d04c54$c61b34e0$52519ea0$@pp.ru> <007901d04cd9$9a1a1840$ce4e48c0$@pp.ru> <013f01d04d13$6fac61f0$4f0525d0$@pp.ru> Message-ID: <95CE3E8E-9265-49C0-8822-DCD199F81D15@eremeev.ru> На самом деле есть зоопарк железок и у каждого поставщика всегда есть несколько прикормленных разрабов, которые весьма ритмично собирают клиента под задачи. Yours Dmitry Eremeev CEO adPremium Russia / office: +7 499 703 32 07 UK / office: +44 870 295 24 46 Skype: eremeev.ru https://linkedin.com/in/dimkae https://facebook.com/dimkae > 20 февр. 2015 г., в 16:45, Alexandre Frolov написал(а): > > А что это был за девайс и что за сканер? > Вы приложение для Андроида сами писали или заказывали вместе со сканером? > > From: Moscow-pm [mailto:moscow-pm-bounces+alexandre=frolov.pp.ru на pm.org] On Behalf Of Денис Ильиных > Sent: Friday, February 20, 2015 4:40 PM > To: Moscow.pm group > Subject: Re: [Moscow.pm] Считыватель RFID - как сделать доступ на Perl? > > У нас для этих целей был заюзан андроид девайс с Блютус сканером , приложение на андроид тонкий клиент и сервереая част на перл. Все в восторге :) и у Нас небыло проблем с персоналом. Видимо повезло. > > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mi на ya.ru Sat Feb 21 16:32:36 2015 From: mi на ya.ru (Nikolay Mishin) Date: Sun, 22 Feb 2015 03:32:36 +0300 Subject: [Moscow.pm] DBIx::SearchBuilder In-Reply-To: References: Message-ID: <3150401424565156@web27o.yandex.ru> Я бы дописал этот оператор в модуле: https://metacpan.org/source/ALEXMV/DBIx-SearchBuilder-1.66/lib/DBIx/SearchBuilder.pm if ( $args{'OPERATOR'} ) { #If it's a like, we supply the %s around the search term if ( $args{'OPERATOR'} =~ /LIKE/i ) { $args{'VALUE'} = "%" . $args{'VALUE'} . "%"; } elsif ( $args{'OPERATOR'} =~ /STARTSWITH/i ) { $args{'VALUE'} = $args{'VALUE'} . "%"; } elsif ( $args{'OPERATOR'} =~ /ENDSWITH/i ) { $args{'VALUE'} = "%" . $args{'VALUE'}; } elsif ( $args{'OPERATOR'} =~ /\bIN$/i ) { if ( blessed $args{'VALUE'} && $args{'VALUE'}->isa(__PACKAGE__) ) { # if no columns selected then select id local $args{'VALUE'}{'columns'} = $args{'VALUE'}{'columns'}; unless ( $args{'VALUE'}{'columns'} ) { $args{'VALUE'}->Column( FIELD => 'id' ); } elsif ( @{ $args{'VALUE'}{'columns'} } > 1 ) { warn "Collection in '$args{OPERATOR}' with more than one column selected, using first"; splice @{ $args{'VALUE'}{'columns'} }, 1; } $args{'VALUE'} = '('. $args{'VALUE'}->BuildSelectQuery .')'; $args{'QUOTEVALUE'} = 0; } elsif ( ref $args{'VALUE'} ) { if ( $args{'QUOTEVALUE'} ) { my $dbh = $self->_Handle->dbh; $args{'VALUE'} = join ', ', map $dbh->quote( $_ ), @{ $args{'VALUE'} }; } else { $args{'VALUE'} = join ', ', @{ $args{'VALUE'} }; } $args{'VALUE'} = "($args{VALUE})"; $args{'QUOTEVALUE'} = 0; } else { # otherwise behave in backwards compatible way } } $args{'OPERATOR'} =~ s/(?:MATCHES|ENDSWITH|STARTSWITH)/LIKE/i; if ( $args{'OPERATOR'} =~ /IS/i ) { $args{'VALUE'} = 'NULL'; $args{'QUOTEVALUE'} = 0; } } Добавить a > b 18.02.2015, 18:18, "Алексей Мышкин" : > Привет всем! > > Возник довольно срочный вопрос - как в DBIx::SearchBuilder сделать такое (если хоть кто-то в курсе): > > SELECT a, b > FROM t > WHERE a > b > > Используется этот модуль в Request Tracker'e > > -- > С уважением, > Мышкин Алексей. > > , > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org -- С уважением Николай Мишин From mail на knutov.com Sat Feb 21 19:39:58 2015 From: mail на knutov.com (Nick Knutov) Date: Sun, 22 Feb 2015 08:39:58 +0500 Subject: [Moscow.pm] perl5i Message-ID: <54E94F8E.9000206@knutov.com> Увидел статью про perl5i, почитал подбронее, заинтересовался. Кто использует в продакшене, особенно в проектах с нагрузкой - какие есть минусы? Несовместимости (5.14 и 5.20, если это важно)? Что со скоростью и потреблением памяти? -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 From sergey.aleynikov на gmail.com Sun Feb 22 00:57:17 2015 From: sergey.aleynikov на gmail.com (Sergey Aleynikov) Date: Sun, 22 Feb 2015 11:57:17 +0300 Subject: [Moscow.pm] perl5i In-Reply-To: <54E94F8E.9000206@knutov.com> References: <54E94F8E.9000206@knutov.com> Message-ID: Добрый день, > Что со скоростью Он автоматом добавляет вам 'no autovivification' и 'use autobox' - о производительности можно забыть. Best regards, Sergey Aleynikov From 0body0 на rambler.ru Sun Feb 22 08:32:59 2015 From: 0body0 на rambler.ru (=?UTF-8?B?0JDQvdCw0YLQvtC70LjQuSDQk9GA0LjRiNCw0LXQsg==?=) Date: Sun, 22 Feb 2015 19:32:59 +0300 Subject: [Moscow.pm] PerlXS + C++ Message-ID: <54EA04BB.9060401@rambler.ru> Хотел написать расширение для Perl на C++, причем нужно слинковать с C++ либой. C C++ как-то в прошлый раз было совсем плохо и не взлетело пришлось писать на голом C... Писать и компилировать c++ и создавать perl extension я по отдельности умею, а вот вместе ... У либы зависимости минимальные и даже есть исходники. 1) Как сделать, какие есть подводные камни? Может есть примеры рабочего кода, Можно ли использовать STL, если да то как? 2) Менее нужно, но тоже животрепещуще - Как отлаживать Perl extention? Ссылки будет достаточно, если есть такие. From sergey.aleynikov на gmail.com Sun Feb 22 09:07:06 2015 From: sergey.aleynikov на gmail.com (Sergey Aleynikov) Date: Sun, 22 Feb 2015 21:07:06 +0400 Subject: [Moscow.pm] PerlXS + C++ In-Reply-To: <54EA04BB.9060401@rambler.ru> References: <54EA04BB.9060401@rambler.ru> Message-ID: Добрый день, > 1) Как сделать, какие есть подводные камни? > Может есть примеры рабочего кода, Посмотрите вот этот доклад - http://www.youtube.com/watch?v=yDm6KZHtcHM. Там есть примеры минимальных мейкфайлов и несколько подводных камней описаны. > Можно ли использовать STL, если да то как? Можно, как и в любой другой плюсовой библиотеке. > 2) Менее нужно, но тоже животрепещуще - Как отлаживать Perl extention? Как всегда, GDB) Best regards, Sergey Aleynikov From mail на knutov.com Sun Feb 22 16:42:05 2015 From: mail на knutov.com (Nick Knutov) Date: Mon, 23 Feb 2015 05:42:05 +0500 Subject: [Moscow.pm] XML::RSS vs Yandex Message-ID: <54EA775D.4060103@knutov.com> Подскажите, что сделать с XML::RSS, чтобы он позволил добавить http://example.net/logo.png http://example.net/logo.png ? my $rss = new XML::RSS( version => '2.0', encoding=>'UTF-8', encode_output => 0 ); $rss->add_module(prefix=>'yandex', uri=>'http://news.yandex.ru') if $yandex; $rss->channel( title => $rss_channel_title, link => $rss_channel_link, language => 'ru', description => $rss_channel_description, lastBuildDate => $lastBuildDate, copyright => $rss_channel_copyright, yandex => { logo => $rss_yandex_logo, }, ttl => 60, ); Но я так и не смог понять как добавить второй yandex:logo с указанием type -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 From chesnokov.ilya на gmail.com Mon Feb 23 02:39:32 2015 From: chesnokov.ilya на gmail.com (Ilya Chesnokov) Date: Mon, 23 Feb 2015 14:39:32 +0400 Subject: [Moscow.pm] PerlXS + C++ In-Reply-To: <54EA04BB.9060401@rambler.ru> References: <54EA04BB.9060401@rambler.ru> Message-ID: Еще можно попробовать Inline::Module (+ Inline::CPP), работа над которым была недавно проспонсирована The Perl Foundation: http://news.perlfoundation.org/2014/12/grant-report-inlinecpp---final.html 22 февраля 2015 г., 19:32 пользователь Анатолий Гришаев <0body0 на rambler.ru> написал: > Хотел написать расширение для Perl на C++, причем нужно слинковать с C++ > либой. > C C++ как-то в прошлый раз было совсем плохо и не взлетело пришлось писать > на голом C... > > Писать и компилировать c++ и создавать perl extension я по отдельности умею, > а вот вместе ... > > У либы зависимости минимальные и даже есть исходники. > 1) Как сделать, какие есть подводные камни? > Может есть примеры рабочего кода, > Можно ли использовать STL, если да то как? > > 2) Менее нужно, но тоже животрепещуще - Как отлаживать Perl extention? > Ссылки будет достаточно, если есть такие. > > > > > > > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org -- Best regards, Ilya Chesnokov From dim0xff на gmail.com Mon Feb 23 03:07:10 2015 From: dim0xff на gmail.com (Dmitry L.) Date: Mon, 23 Feb 2015 15:07:10 +0400 Subject: [Moscow.pm] XML::RSS vs Yandex In-Reply-To: <54EA775D.4060103@knutov.com> References: <54EA775D.4060103@knutov.com> Message-ID: Там по коду не получится ? XML::RSS::Private::Output::Base/_out_ns_tag Из коробки можно сделать только так: В принципе можно обернуть _out_ns_tag { no strict 'subs'; my $orig = \&XML::RSS::Private::Output::Base::_out_ns_tag; *XML::RSS::Private::Output::Base::_out_ns_tag = sub { my ( $self, $prefix, $tag, $inner ) = @_; if ( ref($inner) eq "HASH" && exists( $inner->{__force_out_tag} ) ) { delete $inner->{__force_out_tag}; return $self->_out_tag( "${prefix}:${tag}", $inner ); } else { $orig->(@_); } }; } $rss->channel( title => $rss_channel_title, link => $rss_channel_link, language => 'ru', description => $rss_channel_description, lastBuildDate => $lastBuildDate, copyright => $rss_channel_copyright, yandex => [ { el => 'logo', val => $rss_yandex_logo }, { el => 'logo', val => { __force_out_tag => 1, type => 'square', content => $rss_yandex_logo, } }, ], ttl => 60, ); On 23 February 2015 at 03:42, Nick Knutov wrote: > Подскажите, что сделать с XML::RSS, чтобы он позволил добавить > > http://example.net/logo.png > http://example.net/logo.png > > ? > > my $rss = new XML::RSS( version => '2.0', encoding=>'UTF-8', > encode_output => 0 ); > $rss->add_module(prefix=>'yandex', uri=>'http://news.yandex.ru') if $yandex; > $rss->channel( > title => $rss_channel_title, > link => $rss_channel_link, > language => 'ru', > description => $rss_channel_description, > lastBuildDate => $lastBuildDate, > copyright => $rss_channel_copyright, > yandex => { > logo => $rss_yandex_logo, > }, > ttl => 60, > ); > > Но я так и не смог понять как добавить второй yandex:logo с указанием type > > > > -- > Best Regards, > Nick Knutov > http://knutov.com > ICQ: 272873706 > Voice: +7-904-84-23-130 > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org -- //wbr, Dmitry L. From defender13 на gmail.com Tue Feb 24 10:36:26 2015 From: defender13 на gmail.com (defender13) Date: Wed, 25 Feb 2015 01:36:26 +0700 Subject: [Moscow.pm] =?utf-8?b?0J/RgNCw0LLQuNC70YzQvdC+0LUg0LjRgdC/0L4=?= =?utf-8?b?0LvRjNC30L7QstCw0L3QuNC1INGB0YHRi9C70LrQuCDQsiBhcHAt0Lo=?= =?utf-8?b?0L7QvdGC0YDQvtC70LvQtdGA0LUgTW9qbw==?= Message-ID: Доброго времени суток всем! Везде молчат, есть надежда что ответят тут. Опыта в перле немного, но есть проблема которую хочется решить. В контроллере приложения есть код задающий секретную фразу для кукисов. Разработчики Mojo предлагают $self->secrets ('SeCreTe'); Но мне не нравиться каждый раз использовать указатель $self, т.к. не всегда понятно куда он ссылается. Правильно ли использовать my $s = $self->secrets; $s = $self->secrets(' SeCreTe '); Спасибо заранее за ответы. В гугл посылать можно. -- С Уважением, Ярослав. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From parserpro на gmail.com Tue Feb 24 10:46:15 2015 From: parserpro на gmail.com (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0JzRi9GI0LrQuNC9?=) Date: Tue, 24 Feb 2015 21:46:15 +0300 Subject: [Moscow.pm] DBIx::SearchBuilder In-Reply-To: <3150401424565156@web27o.yandex.ru> References: <3150401424565156@web27o.yandex.ru> Message-ID: Мой вопрос решился немного проще, с использованием 'QUOTEVALUE' => 1 в запросе. Так вместо значения я смог подставить имя второй колонки для сравнения. 2015-02-22 3:32 GMT+03:00 Nikolay Mishin : > Я бы дописал этот оператор в модуле: > > https://metacpan.org/source/ALEXMV/DBIx-SearchBuilder-1.66/lib/DBIx/SearchBuilder.pm > > if ( $args{'OPERATOR'} ) { > #If it's a like, we supply the %s around the search term > if ( $args{'OPERATOR'} =~ /LIKE/i ) { > $args{'VALUE'} = "%" . $args{'VALUE'} . "%"; > } > elsif ( $args{'OPERATOR'} =~ /STARTSWITH/i ) { > $args{'VALUE'} = $args{'VALUE'} . "%"; > } > elsif ( $args{'OPERATOR'} =~ /ENDSWITH/i ) { > $args{'VALUE'} = "%" . $args{'VALUE'}; > } > elsif ( $args{'OPERATOR'} =~ /\bIN$/i ) { > if ( blessed $args{'VALUE'} && > $args{'VALUE'}->isa(__PACKAGE__) ) { > # if no columns selected then select id > local $args{'VALUE'}{'columns'} = > $args{'VALUE'}{'columns'}; > unless ( $args{'VALUE'}{'columns'} ) { > $args{'VALUE'}->Column( FIELD => 'id' ); > } elsif ( @{ $args{'VALUE'}{'columns'} } > 1 ) { > warn "Collection in '$args{OPERATOR}' with more than > one column selected, using first"; > splice @{ $args{'VALUE'}{'columns'} }, 1; > } > $args{'VALUE'} = '('. $args{'VALUE'}->BuildSelectQuery > .')'; > $args{'QUOTEVALUE'} = 0; > } > elsif ( ref $args{'VALUE'} ) { > if ( $args{'QUOTEVALUE'} ) { > my $dbh = $self->_Handle->dbh; > $args{'VALUE'} = join ', ', map $dbh->quote( $_ ), @{ > $args{'VALUE'} }; > } else { > $args{'VALUE'} = join ', ', @{ $args{'VALUE'} }; > } > $args{'VALUE'} = "($args{VALUE})"; > $args{'QUOTEVALUE'} = 0; > } > else { > # otherwise behave in backwards compatible way > } > } > $args{'OPERATOR'} =~ s/(?:MATCHES|ENDSWITH|STARTSWITH)/LIKE/i; > > if ( $args{'OPERATOR'} =~ /IS/i ) { > $args{'VALUE'} = 'NULL'; > $args{'QUOTEVALUE'} = 0; > } > } > Добавить a > b > > 18.02.2015, 18:18, "Алексей Мышкин" : > > Привет всем! > > > > Возник довольно срочный вопрос - как в DBIx::SearchBuilder сделать такое > (если хоть кто-то в курсе): > > > > SELECT a, b > > FROM t > > WHERE a > b > > > > Используется этот модуль в Request Tracker'e > > > > -- > > С уважением, > > Мышкин Алексей. > > > > , > > > > -- > > Moscow.pm mailing list > > moscow-pm на pm.org | http://moscow.pm.org > > -- > С уважением > Николай Мишин > > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org > -- С уважением, Мышкин Алексей. ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From grisxa на gmail.com Tue Feb 24 11:23:11 2015 From: grisxa на gmail.com (Grigory Batalov) Date: Tue, 24 Feb 2015 22:23:11 +0300 Subject: [Moscow.pm] =?utf-8?b?W1NQQU1dIFJlOiAg0J/RgNCw0LLQuNC70YzQvdC+?= =?utf-8?b?0LUg0LjRgdC/0L7Qu9GM0LfQvtCy0LDQvdC40LUg0YHRgdGL0LvQutC4INCy?= =?utf-8?b?IGFwcC3QutC+0L3RgtGA0L7Qu9C70LXRgNC1IE1vam8=?= In-Reply-To: References: Message-ID: <20150224222311.3fb913ab@gbatalov> В Wed, 25 Feb 2015 01:36:26 +0700 defender13 пишет: > В контроллере приложения есть код задающий секретную фразу для > кукисов. Разработчики Mojo предлагают > $self->secrets ('SeCreTe'); > Но мне не нравиться каждый раз использовать указатель $self, т.к. не > всегда понятно куда он ссылается. Если код в контроллере, то $self ссылается на контроллер, так? :-) Вообще, авторы пишут, что secrets - метод приложения, и я его вызываю из App::startup() http://mojolicio.us/perldoc/Mojolicious#secrets From mail на knutov.com Tue Feb 24 14:03:54 2015 From: mail на knutov.com (Nick Knutov) Date: Wed, 25 Feb 2015 03:03:54 +0500 Subject: [Moscow.pm] XML::RSS vs Yandex In-Reply-To: References: <54EA775D.4060103@knutov.com> Message-ID: <54ECF54A.9020804@knutov.com> Спасибо, ваш вариант прекрасно работает. А вообще - может это лучше делать другим модулем? Задача выглядит примерно так - под разных живых людей и разные сервисы вроде яндекс.новостей и новотеки собирать фид по их требованиям, который гарантированно будет валидным и правильным, при этом не зная ничего про XML и весьма поверхностно представляя стандарты и спецификации в области рсс. 23.02.2015 16:07, Dmitry L. пишет: > Там по коду не получится ? XML::RSS::Private::Output::Base/_out_ns_tag > > Из коробки можно сделать только так: > > > В принципе можно обернуть _out_ns_tag > [...] > > On 23 February 2015 at 03:42, Nick Knutov wrote: >> Подскажите, что сделать с XML::RSS, чтобы он позволил добавить >> >> http://example.net/logo.png >> http://example.net/logo.png >> >> ? >> >> [..] >> >> Но я так и не смог понять как добавить второй yandex:logo с указанием type >> -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 From mail на knutov.com Thu Feb 26 07:44:44 2015 From: mail на knutov.com (Nick Knutov) Date: Thu, 26 Feb 2015 20:44:44 +0500 Subject: [Moscow.pm] =?utf-8?b?0JDQu9GM0YLQtdGA0L3QsNGC0LjQstGLIEZpbGU6?= =?utf-8?q?=3ASlurp?= Message-ID: <54EF3F6C.7040907@knutov.com> Искал альтернативы File::Slurp, увидел http://blogs.perl.org/users/leon_timmermans/2013/05/why-you-dont-need-fileslurp.html , сделал бенчмарки https://gist.github.com/knutov/8c9077790f925f1e336f Там табличка большая по ширине, поэтому сюда не вставляю. Какие еще есть хорошие варианты быстро прочитать текстовые файлы (которые могут быть с ютф или без) ? -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 From maxim.vuets на gmail.com Thu Feb 26 08:14:42 2015 From: maxim.vuets на gmail.com (Maxim Vuets) Date: Thu, 26 Feb 2015 17:14:42 +0100 Subject: [Moscow.pm] =?utf-8?b?0JDQu9GM0YLQtdGA0L3QsNGC0LjQstGLIEZpbGU6?= =?utf-8?q?=3ASlurp?= In-Reply-To: <54EF3F6C.7040907@knutov.com> References: <54EF3F6C.7040907@knutov.com> Message-ID: 2015-02-26 16:44 GMT+01:00 Nick Knutov : > Какие еще есть хорошие варианты быстро прочитать текстовые файлы > (которые могут быть с ютф или без) ? https://metacpan.org/pod/File::Slurper "This module tries to make it as easy as possible to read and write files correctly and fast. The most correct way of doing this is not always obvious (e.g. #83126 [https://rt.cpan.org/Public/Bug/Display.html?id=83126]), and just as often the most obvious correct way is not the fastest correct way. This module hides away all such complications behind an easy intuitive interface." From theathlet на yandex.ru Thu Feb 26 08:14:39 2015 From: theathlet на yandex.ru (TheAthlete) Date: Thu, 26 Feb 2015 19:14:39 +0300 Subject: [Moscow.pm] =?utf-8?b?0JDQu9GM0YLQtdGA0L3QsNGC0LjQstGLIEZpbGU6?= =?utf-8?q?=3ASlurp?= In-Reply-To: <54EF3F6C.7040907@knutov.com> References: <54EF3F6C.7040907@knutov.com> Message-ID: Perl6::Slurp Nick Knutov писал(а) в своём письме Thu, 26 Feb 2015 18:44:44 +0300: > Искал альтернативы File::Slurp, увидел > http://blogs.perl.org/users/leon_timmermans/2013/05/why-you-dont-need-fileslurp.html > , сделал бенчмарки https://gist.github.com/knutov/8c9077790f925f1e336f > > Там табличка большая по ширине, поэтому сюда не вставляю. > > Какие еще есть хорошие варианты быстро прочитать текстовые файлы > (которые могут быть с ютф или без) ? > -- Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/ From maxim.vuets на gmail.com Thu Feb 26 08:20:49 2015 From: maxim.vuets на gmail.com (Maxim Vuets) Date: Thu, 26 Feb 2015 17:20:49 +0100 Subject: [Moscow.pm] =?utf-8?b?0JDQu9GM0YLQtdGA0L3QsNGC0LjQstGLIEZpbGU6?= =?utf-8?q?=3ASlurp?= In-Reply-To: References: <54EF3F6C.7040907@knutov.com> Message-ID: On 26 February 2015 at 17:14, Maxim Vuets wrote: > 2015-02-26 16:44 GMT+01:00 Nick Knutov : >> Какие еще есть хорошие варианты быстро прочитать текстовые файлы >> (которые могут быть с ютф или без) ? > > https://metacpan.org/pod/File::Slurper > > "This module tries to make it as easy as possible to read and write > files correctly and fast. The most correct way of doing this is not > always obvious (e.g. #83126 > [https://rt.cpan.org/Public/Bug/Display.html?id=83126]), and just as > often the most obvious correct way is not the fastest correct way. > This module hides away all such complications behind an easy intuitive > interface." Вспомнил откуда это растёт: http://perlweekly.com/archive/170.html "Leon Timmermans released File::Slurper, previously known as File::Slurp::Sane. It's intended as a replacement for File::Slurp, which has a number of problems." From mail на knutov.com Thu Feb 26 09:29:51 2015 From: mail на knutov.com (Nick Knutov) Date: Thu, 26 Feb 2015 22:29:51 +0500 Subject: [Moscow.pm] =?koi8-r?b?4czY1MXSzsHUydfZIEZpbGU6OlNsdXJw?= In-Reply-To: References: <54EF3F6C.7040907@knutov.com> Message-ID: <54EF580F.4050207@knutov.com> Добавил в сравнение https://gist.github.com/knutov/8c9077790f925f1e336f Внезапно, и не могу понять почему, с utf8 Path::Tiny быстрее, хотя с latin1 наоборот, и в 4 раза медленнее. 26.02.2015 21:14, Maxim Vuets пишет: > 2015-02-26 16:44 GMT+01:00 Nick Knutov : >> Какие еще есть хорошие варианты быстро прочитать текстовые файлы >> (которые могут быть с ютф или без) ? > > https://metacpan.org/pod/File::Slurper > > "This module tries to make it as easy as possible to read and write > files correctly and fast. The most correct way of doing this is not > always obvious (e.g. #83126 > [https://rt.cpan.org/Public/Bug/Display.html?id=83126]), and just as > often the most obvious correct way is not the fastest correct way. > This module hides away all such complications behind an easy intuitive > interface." > -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130 From maxim.vuets на gmail.com Thu Feb 26 11:29:21 2015 From: maxim.vuets на gmail.com (Maxim Vuets) Date: Thu, 26 Feb 2015 20:29:21 +0100 Subject: [Moscow.pm] =?utf-8?b?0JDQu9GM0YLQtdGA0L3QsNGC0LjQstGLIEZpbGU6?= =?utf-8?q?=3ASlurp?= In-Reply-To: <54EF580F.4050207@knutov.com> References: <54EF3F6C.7040907@knutov.com> <54EF580F.4050207@knutov.com> Message-ID: On 26 February 2015 at 18:29, Nick Knutov wrote: > Добавил в сравнение https://gist.github.com/knutov/8c9077790f925f1e336f Если интересно мерять разные всякие, тогда стоит добавить также: - slurp_raw из Path::Tiny - IO::All, https://metacpan.org/pod/distribution/IO-All/lib/IO/All.pod - File::Slurp::Tiny, https://metacpan.org/pod/File::Slurp::Tiny - ??? https://github.com/JRaspass/File-Slurp-XS А потом оформить в виде и стиле http://neilb.org/reviews/ (-; > Внезапно, и не могу понять почему, с utf8 Path::Tiny быстрее, хотя с > latin1 наоборот, и в 4 раза медленнее. Дикое поверхностное предположение: latin1 есть кодировка отличная от той, что используется внутри perl-а для хранения данных, и следовательно нужно перекодировать и проверять. From mons на cpan.org Sat Feb 28 19:15:18 2015 From: mons на cpan.org (Mons Anderson) Date: Sun, 1 Mar 2015 07:15:18 +0400 Subject: [Moscow.pm] perl5i In-Reply-To: <54E94F8E.9000206@knutov.com> References: <54E94F8E.9000206@knutov.com> Message-ID: Лично я не понимаю зачем всё это. Почти любое из описанных действий делается собственными средствами перла в одну строчку. Есть, конечно, интересные вещи, но на мой взгляд данный модуль пытается сделать из перла другой язык. 2015-02-22 6:39 GMT+03:00 Nick Knutov : > Увидел статью про perl5i, почитал подбронее, заинтересовался. > > Кто использует в продакшене, особенно в проектах с нагрузкой - какие > есть минусы? Несовместимости (5.14 и 5.20, если это важно)? > Что со скоростью и потреблением памяти? > > > -- > Best Regards, > Nick Knutov > http://knutov.com > ICQ: 272873706 > Voice: +7-904-84-23-130 > -- > Moscow.pm mailing list > moscow-pm на pm.org | http://moscow.pm.org -- Best wishes, Vladimir V. Perepelitsa aka Mons Anderson , http://github.com/Mons