CL быстрее прочих :)

Ага. C. А стандарт называется «POSIX». Может слышал о таком?

А если ОС не POSIX? Не слыхал о таких?

по скорости лучшие С/С++/Java

по памяти - Pascal/C/C++

по размеру кода - Python, Ruby, Perl

Не, лучше созерцать картинку с shapes - http://shootout.alioth.debian.org/u64q/code-used-time-used-shapes.php (учитывая, что будущее за 64 битами и кучей ядер (+ графический сопроцессор)). Там всё видно - скорость по вертикали и память по горизонтали. А в целом все вами перечисленные языки по объёму кода который нужно писать уступают Haskell или CL (уступают CL, существуют примеры - как объектная система C++ или Java или Python заставляет банально само-повторяться, в отличии от).

так зачем выбирают CL?

Это самый гибкий язык по части метаморфоз синтаксис/семантика. Мне его даже присоветовали заместо хаскеля (в случае если мне нужны эти метаморфозы).

Хм, а чем это отличается от pthread_cond_signal?

> А в целом все вами перечисленные языки по объёму кода который нужно писать уступают Haskell или CL

http://shootout.alioth.debian.org/u64q/which-language-is-best.php?xfullcpu=0&...

Это самый гибкий язык по части метаморфоз синтаксис/семантика

я бы не назвал это плюсом

>Напоминаю, тем человеком был я.

В принципе, логично было бы это предположить, поскольку остальные великие скобконосцы прошлого отреклись от своей еретической веры (tailgunner и mv).

Угу, именно тогда, когда обсуждали xmpp, тогда же и приводили пример того, что для C++ нет ни одной приличной библиотеки для взаимодействия с дочерними процессами через стандартные потоки ввода/вывода.

Казалось бы, зачем она такая нужна, когда есть pipe/socketpair, dup, fork и (запамятовал точное название; inb4 его нет в плюсовом стандарте) streambuf, способный использовать file handle для осуществления IO? Особенно с учетом того, какое говно представляют из себя плюсовые потоки.

Извини, я просто в шоке от твоей некомпетентности и способности всё забывать.

Ну тогда предыдущий абзац дает тебе еще одну возможность засомневаться в моей компетенции. Можешь начать свои сомнения с фразы: «В Windown нету fork!».

>А если ОС не POSIX?

MS-DOS и ее графические надстройки меня как-то слабо интересуют.

> скобконосцы прошлого отреклись от своей еретической веры (tailgunner и mv).

ЩИТО? O_O_O_O

ЩИТО? O_O_O_O

Я тоже подумал, что у него скобки в шаблонах перепутались.

>> А если ОС не POSIX?

MS-DOS и ее графические надстройки меня как-то слабо интересуют.

На большее фантазии не хватает?

>А что делать, если процессор не от интела?

Ты сейчас хочешь попытаться убедить меня, что у AMD нет гайдов по оптимизации для разработчиков?

У меня, в отличии от читателей мануалов интела, на руках живой опыт работы с железом

Ты сейчас говоришь как быдлокодер-птушник, которого только что развернули на собеседовании со словами: «Мы не видим диплома ВУЗа».

Читатели на то и читатели, что не писатели. Посвистеть на форуме они могут, конечно, но не более.

Лучше тихонько посвистеть, чем выставлять код, который тормозит из-за наличия правильного выравнивания. Отмазываться фразой «а на нахелемах за 100500 баксов работает прекрасно» очень похоже на тихое лопанье пузырей, запоздало всплыших после громкого пука из лужи.

> казалось бы, зачем она такая нужна, когда есть pipe/socketpair, dup,

fork и (запамятовал точное название; inb4 его нет в плюсовом

стандарте)

Гы-гы, удачи. Кнут вот тоже считает, что повторное использование код это зло. Раздувать тривиальную вещь в несколько десятков (с учётом обработки ошибок, если ты её пишешь)строк кода - это, конечно, очень правильно.

Особенно с учетом того, какое говно представляют из себя плюсовые

потоки.

И что не так с плюсовыми потоками? Вот, Страуструпу понравились, претендуешь на ... на что?

тут не только третий глаз открылся :)

нет ну каков вброс то, каков вброс! :)

>Хм, а чем это отличается от pthread_cond_signal?

Наверное наличием pthread_cond_broadcast, что дает нам возможность будить «хотя бы одну» или «сразу все» нити, висящие в cond_wait*

CL быстрее прочих :)

Lisp уже быстрее жабы?

> будет забавно если программа [\зачеркнуть гильберта] swizard(а) по порабощению шотаута будет воплощена в жизнь :)

гы-гы

посмотри на ATS (он компилируется в си)

он на ОДНОМ ядре все сделал за 65 секунд, в то время как SBCL на ЧЕТЫРЕХ ядрах затратил 50

>> Хм, а чем это отличается от pthread_cond_signal?

Наверное наличием pthread_cond_broadcast

Это другая функция (ХЗ, есть ли она в бордо-нитях). Но pthread_cond_signal будит «at least 1» нить - то есть может и всех.

А в целом все вами перечисленные языки по объёму кода который нужно писать уступают Haskell или CL

[ссылка]

Это было моё наблюдение (просто я сделал такие выводы, на основе кода который видел) безотносительно примеров на шутауте. Но всё же - http://shootout.alioth.debian.org/u64q/program.php?test=pidigits&lang=ghc&id=4 и http://shootout.alioth.debian.org/u64q/program.php?test=pidigits&lang=python3&id=3.

Впрочем согласен - это уже разговор ни о чём (а.к.а. меряние частями тела :)

Это самый гибкий язык по части метаморфоз синтаксис/семантика

я бы не назвал это плюсом

Это выразительное средство - хочу беру (как swizard в той задаче), хочу нет. Но оно есть, а вот в языке (например) Java его нет.

> Ой, а готового, значит, нет?

Вам шашечки или ехать? Есть хорошая оттестированная библиотека на С, так почему бы её не использовать к вящей славе Лиспа?

>И что не так с плюсовыми потоками?

Хочу, по-разному сериализовать данные, отправляемые по сети и записываемые в локальные файлы. При этом хочется максимальной прозрачности для приложения, которое уже все обвешалось operator>>/operator<< для ввода-вывода. Доктор, как мне быть?

> Написать своё решение на «C/C++»

Мне давно неинтересны олимпиадные задачи. Кроме того (насколько я могу судить) решение swizard - просто интересный трюк, демонстрирующий старую идею о том, что надо оптимизировать алгоритмы, а не их реализации.

А как тогда древко? Если устали мозолистые натруженные руки сишников(то что так и нет решения как бы намекает)? Кроме того получается, что поход к решению который демонстрирует уже который раз swizard просто невозможен на ++?

«трюк» который получается несколько раз подряд и с разными задачами уже не трюк. Это (зачеркнуто Спарта) методология!

Ты сейчас хочешь попытаться убедить меня, что у AMD нет гайдов по оптимизации для разработчиков?

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

Ты сейчас говоришь как быдлокодер-птушник, которого только что развернули на собеседовании со словами: «Мы не видим диплома ВУЗа».

Я говорю, как пользователь продукта, который производитель рекламировал фразой «Теперь больше не нужно выравнивать данные». У его прямого и единственного конкурента та же фигня.

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

Докажи.

>Но pthread_cond_signal будит «at least 1» нить - то есть может и всех.

Ну при использовании логики, эта фраза будет прочитана как:

жанная функция разблокирует хотя бы одну из нитей, заблокированных в ожидании события на условной переменной (если, конечно, такие нити есть)

function shall unblock at least one of the threads that are blocked on the specified condition variable cond (if any threads are blocked on cond).

Сравни это с фразой из мануала к borderaux-threads, где прямым текстом говорится «одну или всех, но в целях оптимизации лучше бы сделать, чтобы одну».

> >CL быстрее прочих :)

Lisp уже быстрее жабы?

1) не тупите, это другая задача (про блинчики).

2) таки быстрее, принципиально быстрее

>Ну при использовании логики, эта фраза будет прочитана как:

жанная функция разблокирует хотя бы одну из нитей, заблокированных в ожидании события на условной переменной (если, конечно, такие нити есть)

И какой логике пртииворечит заявление «эта функция может разбудить все заблокированные нити»?

>Есть хорошая оттестированная библиотека на С, так почему бы её не использовать к вящей славе Лиспа?

Ой, а как мне напрямую воспользоваться, скажем, замечательными и оттестированными функциями fprintf/fscanf? Или любой функцией, использующей некую структуру данных? Надо натравливать swig на системные хидеры? Писать свои полигональные колеса?

Почему бы сразу не взять язык, в котором плюшки будут «из коробки» и «без напильника»?

Принципиально - это теоретически или потенциально?

>На большее фантазии не хватает?

Ты сейчас об операционных системах для отправки эсемесок чтоли? Или о программировании кофеварок? Извини, но я программированием для ущербных (пусть и необходимых) железок не занимаюсь. Но вообще то забавно читать подобные пассажи в защиту лиспа, которые и на x86-то запускается с грехом пополам.

> Хочу, по-разному сериализовать данные, отправляемые по сети и

записываемые в локальные файлы. При этом хочется максимальной

прозрачности для приложения, которое уже все обвешалось

operator>>/operator<< для ввода-вывода. Доктор, как мне быть?

И в чём, собственно, проблема? Да, мультиметодов в C++ нет, но это никак не связано с потоками, поэтому берёшь в руки RTTI и для разных потоков реализуешь разную логику. А как должно было бы быть?

Доктор, как мне быть?

Я не доктор, средства повышения IQ мне не известны.

> Кроме того получается, что поход к решению который демонстрирует уже который раз swizard просто невозможен на ++?

Если брать Паскаль как аппроксимацию Си, получается, что на Си подход swizard просто не нужен.

«трюк» который получается несколько раз подряд и с разными задачами уже не трюк

Цирковые акробаты с тобой не согласятся %)

>И какой логике пртииворечит заявление «эта функция может разбудить все заблокированные нити»?

Это противоречит принципу бритвы Оккама. Потому что если ты все-таки подрудишься посмотреть мануал по pthread_cond_signal, то откроешь для себя примерно такую структуру:

NAME
       pthread_cond_broadcast, pthread_cond_signal - broadcast or signal a condition

SYNOPSIS
       #include <pthread.h>

       int pthread_cond_broadcast(pthread_cond_t *cond);
       int pthread_cond_signal(pthread_cond_t *cond);


DESCRIPTION
       These functions shall unblock threads blocked on a condition variable.

       The pthread_cond_broadcast() function shall unblock all threads currently blocked on the specified condition variable cond.

       The pthread_cond_signal() function shall unblock at least one of the threads that are blocked on the specified condition variable cond (if any threads are blocked on cond).

Еще дурацкие вопросы будут?

> Еще дурацкие вопросы будут?

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

> Цирковые акробаты с тобой не согласятся %)

Гы, с тобой приятно общаться ))

>Я говорю, как пользователь продукта, который производитель рекламировал фразой

Повелся на маркетинг как безграмотный птушник?

http://download.intel.com/business/resources/briefs/xeon5500/xeon_5500_perfor...

Across all ranges of operating environments and industries, both

large and small, IT is looking to better align computing resources with the needs of users and business. The intelligent performance of the Intel Xeon processor 5500 series enables this alignment, giving you fine-grained control to put resources where they will have the most business impact...

Боже ж ты мой! Типичная фраза для промывания мозгов безграмотным начальникам ой-ти подразделений.

Докажи.

В том треде я приводил пример кода с пофикшенным выравниванием и драматическое уменьшение времени выполнения вследствии того. По непонятным причинам «пользователь разрекламированного продукта» забоялся проводить замеры у себя, призывая вместо этого меня купить нахелем за 100500 денежных единиц.

> Если брать Паскаль как аппроксимацию Си, получается, что на Си подход swizard просто не нужен.

Учитывая, что паскаль позорно слил по скорости выполнения, подход свизарда нужен.

> он на ОДНОМ ядре все сделал за 65 секунд, в то время как SBCL на ЧЕТЫРЕХ ядрах затратил 50

наркоман, и не лечишься... в _сумме_ 50. А так от старта 12.9сек

Повелся на маркетинг как безграмотный птушник?

Так в том-то и дело, что я руками всё щупаю, а ты буклеты читаешь.

В том треде я приводил пример кода с пофикшенным выравниванием и драматическое уменьшение времени выполнения вследствии того. По непонятным причинам «пользователь разрекламированного продукта» забоялся проводить замеры у себя, призывая вместо этого меня купить нахелем за 100500 денежных единиц.

Результат в 2 с хвостиком раз хуже, чем если бы данные лежали в одной строчке, и всё равно в 3 раза лучше, чем когда они лежат на границе страницы.

К тому же, у тебя древний 32-битный пенёк, у которого 64-битный mov эмулируется двумя 32-битными, но тебе это или не известно, или ты не понимаешь, к чему это ведёт, или понимаешь, но постыдно умалчиваешь.

Нехалем меньше 200 баксов стоит, как в ресторан сходить.

>Да, мультиметодов в C++ нет, но это никак не связано с потоками, поэтому берёшь в руки RTTI и для разных потоков реализуешь разную логику.

Видишь ли в чем дело... Для того, чтобы новый «netstream» можно было передавать в качестве аргумента наряду со старым добрым fstream (или даже i/ostream), нужно, чтобы он был вписан в эту иерархию наследования. А дальше начинается небольшая проблема, связанная с тем, что если какая-то функция получила std::istream &in и пытается сделать in>>int_value, то угадай, вызов какого оператора подставить компилятор? Всегда istream::operator>>.

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

>> Если брать Паскаль как аппроксимацию Си, получается, что на Си подход swizard просто не нужен.

Учитывая, что паскаль позорно слил по скорости выполнения

17 c против 12 с - это слив в 40%, ни разу не позорный; еще учтем, что CL сожрал на 50% больше памяти.

Кстати, время на генерацию кода включено в тест?

> Принципиально - это теоретически или потенциально?

1) если все решения упёрлись в 17 сек (или так и не родили быстрый и корректный вариант в картографической задаче на конкурсе) --- это теория. Явно фундаментальный предел достигли.

2) а CL в обоих случаях «вальяжно спустился с горы и...», то это уже суровая практика.

Так что насчёт потенции я бы даже теоретически не волновался :)

>Цирковые акробаты с тобой не согласятся %)

Так ведь для них это уже и не трюк, а трудовые будни.

Если брать Паскаль как аппроксимацию Си, получается, что на Си подход swizard просто не нужен.

Плохая апроксимация, паскаль же слил лиспу, ну free pascal по крайней мере, других я не увидел.

> > «трюк» который получается несколько раз подряд и с разными задачами уже не трюк

Цирковые акробаты с тобой не согласятся %)

с _разными_ же задачами... ну чем акробатам поможет их умение в одном случае занести рояль на 12й этаж, а во втором сдать печатать на пишущей машинке со скоростью 200 с/мин?

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

К твоему сведению, у меня под рукой была пара 64-битных машин с бздей, на которых я произвел замеры. То, что выравнивание 64-битного целого на 32-битной архитектуре = 4 очевидно любому окончившему среднюю школу.

Нехалем меньше 200 баксов стоит, как в ресторан сходить.

Подари 200 баксов, раз такой богатый :)

> 17 c против 12 с - это слив в 40%, ни разу не позорный

Для С (пусть и эмулируемому паскалём) это именно что позорище несусветное. Ибо высокая скорость работы --- это почти единственное зачем следут мучаться с этим портируемым макроассемблером.

> паскаль же слил лиспу,

Блин. Да не Паскаль слил Лиспу, а алгоритм, использованный в Паскаль-программе слил алгоритму, использованному в Лисп-программе. Неужели такие очевидные вещи нужно объяснять? Или ты Ъ и не сходил по ссылке?

ну free pascal по крайней мере, других я не увидел.

Freepascal - это что такое? GNU Pascal знаю, FreePascal - нет.

***зописывает: Лиспособы --- суть нищеброды несчастные.

>Кстати, время на генерацию кода включено в тест?

Включено, если на этой странице речь все еще идет о задаче из первого поста.

> алгоритм, использованный в Паскаль-программе слил алгоритму, использованному в Лисп-программе

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

>> 17 c против 12 с - это слив в 40%, ни разу не позорный

Для С (пусть и эмулируемому паскалём) это именно что позорище несусветное.

Еще один не заметил того, что использовались разные алгоритмы. Где вас таких делают? %)

К твоему сведению, у меня под рукой была пара 64-битных машин с бздей, на которых я произвел замеры. То, что выравнивание 64-битного целого на 32-битной архитектуре = 4 очевидно любому окончившему среднюю школу.

У тебя на балконе может стоять подводная лодка, но нам это также неочевидно, как и факт запускания кода с %esi на 64-битной оси.

Подари 200 баксов, раз такой богатый :)

Хватит нищебродить, иди работать лиспером.