а какие языки кроме C/C++ вы можете посоветовать для решения таких же задач для которых используется C/C++?
то есть доступ к системе, высокоскоростная обработка данных, математика

Здравствуйте, tttraveler, Вы писали:

T>а какие языки кроме C/C++ вы можете посоветовать для решения таких же задач для которых используется C/C++?
T>то есть доступ к системе, высокоскоростная обработка данных, математика

Pascal, Ada, D, Rust, ...

Здравствуйте, tttraveler, Вы писали:

T>а какие языки кроме C/C++ вы можете посоветовать для решения таких же задач для которых используется C/C++?
T>то есть доступ к системе, высокоскоростная обработка данных, математика

если не писать свои велосипеды — то любой язык, например питон с numpy и т.п.

Здравствуйте, tttraveler, Вы писали:

T>а какие языки кроме C/C++ вы можете посоветовать для решения таких же задач для которых используется C/C++?
T>то есть доступ к системе, высокоскоростная обработка данных, математика
что такое высокоскоростная обработка данных? на питоне полно библиотек, написанных на си. если писать на питоне только "клей", то по скорости получится как си, только более наглядно. доступ к системе есть у того же питона. есть даже кросс-платформенный отладчик для нативных файлов оси, работающий как под виндой, так и под линухом с маками. если, например, стоит задача потрейсить программу, а затем обработать лог, свернув циклы и осуществив декомпозицию с разбием на функции, то мы получаем системно-независимую утилиту. крысота. не нужно изобретать свой трейсер. не нужно учитывать разницу 32 и 64 бит. и так далее.

Здравствуйте, Abyx, Вы писали:

T>высокоскоростная обработка данных
и
A>питон
? =)

ты, наверное, и для многопоточного программирования станешь рекомендовать питон?

Здравствуйте, мыщъх, Вы писали:

М>если писать на питоне только "клей", то по скорости получится как си
нет.

Здравствуйте, niXman, Вы писали:

X>Здравствуйте, мыщъх, Вы писали:

М>>если писать на питоне только "клей", то по скорости получится как си
X>нет.
давайте потестим. например, вот. https://code.google.com/p/esmre/
давайте так же возьмем достаточно большой словарь: http://svn.pietdepsi.com/repos/projects/zyzzyva/trunk/data/words/North-American/OWL.txt
и найдем все слова в библии, которых нет в этом словаре: http://www.ccel.org/ccel/bible/kjv.txt

или давайте забьем на клей и будем писать на питоне. возьмем Lex/yacc для питона (http://www.dabeaz.com/ply/) и в качестве разминки напишем транслятор для бейсика. сравним скорость трансляции с си.

Здравствуйте, мыщъх, Вы писали:

думаю, что тут любые тесты будут лишними, ибо вы наверняка понимаете, что даже "клей" — рантайм оверхед.

тестить нужно, если интересна оценка этого оверхеда.

Здравствуйте, niXman, Вы писали:

T>>высокоскоростная обработка данных
X>и
A>>питон
X>? =)

X>ты, наверное, и для многопоточного программирования станешь рекомендовать питон?

"многопоточность" — это способ решения задач.
если например надо обрабатывать картинки, и есть С или С++ либа которая делает это в много потоков — почему бы не вызвать ее из питона?

Здравствуйте, niXman, Вы писали:

X>Здравствуйте, мыщъх, Вы писали:

X>думаю, что тут любые тесты будут лишними, ибо вы наверняка понимаете, что даже "клей" — рантайм оверхед.

X>тестить нужно, если интересна оценка этого оверхеда.

конечно, рантайм оверхед 10мс работы питона на 10 минут работы либы это очень существенно.

Здравствуйте, Abyx, Вы писали:

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

да и холиварная это тема...

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

Здравствуйте, niXman, Вы писали:

X>Здравствуйте, мыщъх, Вы писали:

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

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

Здравствуйте, niXman, Вы писали:

A>>если например надо обрабатывать картинки, и есть С или С++ либа которая делает это в много потоков — почему бы не вызвать ее из питона?
X>если например надо обрабатывать картинки, и есть С или С++ либа которая делает это в много потоков — то просто юзаем ее.

просто и на С, да?
вот простой код на питоне

import my_image_processing_lib
src = open('src.img', 'rb').read()
result = my_image_processing_lib.process()
open('out.img', 'wb').write(result)

я могу набрать и выполнить его в REPL

а на плюсах ты сначала напечатаешь 100 строк, еще наверное cmake или bat/sh файл напишешь, потом пять раз перекомпилируешь чтобы поправить все ошибки — это конечно же проще чем питон с его REPLом

Здравствуйте, мыщъх, Вы писали:

М>оверхид смарт-поинтеров.
я могу не использовать смарт-поинтеры
но, по аналогии, используя питон — я не могу не использовать питон

М>это же ведь жуткий оверхид по сути
нет.

Здравствуйте, мыщъх, Вы писали:
X>>думаю, что тут любые тесты будут лишними, ибо вы наверняка понимаете, что даже "клей" — рантайм оверхед.
М>нет. не понимаю. откуда такой страх перед оверхидом? давайте тогда брать оверхид смарт-поинтеров. это же ведь жуткий оверхид по сути. давайте брать оверхид динамической памяти, что вообще ужос. аргументы функции -- оверхид. глобальные переменные -- наше все. они (как вы понимаете) иницилизируются даром при загрузке файла. а перменные только на чтение еще и не сваливаются в своп. вот только тесты что-то не показывают разницу этого оверхида (в большинстве случаев).

Ви будете смеяться, но таки да. Динамическая память — это адский оверхед, особенно, когда речь идёт о десятках-сотнях миллионов маленьких объектов, занимающих гигабайты.
Я тут уже писал про блеск и нищету unordered_map.

Здравствуйте, tttraveler, Вы писали:

T>а какие языки кроме C/C++ вы можете посоветовать для решения таких же задач для которых используется C/C++?
T>то есть доступ к системе, высокоскоростная обработка данных, математика


Да любой где есть оптимальный компилятор, но нет виртуальной машины.
Если связаны с матаном то я бы предложил посмотреть на fortran, forth, Haskell, Prolog.

Здравствуйте, niXman, Вы писали:

X>да и холиварная это тема...

X>просто нужно отметить, что, так как С/С++ используются и для решения задач критичных к производительности, питом для этого не подходит.
а никто и не предлагает писать все целиком на питоне. под капотом там будет си. основная вычислительная нагрузка ляжет на нативный код (зачастую написанный со вставками на асме для разных платформ).

рассмотрим это на примере формата pdf. основные вычислительные затраты это расжать все стримы и отредерить контент. но для начала файл нужно распарсить. и снова, Lex/Yacc для питона могут (при необходимости) генерить выходной файл на си, так что "клей" в ран-тайм не попадает _совсем_. но программа написана на питоне.

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

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

так что ваше утверждение о том, что питон всегда дает оверхид в рантайме неверно по трем причинам:
1) метапрограммирование: результатом работы программы на питоне является сгенерированная программа на си с машинной высокоуровневой оптимизацией (например, повторное использование переменных для уменьшения кол-ва выделяемой памяти);
2) для питона есть _компиляторы_ в нативный код и тут вопрос лишь в их эффективности, но разрыв между си и "клеем" питона сокращается до погрешности измерений;
3) JIT компилятор питона потенциально способен обогнать си, т.к. JIT распологает информацией недоступной компилятору си;

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

Здравствуйте, Кодт, Вы писали:

К>Здравствуйте, мыщъх, Вы писали:


К> Ви будете смеяться, но таки да. Динамическая память — это адский оверхед, особенно,
K> когда речь идёт о десятках-сотнях миллионов маленьких объектов, занимающих гигабайты.
разумеется. даже если блоки храняется не в списке, а в виде дерева, то расходы все равно чудовищны. я тут разбирался с разными реализациями Aho-Corasick и обнаружил, что народ активно пишет свои аллокаторы. не от хорошей жизни.

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

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

Здравствуйте, tttraveler, Вы писали:

T>а какие языки кроме C/C++ вы можете посоветовать для решения таких же задач для которых используется C/C++?
T>то есть доступ к системе, высокоскоростная обработка данных, математика

спасибо всем за ответы
теперь очередной набор вопросов
1. каковы перспективы и недостатки D для коммерческого использования на ближайшие лет 10?
2. насколько комфортно будет использовать связку Python + D для разработки десктопных мультиплатформенных оконных приложений?