Как технарю из России стать программером в США за 150К

[Zombie416]

Вот с этого и надо было начинать...не все же знают

Совершенно верно. Стоит сначала узнать, а потом начинать рассказывать

Я говорю про реальные цифры с реальными практическими задачами. А не linked list из миллиона целых чисел в вакууме.

В вакууме получается (если довести до 25 миллионов циклов), C++ native vs C++/CLR vs C# 3.3 / 4.5 / 5.5 секунд, причем все это плавает в зависимости от x86/x64 в удивительно широких пределах. На linked list с целыми C# страдает, вероятно из-за boxing/unboxing.

[Boriskin]

XML и БД на C# и Яве - часть основной библиотеки. Без них не бывает.

Xerces, sql++ и так далее.

[ddv]

Согласитесь, что это критично только для очень узкого круга задач.
Зато C# могут выучить все, а C++ только особо одаренные.

Согласен что могут выучить все. Но те кто не смог выучить С++ не сможет писать эффективные программы даже на C#. А Visual Basic и аналоги существовали давно. Так что всетаки C# это развитие VB ниши, а не замена C++.

[zzhou]

А аналог std::list называется LinkedList<T>.

Вот с этого и надо было начинать...не все же знают что массив можно обозвать списком. Да ...теперь разница меньше - 2.5 раза...но и это далеко от одинаковой производительности...и даже от 50%-100% озвученных вами.

Это задача про сферического коня в вакууме. А если взять реальное приложение написанное "средними программистами" то окажется:
1. На Java оно работает быстрее (потому что Jit в Яве анализирует код на лету - учитывая то, как он исполнялся), многие _реально_ важные вещи работают быстрее (покажите мне "среднего программиста" на C++ который будет грамотно использовать heap - а на Яве это автоматом) - т.е. выделение памяти под объект очень дешёвое)
2. На Яве меньше утечек ресурсов - приложение реже падает.
3. Приложение написано будет быстрее из-за более развитой стандартной библиотеки и большого количества очень стабильных OSS библиотек.

Т.е. супер-С-профи, конечно, напишет на C++ более эфективный код по добавлению/удалению элемента в список. Или даже код который миллион раз сделает 1+1. Но я хотел бы посмотреть как этот суперпрофи напишет стандартное "автоматизированное рабочее место кассира" - и сколько сил ему прийдётся потратить чтобы оно не падало раз в день из-за утечек памяти.

[Zombie416]

Но те кто не смог выучить С++ не сможет писать эффективные программы даже на C#.

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

А остальные могут писать на любом, и между (в основном) процедурными компилируемыми в нативный код (не важно на каком этапе и на чьем компьютере) языками вроде C/C++/C#/Java/... большой разницы нет. Где-то синтаксис проще, где-то сложнее, где-то что-то короче записывается, где-то длиннее. На этом принципиальные отличия кончаются.

[ddv]

1. На Java оно работает быстрее (потому что Jit в Яве анализирует код на лету - учитывая то, как он исполнялся)

Даже если оно и анализирует код на лету ( в чем я глубоко сомневаюсь,..скорее всего он компилирует при загрузке класса или т.п.), то тогда на это тратятся НЕМАЛЫЕ ресурсы и оно НЕ может быть быстрее native кода.

многие _реально_ важные вещи работают быстрее (покажите мне "среднего программиста" на C++ который будет грамотно использовать heap - а на Яве это автоматом) - т.е. выделение памяти под объект очень дешёвое)

Быстрее чего?? Вы утверждаете что Native код после JIT будет быстрее ....Native кода который откомпилирован и оптимизирован компилятором на основе более полной информации??? Что значит правильно использовать heap??? Выделение памяти это всегда недешевое удовольствие, и особенно для много потоковых систем.

2. На Яве меньше утечек ресурсов - приложение реже падает.

На С++ как напишешь так и будет работать. Это в яве утечка ресурсов возможна даже если все правильно написано.

3. Приложение написано будет быстрее из-за более развитой стандартной библиотеки и большого количества очень стабильных OSS библиотек.

С чего это на Яве библиотеки более стабильные? Получается парадокс...пишут менее квалифицированные - а результат более стабильный... Вам самому не смешно?

[nightmare2]

Согласитесь, что это критично только для очень узкого круга задач.
Зато C# могут выучить все, а C++ только особо одаренные.

Согласен что могут выучить все. Но те кто не смог выучить С++ не сможет писать эффективные программы даже на C#. А Visual Basic и аналоги существовали давно. Так что всетаки C# это развитие VB ниши, а не замена C++.

>Согласен что могут выучить все. Но те кто не смог выучить С++ не сможет писать эффективные программы даже на C#.
Но они смогут писать работающие программы, очень часто этого достаточно.
K тому же эффективность относительна.

>А Visual Basic и аналоги существовали давно. Так что всетаки C# это развитие VB ниши, а не замена C++.
И да и нет. Конечно это VB / Delphi ниша. Но многое взято из C++.
Мне кажется, что это своего рода попытка обобщение всего лучшего что было на тот момент. Если сравнивать VB и C# то это небо и земля.

[Zombie416]

2. На Яве меньше утечек ресурсов - приложение реже падает.

Утечки памяти - это да, редкость в 100% managed code, да только ценность этого сомнительная, памяти нынче навалом и дешево.

А вот с утечками ресурсов как раз все печально у Java, и по (ИМХО) ошибке переписывателей, в C# тоже. Гораздо хуже чем в C++, и приводит к мелким, редким, но неприятным последствиям если в неожиданный момент кидается исключение, с leaks и освобождением ресурсов неизвестно когда и кто знает в какой нити. С чем приходится бороться кучей нечитаемых try/finally (которые из-за убогого препроцессора даже не спрятать), critical finalizers и прочей левой чепухой.

И рабочее место кассира писать на C++ и C# примерно одинаково быстро, при знании библиотек. Но C# на порядки быстрее компилируется и собирается. И что реже падает - это да. Но проявляется не в программах Hello world, а в больших проектах с кучей библиотек разного качества писанных людьми разной квалификации. На C++/C достаточно одного идиота в команде, или временного помрачения неидиота, и появляется непонятно откуда вылезающий memory overrun или stack corruption. Иногда. И ищи свищи. С managed кодом можно идиотам запретить писать unsafe код (они и сами боятся), и проще анализировать написанное автоматическими средствами.

[Boriskin]

3. Приложение написано будет быстрее из-за более развитой стандартной библиотеки и большого количества очень стабильных OSS библиотек.

С чего это на Яве библиотеки более стабильные? Получается парадокс...пишут менее квалифицированные - а результат более стабильный... Вам самому не смешно?

Т-щ просто не в курсе того, сколько разных либ есть под плюсы.

[ddv]

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

А остальные могут писать на любом, и между (в основном) процедурными компилируемыми в нативный код (не важно на каком этапе и на чьем компьютере) языками вроде C/C++/C#/Java/... большой разницы нет. Где-то синтаксис проще, где-то сложнее, где-то что-то короче записывается, где-то длиннее. На этом принципиальные отличия кончаются.

Несовсем так....Существует не нулевое множество людей которые программируют на C#, но не могут программировать на C++. И об этом говорил предыдущий оратор с которым я согласился. И именно к этому множеству относится мое высказывание.

[Boriskin]

И да и нет. Конечно это VB / Delphi ниша. Но многое взято из C++.
Мне кажется, что это своего рода попытка обобщение всего лучшего что было на тот момент. Если сравнивать VB и C# то это небо и земля

Да проще все, глубоко унутри у вашего шарпа все тот же Вынь32, поэтому никуда от родственности с плюсами было не деться. И никакого перехода на принципиально новый фреймворк (типа с Carbon на Cocoa) пока нет и имхо и не предвидится, так и будет эволюционировать шаг за шагом...

[Zombie416]

Даже если оно и анализирует код на лету ( в чем я глубоко сомневаюсь,..скорее всего он компилирует при загрузке класса или т.п.), то тогда на это тратятся НЕМАЛЫЕ ресурсы и оно НЕ может быть быстрее native кода.

Ресурсов процессора обычно имеется с избытком. И может. И бывает.

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

Больше того, по мере усложнения компьютеров, роста в них количества процессоров (в том числе специализированных) и непредсказуемости на машине разработчика сколько чего будет на клиенте, managed код (=посылка клиенту упрощенного исходного текста для окончательной компиляции и сборки) гораздо предпочтительнее, и с точки зрения разработчика (не надо делать 120 версий), и с точки зрения производительности.

С чего это на Яве библиотеки более стабильные? Получается парадокс...пишут менее квалифицированные - а результат более стабильный... Вам самому не смешно?

Парадокса нет. Стандартные библиотеки пишут люди квалифицированные. А нестандартные не устраивают memory overruns в чужой памяти (ака любимые всеми проблемы с переполнением буферов и дальше хуже) и имеют простой внешний интерфейс с reflection. Это колоссальное преимущество в большом проекте с разными людьми.

[crypto5]

Вы утверждаете что Native код после JIT будет быстрее ....Native кода который откомпилирован и оптимизирован компилятором на основе более полной информации???

Какой конкретно более полной информации? Джава например может знать о наборе инструкций процессора целевой системы, а с++ компиллер нет.

Что значит правильно использовать heap??? Выделение памяти это всегда недешевое удовольствие, и особенно для много потоковых систем.

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

[ddv]

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

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

[zzhou]

1. На Java оно работает быстрее (потому что Jit в Яве анализирует код на лету - учитывая то, как он исполнялся)

Даже если оно и анализирует код на лету ( в чем я глубоко сомневаюсь,..скорее всего он компилирует при загрузке класса или т.п.), то тогда на это тратятся НЕМАЛЫЕ ресурсы и оно НЕ может быть быстрее native кода.

В Яве нет автоматической компиляции в нативный код. Т.е. она не производится обязательно перед выполнением кода - когда Jit решит что код достаточно критичен - тогда и сделает.

Компилирование из bytecode в нативный делается один раз - и для приложения которое висит долго (место кассира, веб сервер) затраты мизерны. Но когда сишный компилятор имеет доступ только к development-time информации, Jit имеет доступ к дизайн-тайм информации.

Т.е. грубо говоря - если забыл указать const в C++ - то оптимизатор его обыно не сможет соответственно оптимизировать. Java - сможет.

многие _реально_ важные вещи работают быстрее (покажите мне "среднего программиста" на C++ который будет грамотно использовать heap - а на Яве это автоматом) - т.е. выделение памяти под объект очень дешёвое)

Быстрее чего?? Вы утверждаете что Native код после JIT будет быстрее ....Native кода который откомпилирован и оптимизирован компилятором на основе более полной информации??? Что значит правильно использовать heap??? Выделение памяти это всегда недешевое удовольствие, и особенно для много потоковых систем.[/quote]

1. У компилятора меньше информации чему у Jit.
2. На Яве есть "куча", которой заправляет VM. Т.е. когда делается new... - то нет автоматического malloc - вместо этого просто VM учитывает что такие-то 20 байт заняты таким-то объектом (malloc выполняется только когда куча уже заполнена). При этом VM:
- Может решить что этот объект может жить на стеке - и выделит под него память на стеке (что быстрее)
- Делит объекты на "долгоживущие", "короткоживущие" и т.д. - соответственно размещая их на куче, нменьшая фрагментацию памяти.

На С++ - это решает программист и это весьма нетривиально (начинаются или игры с библиотеками - или долгие часы в профайлере - или и то и другое сразу)

2. На Яве меньше утечек ресурсов - приложение реже падает.

На С++ как напишешь так и будет работать. Это в яве утечка ресурсов возможна даже если все правильно написано.[/quote]

Примеры утечек ресурсов в "правильно написанной" Ява-программе?

С чего это на Яве библиотеки более стабильные? Получается парадокс...пишут менее квалифицированные - а результат более стабильный... Вам самому не смешно?

1. Кто сказал что на Яве пишут менее квалифицированные? Менее снобские - это да.
2. Результат более стабилен - в том числе - и из-за преимуществ языка.
3. Я привёл пример Hibernate, JSF и т.д. - которых на C++ всерьёз нет, и которые очень сильно упрощают разработку _реальных_ приложений.

[ddv]

Какой конкретно более полной информации? Джава например может знать о наборе инструкций процессора целевой системы, а с++ компиллер нет.

Набор инструкций для C++ компилятора практически известен...А оптимальный SSE4 и java наврятли сгенерит.

[Brazen]

Ни разу за 10+ лет не приходилось такое делать. Но вот как надо извращатся в С чтобы XML разобрать или до БД добраться - это я видел.

Потому C такой и компактный, что все фичи в библиотеках.

Правильно. В разных библиотеках разной степени кривизны. Но настоящие Сишники всё равно будут руками с нуля писать - чтобы не мучатся с чужими багами.

Аналог Hibernate на С++ насколько зрелый есть? Или какой-нибуть JSF.

XML и БД на C# и Яве - часть основной библиотеки. Без них не бывает.

Hibernate - это внешняя библиотека. И в ней таки есть баги. JSF - тягучий кусок дерьма. Могли бы что-нибудь поприличнее вспомнить, хотя бы простецкий JSP или компонентный Wicket, но не JSF. Спасибо, этого не надо.

БД на жабе - это низкоуровневые вещи типа послать запрос, получить таблицу. Или вместо таблицы получить исключение, которое потом через десять этажей надо прокидывать. Минимальный уровень, на котором работа с БД на жабе становится приятной - это iBatis. Таки библиотека. Неродная.

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

--

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

[crypto5]

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

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

Я хочу еще раз спросить, а чего вы так взьелись? Никто не отбирает у С++ рынок высокопроизводительных апликух. Просто оказывается что для очень большого круга задач производительности джавы и с# более чем достаточно, а игры и числодробилки пишите себе на с++.

[crypto5]

Какой конкретно более полной информации? Джава например может знать о наборе инструкций процессора целевой системы, а с++ компиллер нет.

Набор инструкций для C++ компилятора практически известен...А оптимальный SSE4 и java наврятли сгенерит.

Как обычно все скрыто в том насколько "практически известен" и насколько "наврятли"
Ну и вы все еще не ответили на вопрос, какой дополнительной инфой обладает С++ компилятор, и которая не известна джаве?

[ddv]

2. На Яве есть "куча", которой заправляет VM. Т.е. когда делается new... - то нет автоматического malloc - вместо этого просто VM учитывает что такие-то 20 байт заняты таким-то объектом (malloc выполняется только когда куча уже заполнена).

какие всетаки наивные эти java программисты...а "учитывает" VM где???
В C++ тоже есть менеджер памяти который забирает память у системы кусками, а потом раздает и менеджает ее сам.

[crypto5]

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

Вполне можно написать на миксе, ЮИ и всякую бухгалтерию на джаве а то что поближе к железу на С, а вы это к чему спрашиваете?

[ddv]

Ну и вы все еще не ответили на вопрос, какой дополнительной инфой обладает С++ компилятор, и которая не известна джаве?

Как минимум :
1. Все неиспользуемые в данном приложение модули, поля, классы и т.п. На основании этого их можно выкинуть,порезать и вставить внутрь исполняемого модуля.
2. Inline функции, процедуры и т.п.

[crypto5]

2. На Яве есть "куча", которой заправляет VM. Т.е. когда делается new... - то нет автоматического malloc - вместо этого просто VM учитывает что такие-то 20 байт заняты таким-то объектом (malloc выполняется только когда куча уже заполнена).

какие всетаки наивные эти java программисты...а "учитывает" VM где???
В C++ тоже есть менеджер памяти который забирает память у системы кусками, а потом раздает и менеджает ее сам.

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

[crypto5]

Ну и вы все еще не ответили на вопрос, какой дополнительной инфой обладает С++ компилятор, и которая не известна джаве?

Как минимум :
1. Все неиспользуемые модули, поля, классы и т.п.
2. Inline функции, процедуры и т.п.

В джаве хотспот тоже не компилирует неиспользуемые поля и классы. Что там дальше?
Про инлайн я вообще не понял? Я тоже знаю такое слово..

[ddv]

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

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