Google разрабатывает язык Noop для замены Java

> задача в ответ - дана строка на 1млн символов, где слова разделены пробелами, раздели ее максимально быстро на массив слов

Java/Python: s.split(" ")

Критерий "максимально быстро" - он непонятный. Вы укажите конкретное ограничение по времени и тип железа.

> а использование сторонних библиотек совсем не такое страшное, как вы расписываете :)

В Python/Java - конечно не страшное. Прописал импорты в начале исходника и всё работает. Это в примитивных средах разработки надо будет скакать с бубном, указывая линкеру пути и хитрые флаги.

> Критерий "максимально быстро" - он непонятный.

ну хотя бы не слить С/С++ в десять раз по времени

> Это в примитивных средах разработки надо будет скакать с бубном, указывая линкеру пути и хитрые флаги.

вот уж никогда не думал, что это так сложно :)

> Такие заявления принято сопровождать примерами, дабы они не звучали пуком в лужу.

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

Вы лучше приведите пример, где у вас боксинг вызывает серьёзные проблемы во время разработки или рантайма. Тогда и поговорим.

>Smalltalk из криокамеры вытащили

Смолток проприетарен до последнего бита

А как же педон?

После провала с "интернет-офисом" (пользователь выбирает OpenOffice/Symphony) и "хромом" (Firefox не уменьшил своей доли рынка) решили изобрести еще один велосипед.

Вперед и с песнями!

Это невозможно, результат последующей операции зависит от результата предыдущей. Не?

> Java/Python: s.split(" ")

это окончательное решение и мне можно сравнивать его с решением на С++?

> Дурак? список о*енная абстракция.

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

>к счастью не так часто надо вычислять факториалы

Задача была не на вычисление факториалов. Люблю, черт возьми, некорректно поставленные задачаи! Пойдет в мою копилку.

> Это невозможно, результат последующей операции зависит от результата предыдущей. Не?

ещё как возможно. паралелится в легкую - достаточно вспомнить, что a*b*c*d = (a*b) * (c*d)

можно сделать для двух потоков - один считает с начала до середины, второй - с конца.

>> Smalltalk из криокамеры вытащили

> Смолток проприетарен до последнего бита

Вызывающе неверная информация

Смолток имеет открытую лицензию:

http://ru.wikipedia.org/wiki/Squeak

http://www.squeak.org/

>> Критерий "максимально быстро" - он непонятный.

> ну хотя бы не слить С/С++ в десять раз по времени

split на Питоне, как бы, на Си и написан :D Так что время будет то же самое. На Java split написан на Java, но на чистых числодробилках скорость Java колеблется от «быстрее Си на несколько процентов» до «уступает процентов на 20-30». В любом случае о десятках раз речь не идёт :)

...

Вообще, вот инфа для размышления, кто не смотрел ещё: http://balancer.ru/tech/forum/2008/08/t63003--proizvoditelnost-yazykov-obektn...

Есть некоторая вероятность, что этот вариант будет работать чуть-чуть медленнее написанного при помощи string.indexOf(' ') и пр., так как под сплитом всё-таки регексп.

Но такие участки всегда можно переписать, если они являются узким местом.

> ну хотя бы не слить С/С++ в десять раз по времени

Пипец критерий. Вы можете себе представить, чтоб такое возникло в реальной жизни? Чтоб заказчик хотел не определённых величин, а "не хуже, чем на другом языке"? Бред.

>>> Это авторы старых учебников по программированию.

>> таки не знаете... книга написана в 2007 году

>Скорее, она издана в 2007 году.

да, сорри, опечатался.... в 2005 году

>Это требует некоторого знания истории и внутренностей ядра. Вот неплохой и довольно краткий материал

укажите точнее, а то "многабукаф", а информации по реализации posix threads я там не нашёл...

> split на Питоне, как бы, на Си и написан :D Так что время будет то же самое

вы уверены? ;) а если я в С++ пройдусь по строке и запомню указатели на начала слов в вектор, а пробелы забью нулями? ( если исходная строка не должна меняться - ее можно скопировать в другой буфер, что будет сделано очень быстро, если может меняться - еще один плюс к производительности кода )

> Пипец критерий. Вы можете себе представить, чтоб такое возникло в реальной жизни?

не поэтому-ли программы на Java зачастую тормозят? :)

>Когда библиотека перестаёт развививаться дальше, она не исчезает волшебным образом из всех проектов, где используется. Просто перестаёт обновляться. И у программиста останется ещё уйма времени на то, чтобы найти что-то новое и более живое. Или, в самом крайнем случае, написать это новое самому.

это понятно, но цена такого перехода?

задача в ответ - дана строка на 1млн символов, где слова разделены пробелами, раздели ее максимально быстро на массив слов

#!/usr/bin/env python

import re

def split_to_words(s):
    match = None
    for match in re.finditer('(?s)(.+?)(\s+|$)', s):
        word = match.group(1)
        if word.strip():
            yield word 
            
print list(split_to_words('  sss bbb   sss ddd    fff'))
print list(split_to_words('  '))
print list(split_to_words(''))

И зачем нам этот массив дальше понадобится?

> это окончательное решение и мне можно сравнивать его с решением на С++?

Рассказываю вам, как пишутся программы, имеющие заданные критерии производительности.

1. Пишется первый вариант, как можно проще.
2. Тестируется производительность.
3. Если производительность не удовлетворяет критериям:
3.1. Профилируем, определяем узкие места.
3.2. Заменяем неэффективные алгоритмы (O(N^2) и больше)
3.3. Если проблема осталась - читаем литературу по специфике рантайма и структур данных и переписываем алгоритмы с их учётом.
3.4. Если проблема осталась - выносим наиболее критичные участки в низкоуровневый язык.
4. Сдаём программу или докладываем о невозможности достижения критериев производительности.

> И зачем нам этот массив дальше понадобится?

очевидно же - для индексации

>Я думал тред просто завалит кусками кода. Видимо основная часть школоты в положенном им месте. А так только три калеки привели кучку неработающего говна.

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

> не поэтому-ли программы на Java зачастую тормозят? :)

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

На крейсерской высоте жаба/шарп летят со скоростью 0.5-1 C.

>>> http://msdn.microsoft.com/en-us/library/ms684161(VS.85).aspx

>> Не понимаю, зачем использовать это в переносимых программах, но это явно содрано с юниксовой session.

> эээ, точно внимательно прочитали?.. это про sandboxng

Не заметил там sandboxing. Если имеются в виду лимиты: ("job can enforce limits on each associated process, such as the working set size, process priority, end-of-job time limi"), то лимитов на дерево процессов в Unix нет вообще. В Linux они то ли есть, то ли вот-вот будут в виде контроллеров/контейнеров. Однако пойнт в том, что эта конструкция непереносима.

Дурак? список о*енная абстракция.

> Да абстракция, отличная. Только непонятно зачем программистов надрачивают реализовывать эту абстракцию. Разве что только пролить свет на указатели. Хм.

> а если я в С++ пройдусь по строке и запомню указатели на начала слов в вектор, а пробелы забью нулями?

Вы, наверное, удивитесь, но Java сделает примерно то же самое. Там строки интернятся, со всеми вытекающими.

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

Конечно. Но решение должно упираться в ресурсы машины, а не в примитивные ограничения примитивного язычка.

> Рассказываю вам, как пишутся программы

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

>это понятно, но цена такого перехода?

Поскольку библиотеки умирают, обычно, нечасто, то цена такого _подхода_ в целом будет много ниже цены, подхода, при котором будут изобретаться велосипеды на каждый чих :)

> Можно предложить народу написать факториал, который считается хотя бы в 2 потока на разных языках.

Python вылетает сразу, там нельзя тредами параллелить процессор, только I/O. Хотя, конечно, есть мультипроцессирование, но оно ООООЧЕНЬ редко будет окупаться :]

> Вы, наверное, удивитесь, но Java сделает примерно то же самое. Там строки интернятся, со всеми вытекающими.

думаю стоит проверить - можете плз написать сюда полный пример кода на Java

>> Как бы намекает, что отстрелить себе ногу можно на любом языке...

> Причем в правильных языках, с течением времени, возможностей для этого все меньше и меньше.

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

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

> хе, мне кажется Вы и сами можете придумать такие примеры с лёгкостью... например административный запрет на использование сторонних библиотек, или, например, использование специфичной платформы на которую данные библиотеки не портированы + ещё "питцот тыщ" ситуаций возникающих в повседневной работе )

>административный запрет на использование сторонних библиотек

значит всё-таки фюрер запретил?

>например, использование специфичной платформы на которую данные библиотеки не портированы + ещё "питцот тыщ" ситуаций возникающих в повседневной работе )

странно, но у меня таких ситуаций не возникает, ага

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

Я что сегодня действительно настолько туманно выражаюсь? Где я упоминал _любого_?

> "Заменяем неэффективные алгоритмы" не катит, оптимизация пишется параллельно основному коду

Зачем тормозить выкатку прототипа? Чтобы на интеграционное тестирование меньше времени осталось?! Ппц подходик.

Оптимизацию всегда лучше оставлять на потом. Заранее предсказать поведение рантайма ОЧЕНЬ сложно, особенно с учётом сложности современных процов.

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

То есть в жабе запрещено использовать различные деревья?

> Поскольку библиотеки умирают, обычно, нечасто, то цена такого _подхода_ в целом будет много ниже цены, подхода, при котором будут изобретаться велосипеды на каждый чих :)

Да мы вроде спорили не в дихотомии "NIH - велосипед", а в дихотомии "батарейки включены - не включены".

вычисление значения факториала от _любого_ натурального числа принципиально не возможно

неправда Ваша... вот вам программа на языке erlang:

-export([factorial/1]).

factorial(0) -> 1;

factorial(N) -> N * factorial(N-1).

вычисляет факториал от 5000000 за считанные секунды. :)

>Не заметил там sandboxing. Если имеются в виду лимиты: ("job can enforce limits on each associated process, such as the working set size, process priority, end-of-job time limi"), то лимитов на дерево процессов в Unix нет вообще. В Linux они то ли есть, то ли вот-вот будут в виде контроллеров/контейнеров. Однако пойнт в том, что эта конструкция непереносима.

Да-да-да! Ну Вы же всё правильно понимаете! :)

> Не могу собрать.

Не в обиду, но сразу видно, кто маны не читает :-)

g++ -lgmpxx -lgmp factorial.c -o fact3

>Поскольку библиотеки умирают, обычно, нечасто, то цена такого _подхода_ в целом будет много ниже цены, подхода, при котором будут изобретаться велосипеды на каждый чих :)

Согласен с каждым словом!

В в энтерпрайзе где программы живут десятилетиями, вероятность умирания библиотеки написанной группой программистов "под руководством дяди Вани" существенно выше, не?

>> Это требует некоторого знания истории и внутренностей ядра. Вот неплохой и довольно краткий материал

> укажите точнее, а то "многабукаф"

Бгг. Вопрос, знаешь ли, не самый банальный. Если кратко, то теперь tid не является pid.

> а информации по реализации posix threads я там не нашёл...

Ахренеть, Вообще-то там _вся_ информация - о реализации POSIX threads в Linux. Документ даже называется NPTL Design (если что, NPTL - это стандарнтая поддержка нитей в Linux). Если нет сил читать весь документ, осиль только главы 1, 3, 6.

>>административный запрет на использование сторонних библиотек

>значит всё-таки фюрер запретил?

:))) бывает и такое

>>например, использование специфичной платформы на которую данные библиотеки не портированы + ещё "питцот тыщ" ситуаций возникающих в повседневной работе )

>странно, но у меня таких ситуаций не возникает, ага

случаи разные бывают, не?

> Зачем тормозить выкатку прототипа? Чтобы на интеграционное тестирование меньше времени осталось?!
> Оптимизацию всегда лучше оставлять на потом

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

>Я что сегодня действительно настолько туманно выражаюсь? Где я упоминал _любого_?

Ты вообще не сказал область определения функции, точность вычислений, и что должно быть в случае ошибки. Не сказал - значит всё это на твоей совести, телепаты в отпуске.

> Тормознутось (2-4x раза при Jit) -- детерменирована (известно, сколько стоит железо) а утечки памяти приводят к катастрофе на сервере в итоге. Господи, вам в вузе преподавал фанатик С++ или вы сами заразились?

Обьясните - зачем тормозить систему в 2-4 раза (оптимистично)? У меня в системе обычно нет Java программ - и тормозов, соответственно. Раньше - были. Но, как можно легко догадаться, как только находится C/C++ аналог - Java программа не выдерживает конкуренции ни секунды.

> Отнюдь. Практика показывает, что 'правильные' языки делают для быдла, не умеющего и не желающего думать. Сделай систему, чтобы даже идиот мог ей пользоваться - и только идиот и сможет ей пользоваться.

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

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

Про ОС и все известные языки никто еще не лепетал. Поручик, держите себя в руках. От вас несет бредом.

>программистов надрачивают реализовывать эту абстракцию

А что там надрачивать?