LINUX.ORG.RU

Perl 5.20

 ,


3

8

Несколько часов назад состоялся релиз новой мажорной версии языка программирования Perl. Разработка Perl 5.20.0 заняла примерно 12 месяцев с момента выпуска Perl 5.18.0 и содержит около 470 000 строк изменений в 2 900 файлах от 124 авторов.

В этой версии достаточно много новшеств:

  • Subroutine signatures
    То, чего многие так ждали, а другие возражали привычным «ненужно»
    sub foo($bar, $baz) {
      print "\$bar=$bar, \$baz=$baz"
    }
    
    Таким образом теперь можно определять параметры функции в скобках после её имени. Есть и возможность задать значение по умолчанию
    sub bar($foo, $baz=10) {
      print '$foo+$baz=', $foo+$baz
    }
    
    О других особенностях новой экспериментальной возможности можно прочитать в perldoc perlsub. Стоит отметить, что старый механизм получения параметров функции из @_ также остаётся в силе.
  • Новый синтаксис для получения среза ключей-значений/индексов-значений для хешей/массивов
    %hash{...} и %array[...] соответственно
    %h = (blonk => 2, foo => 3, squink => 5, bar => 8);
    %subset = %h{'foo', 'bar'}; # срез ключ-значения для хеша
    # %subset теперь (foo => 3, bar => 8)
    
    @a = "a".."z";
    @list = %a[3,4,6]; # срез индекс-значения для массива
    # @list теперь (3, "d", 4, "e", 6, "g")
    
  • Постфиксное разыменовывание
    К старому доброму разыменовыванию ссылок, навроде @$foo и %$bar, был добавлен вариант постфиксного разыменовывания: $foo->@* и $bar->%* соответственно. Синтаксис для других типов ссылок можно посмотреть в perldoc perlref
  • Механизм копирования при записи (copy-on-write) для строк
    Теперь при присвоении переменной значения другой строковой переменной не создаётся копии буфера вплоть до тех пор, пока значение одной из переменных не будет изменено. Это увеличивает скорость присвоения и снижает потребление памяти. Теперь не потребуется передавать в функцию строковую переменную по ссылке, чтобы увеличить производительность.

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

★★★

Проверено: Aceler ()
Последнее исправление: cetjs2 (всего исправлений: 2)
Ответ на: комментарий от anonymous

А перл - да. Заказчики были, есть и будут

cobol тоже мертвый язык и за поддержку говна мамонта, на нем писанного, все еще платят. за ошибки всегда приходится платить. но одно дело - ошибки молодости, когда поставили не на ту лошадь потому, что выбирать особо не из чего было, и совсем другое, когда продолжают ставить на лошадь, которая ни разу не выигрывала и уже никогда не выиграет, потому что старая.

anonymous
()
Ответ на: комментарий от anonymous

man aio ?

вы сами этот ман читали? чтобы не заблокироваться, файлы надо открывать с O_DIRECT. сотня процессов, читающих один и тот же файл будут постоянно дергать диски, а не читать из кеша.

Вы говорите про блокирующий вызов. Как насчет aio_write ?

вы определенно не понимаете, о чем пишете. тогда уж aio_read. но читает он в юзерлендовский буфер и до завершения операции трогать его нельзя.

spy
()
Ответ на: комментарий от anonymous

Прямо сейчас на одном из серверов 305 процессов hypnotoad

у вас банальный prefork. натравите на это slowloris и посмотрите, как быстро этот prefork сожрет память на 10к коннектов.

spy
()
Ответ на: комментарий от anonymous

Схему 200х300 можно и перенастроить на 3000х20, если оно себя покажет лучше.

вы лучше 128к на 1 процесс покажите.

spy
()
Ответ на: комментарий от anonymous

cobol тоже мертвый язык и за поддержку говна мамонта, на нем писанного, все еще платят. за ошибки всегда приходится платить. но одно дело - ошибки молодости, когда поставили не на ту лошадь потому, что выбирать особо не из чего было, и совсем другое, когда продолжают ставить на лошадь, которая ни разу не выигрывала и уже никогда не выиграет, потому что старая.

Неизвестный погроммистишко приводит мутные аналогии в качестве аргументов. Эх, очень слабый анонимус нынче пошел..

Я тебе как архитектор и «случившийся» программист скажу что TIMTOWTDI-ориентированные ЯП могут сильно сэкономить ваше время и нервы при умелом подходе.

Кстати, кроме perl, я бы включил Си и С++ (с некоторым подмножеством свойств) в список TIMTOWTDI-ориентированных языков (asm не рассматриваю из-за чрезмерной низкоуровневости и ориентира на архитектуру системы).

Рассматривая этот список из 3-х ЯП, можно сказать что кроме perl в оставшихся ЯП зашкаливает уровень «занудства» (возня с типами данных и их приведениями, ООП, выраженная инертность языковых конструкции, ...). Поскольку TIMTOWTDI-ЯП мы используем чтобы экономить время и нервы на циклах разработки, то ради еще большего выигрыша во времени логично не трогать в разработке ЯП которые вынуждают заниматься «занудством». Но в случае если необходима экстремальная производительность - то тут жертвуем «свободой от занудности» в пользу возможности более низкоуровневого управления ради производительности - поэтому выбираем либо Си, либо пишем на некотором подмножестве С++.

Вот примерно из-за чего мы разививаем, изучаем и пишем новые (да-да) проекты на perl.

PS: Прелесть ЯП perl еще в том что как только появятся новые парадигмы программирования - они безболезненно появятся в perl через модули на CPAN, ибо

Perl history in brief, by Larry Wall: ... Perl 5 introduced everything else, including the ability to introduce everything else.

:)

anonymous
()
Ответ на: комментарий от spy

вы сами этот ман читали? чтобы не заблокироваться, файлы надо открывать с O_DIRECT. сотня процессов, читающих один и тот же файл будут постоянно дергать диски, а не читать из кеша.

Пользовать сисколлы ядра напряму с O_DIRECT нужно для raw доступа к диску. Спросите Oracle что это за зверь и для чего им обращение без кэша.

но если вам нужен кэш, то для можно использовать aio-POSIX API из glibc который реализуется pthread-тредом в юзерспейсе.

Не вижу никаких проблем, разные варианты для разных задач. Нужны будут еще варианты - реализуют. А пока вроде всем хорошо.

anonymous
()
Ответ на: комментарий от spy

у вас банальный prefork. натравите на это slowloris и посмотрите, как быстро этот prefork сожрет память на 10к коннектов.

Конечно prefork, я и не отрицал. Под 10k коннектов (одвременных) если не хватит памяти я переделаю логику обработки соединении (prefork+select). На perl это займет максимум минут 30 (с тестированием).

anonymous
()
Ответ на: комментарий от spy

вы лучше 128к на 1 процесс покажите.

Без проблем, но с вас железо (+3 внешних сетевых интерфейса) которое обеспечит достаточную производительность для обработки 128k на 1 процессе. Вы можете тщательно оттюнить linux ядро - за «читерство» не сочтем. Вопрос системы мощностью достаточной для выполнения задачи - с вас, и в таком случае мне абслютно без разницы будет у нас 1 поток в контексте процесса или будет больше. По рукам?

anonymous
()
Ответ на: комментарий от anonymous

Многопоточный сервер уже написал, делаю тесты (очень интересные результаты).

Пришел в тред написать отчеты по тестам, но пришлось на вбросы ответить. Так что напишу в следующий раз. Результаты, кстати, очень и очень интересные.

anonymous
()
Ответ на: комментарий от anonymous

Пришел в тред написать отчеты по тестам, но пришлось на вбросы ответить

Результаты тестов интересуют больше, чем тексты сражений с троллями. Ждём результаты

anonymous
()
Ответ на: комментарий от anonymous

Пользовать сисколлы ядра напряму с O_DIRECT нужно для raw доступа к диску.

слышал звон, но не знаю где он. (с)

O_DIRECT - это такой способ сделать page cache bypass. не более. AIO в linux требует открывать открывать файлы с O_DIRECT и читать блоками, равными блоку фс, иначе можно заблокироваться.

spy
()
Ответ на: комментарий от anonymous

Под 10k коннектов (одвременных) если не хватит памяти я переделаю логику обработки соединении (prefork+select).

select лимитирован FD_SETSIZE, который обычно равен 1024. т.е. более 1к коннектов на процесс у вас не получится(это не считая оверхеда от select).

повторить то же самое для 128к коннектов просить не буду.

spy
()
Ответ на: комментарий от anonymous

Без проблем, но с вас железо (+3 внешних сетевых интерфейса) которое обеспечит достаточную производительность для обработки 128k на 1 процессе.

да легко. 2 машины с 16Гб памяти.

только зачем 3 интерфейса? речь о том, чтобы эти 128к хотя бы просто держать и периодически слать по ним keep-alive.

Вы можете тщательно оттюнить linux ядро - за «читерство» не сочтем.

а что за читерство? http://habrahabr.ru/post/123154/ вот тут на nodejs 1млн коннектов держат.

Вопрос системы мощностью достаточной для выполнения задачи - с вас, и в таком случае мне абслютно без разницы будет у нас 1 поток в контексте процесса или будет больше.

ну вот по ссылке выше - машина с 16Гб использовалась для 1млн коннектов и памяти потреблялось ~ 13Гб. Т.е. 4-8Гб памяти для 128к коннектов хватит с запасом.

По рукам?

легко. код и контакты в студию :)

spy
()
Ответ на: комментарий от anonymous

т.е. поддерживать со стороны вендора обратную совместимость с предыдущими своими же версиями продукта не комильфо? а проблема потребителя это его личная проблема, и ему нужно уметь читать код т.к. это просто :)

GOD ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.