GD Star Rating
loading...

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

Бонусом для Aux’a: Why I love everything you hate about Java

Пик анрелейтед.

Админы и сочувствующие посетители hardblog.net посчитали злободневным:белые ночи, поликлиники и Невский

Tagged with →  

146 Responses to Старая (2006), но интересная

  1. Xuaapp:

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

  2. Xuaapp:

    I used to hate all that stuff too. But you know what? After working for all these months on these huge pieces of Twitter infrastructure I’ve started to love the AbstractFactoryFactories.

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

  3. Letno:

    Давайте уже вздуем друг дружку!

  4. Aklre:

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

  5. Peeef:

    Статья херню говорит (я про ту, что C хаит).
    1) Чувак всем рассказывает как намного лучше писать intense scientific computing не на сях, однакож все самые производительные современные либры, даже если раньше они были написаны на Фортране, сейчас компилируются именно из С.
    2) Про aliasing он тоже ступил. Restrict жежь.

  6. Xuaapp:

    : вот, отличное замечание (: Чувак хочет в мир руби, например, принести паттерны явы и чтобы они работали как в яве. Это тоже самое, что совать их в C обычный – так не работает. Человек просто не умеет пользоваться инструментами отличными от явы. И это не всегда минус, возможно, он гений в плане явы, в таком случае пусть ею и занимается.

  7. Peeef:

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

  8. Aklre:

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

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

  9. Aklre:

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

  10. Peeef:

    : а вот абстрактный код про… писать на чём–то высокоуровневом, что будет пользовать эти сишные либы и что будет бешено оптимизироваться

    Все самое “бешено оптимизированное компилятором” уже в либах. А высокоуровневый код можно ленивенько на матлабе или питоне пописывать.

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

  11. Aklre:

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

  12. Peeef:

    : Ты неправильно прочитал. Он реально жалуется на алиасинг поинтеров и что, мол, Фортран без поинтеров якобы скомпилирует лучший SMD код нежели С, который в поинтерах не разберется. Практика однако показывает обратное.

    Учоный никаких С кодов оптимизировать не должен, бред это. Всё критичное уже есть в либрах которые уже оптимизированы под нужную платформу и под нужный юзкейс, и никакой ОКамл там не поможет. Учоные же пишут на R, матлабе и питоне.

  13. Peeef:

    : лучший SMD код
    *SMP или SIMD, имелось в ввиду, на выбор

  14. NotPhone:

    Во второй статье самое сильное – это:

    val future = new Future {
    doSomeWork
    }

    С головой выдает джавистов и прочих *плетов как они есть.

  15. Xuaapp:

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

  16. KipMilk:

    http://marc.info/?l=git&m=12411170260972…
    а вот тут гуглер рассказывает как они сишный гит перепиливали на джаву

  17. Sukon:

    : А вот гуглерам точно платят за невозбранное делание хуеты в рабочее время.

  18. Aklre:

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

  19. Xuaapp:

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

  20. Aklre:

    : как раз вчера приятель-контрактор цитировал своего текущего клиента, начальника отдела: “ты что? у них тут у половины PhD, они не поймут”.

  21. Aklre:

    : что-то мне уже не так радостно.

    короче если класс заявлен, как class Foo {} из него всё же можно вытащть String.class а если Foo {} то хер.

  22. Aklre:

    : явно пора спать

    если класс заявлен, как class Foo[String] {} из него всё же можно вытащть String.class а если Foo[T] {} то хер. Точней хер в виде Т.

  23. Lagapp:

    : А чего такого тут?

  24. Lagapp:

    : Вообще type erasure же!

  25. Lagapp:

    : Зато смотри как оживились все. И вообще, если есть хорошие статьи – пиши посты, кидай ссылки. Чего я один тут как массовик-затейник?

  26. Raeno:

    пишут всё, пишут. кто-нибудь за эти 15 лет объяснит – почему Java так, блядь, тормозит и жрёт столкьо ресурсов?

    в браузере 3Д на флеше скачет-летает, WebGL разный, а банковские апплеты из 5 окошек рисуются со скоростью, видимой глазом

  27. Hsvhlam:

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

  28. Ocser:

    : потому что write once, work everywhere, а не write once, work faster than anything else.

  29. Hsvhlam:

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

  30. Xuaapp:

    : html+js самый настоящий write-once. И веб-демка Microsoft их интерфейса Metro работает в браузере в моём телефоне быстрее и плавнее, чем “нативный” софт на яве. Ебанись, блядь!

    Ява – говно. С любой стороны.

  31. Aklre:

    : я ж о том же. но там всё хитро. ирэйжа эта грёбаная не делается для анонимных классов, например. то есть иногда всё же можно. code.google.com/p/gentyref/ например

  32. Aklre:

    : потому что все эти 15 лет жаба была на 99% энтерпрайз инструментом а там подождать денёк никого не напрягает. наоборот, убедительно система работает.

  33. Ocser:

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

    ну ей богу, смешно тебя читать даже

  34. Xuaapp:

    : я прекрасно знаю как оно работает в банках. И то, что там творится сплошное трололо я тоже знаю. И это ещё одна причина, по которой ява – говно. На ней невозможно писать что либо отличное от говна.

  35. Sukon:

    : Дада, уже лет 5 мне интересно, хоть что-нибудь на нём написали уже?

  36. Xuaapp:

    : я на нём написал hello world

  37. LanTunes:

    : ебаные теоретики..

  38. Ocser:

    : за что Серёжа не берётся..

  39. Xuaapp:

    : я не виноват, что каждый кодер финансового софта – Серёжа.

  40. KoZlo:

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

    your argument is invalid

  41. Peeef:

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

    Херня. Один и тот же код что на сях, что на фортране будет работать сравнимо.

    Кроме того, на фортране можно написать более–менее универсальный алгоритм, который будет неплохо оптимизироваться на целый класс систем.

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

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

    Если “ученый” занимается разработкой алгоритма и цель его – написать статью и показать как его алгоритм быстрее других, уж поверь мне – он в курсе и про restrict и про все остальное. Если же ты рассматриваешь “ученых”, которые просто используют готовые алгоритмы, то для них все что нужно уже есть в либрах, а если в либрах нет – они обойдутся без этого.
    А еще есть “ученые”, которые как бы пишут свои алгоритмы, но им до лампочки разница в скорости вплоть до 5х разницы. Они будут писать на том, языке, на котором им удобнее.

  42. Peeef:

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

    В любом случае фортран со своими компиляторами в этой области вообще особо не выделяется.

  43. Xuaapp:

    : про банки всё просто – софт для Fortune 500 пишут такие конторы, как Accenture. А Accenture пишут такую индусятину, что диву даёшься как им всем до сих пор зубы не повыбивали. Так что в банках такая же хуета.

  44. Peeef:

    : Ну прошлый мой пост потерли, поэтому я лучше посижу молча, покритикую других 🙂

  45. Xuaapp:

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

  46. Aklre:

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

  47. Xuaapp:

    : с этим я не спорю (: С другой стороны зарплаты в мире явы за индусятину ого-го.

  48. Ocser:

    : это конечно общий тренд, насчёт индусятины. И насчёт Аксенчур как софт комании для банков я честно не в курсе. Я считал, что это делает например Misys. И делает не плохо, хотя и не идеально, наверное.

    По-поводу сбера я не понял. Там вообще АБСка собственной разработки, насколько я знаю – единственный банк в россии, работающий на своей АБС. И я имел в виду продукты уровня процессинга, абс, фронта и портала, когда говорил о роли Java. А не о вских там обвесах, подкрылках и задних спойлерах.
    Кстати госорганы госорганам рознь. Мне понравилось недавно в одной компашке, которая делает апкоминг проект Д. Медведева. Там хоть и молодёжь была, но с желанием научится и вполне ясными головами. Хотя в целом госорганы – унылая дыра, где никто не потивирован делать хорошо. Увы.

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

    Изначально тема, с которой я не согласился была про язык программирования. Мне нравится Java (это вы уже заметили). Он очень гибкий язык, на котором можно многое, чего нельзя сделать на С и C++. Может он иногда медленнее и ест больше ресурсов, но как известно, современные процессоры выполняют бесконечный цикл за доли секунды. И в первой же статье указано, что с включенным JIT ява отрабатывала на уровне программы на C. И это было в 2008.
    А уж что на этом языке пишут. Кто пишет и как – это тема отдельная.

  49. Hsvhlam:

    : Я высоко ценю твои мысли об идеальном устройстве мира, но в реальности херня составляет 80% всего кода, и компиляторщики должны изъёбываться, чтобы сделать из херни конфетку.

  50. ParApp:

    : фортран – клеви, код, сокмпилированый intel fortran compiler часто обгоняет по производительности аналогичный сишный код. Современный фортран очень сильно не соответствует представлениям большинства программистов о нем, это очень неплохой инструмент.

  51. Hsvhlam:

    : Окей, я погорячился. Действительно, фортран и си компилируются сейчас примерно одинаково и работают с примерно равной скоростью.
    Но это не потому что си так же легко оптимизировать, а потому что и си, и фортран на параллельные системы оптимизируют очень хуёво.
    Серьезное автоматическое распараллеливание сейчас есть только в академических полуработающих на узких классах программ системах, типа GCC Graphite.

  52. Hsvhlam:

    : начинка у IFORT и у ICC почти одинаковая, серьезной разницы быть не должно.

  53. RARwin:

    : openmw. Но и его переписали на плюсы.

  54. ParApp:

    : я отвечу просто – векторизация 🙂

  55. Letno:

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

    Удобство от новой технологии не всегда компенсирует затраченное на освоение время.

    На счет того что Java-говно, не уверен. То что является номером один в мире, не может быть таковым. Мнение программистов не особо интересно.

    А вообще, настоящий программист пишет не на том что ему нравится, а на том на чём есть возможность.

  56. Aklre:

    дгузья! давайте устгоим тугнир!
    правила просты: оговариваем нехитрый но трудоёмкий в выполнении алгоритм (чтоб в один файл на строк 400 уложиться). каждый участник пишет его на жабе и на плюсах, делает бенчмарк(время, память) и потом здесь меряемся хуями.

    пгофит!

    моё предложение: шаг игры жизнь на поле 10000х10000

  57. RARwin:

    : опять ведь временем холодного старта будете меряться

  58. Peeef:

    : Да, и компилятор С/C++ здесь во первых рядах.

  59. Peeef:

    : Замер времени никто не мешает делать внутри алгоритма.

  60. Ocser:

    : с поправкой: работать должно под ОС Андроид

  61. Aklre:

    : а. да, ещё jre нужно оговорить. пусть сановская будет, хоть и не вся кошерная.

  62. Lagapp:

    : может ещё числа фибоначчи повычисляем?

  63. Aklre:

    : какие все ироничные сегодня.

    давай. произведение первой тысячи чисел фибоначчи. в 400 строк.
    кстати, почему бы нет?

  64. Xuaapp:

    : настоящий программист выбирает инструмент исходя из задачи.

  65. Aklre:

    : in soviet union инструмент выбирает задачу и программиста

  66. Xuaapp:

    : как язык ява ащще ни разу не гибкая (: Но в принципе нормальный такой взрослый язык. Обычный. А про JIT – я люблю пример знакомых, делающих одну из самых популярных игр для Facebook (не скажу какую, но из топа десять). Писали изначально на Java, ибо опыт у людей явовый. Упёрлись в производительность и переписали как сумели на PHP. Ржака, но стало быстрее, лол.

  67. Xuaapp:

    : я придумал задачу интереснее. Берём произвольное изображение размером 10000х10000 пикселей (bmp чтобы не ебать мозг), на выходе надо получить такое же изображение, но со сдвинутым hue. Например, на 50% не важно. Ограничим доступную оперативную память 64 килобайтами (на всё, включая загруженный в память код и доп расходы типа VM) и посмотрим кто круче, лол. Ну оок, ява тут слила по-дефолту. Снимем ограничение на память.

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

  68. Letno:

    : программист в большинстве случаев ничего не выбирает. Выбирает тот кто дает деньги – работодатель, заказчик, руководитель проекта и т.д.
    Программист конечно может сменить место работы. Но и тут выбор инструментов будет не за ним.

  69. Letno:

    : неинтересно. Самый красивый и быстрый код будет для GPU. Сунуть картинку в видеокарту и применить соответствующую матрицу для буфера цвета.

  70. LleLt:

    : извини, бро, но вот это
    Он очень гибкий язык, на котором можно многое, чего нельзя сделать на С и C++.
    ты очень преувеличиваешь. Во-первых, про невъебенную гибкость, во-вторых, про “нельзя сделать на С/С++”. Второе – вообще выглядит дешёвым слоганом из брошюр клуба фанатов явы. Более того, на с/с++ можно сделать такое, от чего ява вообще мхом поростёт от зависти.
    Про проблемы человеческих ресурсов ты правильно написал, это касается не только программирования. Но, опять же, касательно языка, каждый день появляются тысячи сообщений в интернетах о диких тормозах явы везде. Далеко ходить не нужно, пресловутый Eclipse, на работе ERP софт от Oracle, Accurev, да примеров масса и это не прыщавые школьники. И вся эта хрень бессовестно жрёт ресурсы и загружает процессор бессмысленными действиями (чего только stack trace стоит посмотреть, миллионы идиотских классов). И не нужно рассказывать про огромные ресурсы современных компов, ява не одна живёт на компе, есть ещё и другие пожиратели, кому эти ресурсы тоже пригодятся. У меня рядом живут VS 2010 и Eclipse, уверяю, первый жрёт ресурсов на порядок меньше, хотя проекты там на тот же порядок больше, но это не мешает яве сожрать 1,5-2 гига виртуалки, после чего винда начинает бешено свопиться и тут уже VS подтормаживает на компиляции. Ой, да чего говорить, в интернете уже лет пятнадцать одно и тоже повторяют, а воз и ныне там.
    Смотреть на синтетические тесты расчёты мифических алгоритмов float/string никому нахуй не нужно, это нигде не используется. В реальной жизни софт выполняет очень широкий круг задач, и в итоге все эти ебанутые горы фреймворков тупят так, что хочется разбить все мониторы вокруг. Потому скорость какие-то алгоритмов нихуя не показатель для явы, это синтетика. Единственный фактор – восприятие человеком. И если последний постоянно видит и жалуется на жестокое тупилово, то все остальные доводы, включая мега-довод “нннуууу, у меня всё пашет отлично”, ему нихуя не интересны.

  71. LleLt:

    : давай лучше жизненный эксперимент. Переписываем любой тупящий софт с явы на С++ и замеряем рост показателей. Профит! Например, Eclipse. Спасибо скажут миллионы.

    И да, измерять любой один алгоритм – бессмысленная задача. В люди жизни пользуются комплексным софтом, который не только считает длину строки задом наперёд. Нет ни единого софта, который выполняет только лишь один алгоритм на 400 строк. Для таких задач берут фортран, если уж на то пошло 🙂 Давай сравнивать браузеры, редакторы сложнее notepad (аудио/видео/текстовые), IDE, игры, ОСи, etc., то есть то, чем народ пользуется изо дня в день. Вот там замерим и качество кода, и ынтерпрайз, и скорость, и масштабируемость, и поддержку SMP, и так далее.

  72. Xuaapp:

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

  73. Xuaapp:

    : ты не сунешь 400 метров картинки в GPU за раз – это раз. Второе – этот пример очень хорошо покажет нам избыточность того говна, что любят хуячить жабоёбы.

  74. Xuaapp:

    : можем попробовать найти веб-браузер на яве и поржать. Хотя любая IDE уже показатель – клипса ёбаный тормоз, VS – нормуль даже на старом железе.

  75. Aklre:

    : ты меня похоже в чём-то обвиняешь. это забавно.
    1. должен заметить, что жабу я тоже не люблю. во-первых ирейжа, во-вторых параноидальный страх нововведений, что приводит к паттернам, решающим проблему но код красивей не делающим, в-третьих тормоза, да. как-то лет 5 назад я отказался от азуреуса потому что это ж был пиздец ваще. теперь в основном пользуюсь делюгой, которая вроде на питоне.
    2. твой пример во-первых, как верно заметил , лучше решается на КГБ и си тут тоже сосут, а плюсы тут вообще ни при чём, хотя честней всё же сравнивать языки из одной песочницы ооп. во-вторых ты сказал, что чистый си выигрывает у жабы в задачах прямого доступа к памяти и её потреблению, я конечно туповат, но не идиот и спорить с этим не стану.
    3. при том, что жабу я не люблю, если мне интересно или хорошо платят, я вполне на ней могу писать. это всего лишь язык. если будет нужно, потом перепишу на плюсах и получу выигрыш по памяти. и не уверен, что по скорости.

  76. Sukon:

    : Векторизация чего именно?

  77. Sukon:

    : Это который?

  78. Sukon:

    : Энтерпрайзный?

  79. Xuaapp:

    : векторизация векторных векторов.

  80. Letno:

    : у меня в ноуте 1ГБ например. А если и этого не хватит, то обработаю по частям.

  81. Xuaapp:

    : угу, через синглтоны с фабрикой.

  82. Xuaapp:

    : дело не в прямом доступе к памяти.

  83. Sukon:

    : Покажи код.

  84. Xuaapp:

    : я красненький забыл.

  85. Xuaapp:

    : я эту фигню лет шесть уже не видел, никакого кода не осталось. Так побаловался и всё.

  86. Hsvhlam:

    : очевидно, вычислений над массивами.

  87. Ocser:

    : спорить не хочется мне, хоть вы и докопались только к скорости и жмёте на педаль. я уже на это отвечал, в начале самом.

    по-поводу мха от зависти, интересно, честно, дашь примеры?
    про гибкость, уточню только, что я имел в виду, что можно на лету генерить и вставлять различные proxy и interceptor’ы. AOP. reflection в полный рост. Вот тут уж мху хватит и для C++. (к.NET реализации не относится)
    Чтоб было понятно, я занимаюсь распределёнными системами. Никаких пользовательских интерфейсов и свопящихся виндов. И тут что-то альтернативное Java EE найти сложно. Да, может быть Remoting. Сто лет его не трогал, не в той конторе я работаю 🙂

  88. Letno:

    : где он байты через аппаратный UART проёбывал и доказывал что это круто и есть тайное знание.

  89. Aklre:

    : дык вперёд, я типа судья 😉

  90. Letno:

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

  91. ParApp:

    : вычислений http://software.intel.com/sites/products…
    Я могу сказать только за С++ компилятор MS, он векторизацию не выполняет совсем, даже если включить в настройках проекта SSE инструкции, он их при кодогенерации практически не использует. Там приходится использовать compiler intrinsics вручную, код в результате выглядит убого, я уже молчу о том как он пишется и поддерживается. Если в твоем алгоритме много векторных операций, то проще использовать фортран, нежели писать на няшной сишке код с компиляторными интринсиками.

  92. Xuaapp:

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

    1. Менеджмент ставит новую задачу на предварительном митинге и даётся некоторое время разрабам на установление сроков выполнения и выбора технологий.
    2. Если программеры находят новый для компании инструмент хорошо знакомый хотя бы одному, то проводится собрание программеров для выяснения плюсов и времени обучения доп. людей на роль junior (один уже не джуниор).
    3. Начальству, в котором присутствует CTO (который в теме и может оценить наш пиздёж) представляется презентация с плюсами, минусами, возможными подводными камнями. Начальство задаёт вопросы на тему интеграции с существующими решениями, сложностью поиска и обучения кадров и т.д.
    4. По результатам презентации делается общий вывод – надо оно нам в данной ситуации или нет. Если плюсы очень хорошо перевешивают, то новая технология принимается в оборот.

    С бодуна никто ничего не делает, ибо будет бардак.

  93. Xuaapp:

    : erlang и твоя ява плачет.

  94. Letno:

    : ты описал обычную ситуацию.
    Мне например пару лет назад навязывали технологию которая мне активно не нравилось. Я предложил другой вариант, хотя ни я и никто у нас им не владел. Причем мой вариант требовал нехилых вложений. В итоге удалось убедить руководство и заменили не только софт, но и железо всему департаменту: новые некислые компьютеры с внешними видеокартами и двумя мониторами.
    Но это не значит что я выбрал технологию. За нее проголосавали рублем хозяева бизнеса.
    И если бы убедить не удалось, то пришлось бы заниматься (на мой взгляд) говноклюйством.

  95. Hsvhlam:

    : интел лучше.

  96. Sukon:

    : А чего его потерли? Хороший же был пост.

  97. Sukon:

    : гцц может быть и не лучшим образом но с -ftree-vectorize вроде бы пытается что-то сгенерить. Другое дело что для этого сишный код надо писать более наглядным для конпайлера образом, что делает этот процесс не совсем автоматическим.

    Как с этим делом у фортрана?

    (Всё равно векторизацию R им не обогнать, имхо).

  98. Sukon:

    : От erlang я сам кровавыми слезами заплачу.

  99. Sukon:

    : Дак сначала надо определиться, что делать-то.

  100. ParApp:

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

  101. Aklre:

    : *бдыщь* *level up* второй уровень абстракции!

  102. LleLt:

    : примеры? Да какие могут быть тут примеры. Посмотри список фич в С++11 для примера, вспомни метапрограммирование, где унылые генерики молча в уголочке завывают, это обычные базовые примеры. Но здесь же мы сравниваем виртуальную машинку и полную статику, собственно сравнение некорректно, джаве недоступны некоторые вещи по определению. Все эти упомянутые прокси, интерцепторы, аопы и прочие жопы вполне себе нормально програмятся на сях, вопрос только нужны ли они в сях. Исходя из статической сущности многие вещи теряют актуальность и реализуются по другим принципам. Сравни то, что генерит ява компилер с решениями на плюсах. Сравни скорости, замерь память, затраты ресурсов. Reflection нужен только тем, кто без него жить не может, то есть ява и шарп, плюсам он ни в хуй не впился. Распределённые системы реализовывались десятки лет назад и реализуются и поныне, на тех же сях, яве, шарпе, скрптовых языках и прочих. Я не вижу никаких существенных преимуществ явы в этом вопросе. Мне, например, нравится пример систем для бирж, где виртуальные машины полностью вытеснены чистыми плюсами.
    Извини, но мне правда кажется, что у тебя есть обширные знания только лишь в яве, потому адекватности сравнения и суждений нет. Возможно, я ошибаюсь. Но неправильно так сливать плюсы, не имея о них полного представления. Мне всё же хотелось бы увидеть что именно “нельзя сделать на С и С++”.

    На самом деле весь вопрос, как всегда, в бабле. Стоимость проектов на яве почти всегда дешевле, чем на плюсах. Изучение плюсов дороже (сложнее), спецы на плюсах дороже, в итоге саппорт проект дороже не потому, что сложнее, а потому, что спецы дороже стоят. Но отличные специалисты напишут хороший код, который будет лёгкий, читаемый, быстрый, еtс. Но стоить будет существеннее. В итоге за половину стоимости нанимают яву, получают громоздкие решения и тучные стада явадевелоперов, которые думаю, что их язык номер один потому, что он такой охуенный и крутой. А на деле выходит эдакая совокупность факторов, снижение стоимости железа, роста количества девелоперов вообще, снижение планки образования у среднего девелопера, и прочих.
    Выше шла речь про банки, что отлично иллюстрирует мою мысль. Низкий уровень людей, низкий уровень зарплат, жлобство, всё это в итоге приводит к тому, что мы видим.
    Я не умаляю заслуг явы или шарпа, или чего-то другого. Любой инструмент чем-то выигрывает, чем-то проигрывает. Потому нельзя говорить строго категорично “это – хуйня” или “то – лучшее”.

  103. KipMilk:

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

  104. Ocser:

    : бла-бла скорость, память, бла бла. и так уже целый день 🙂

    я не сливаю плюсы! вообще ни слова против них не написал. Они мне нравятся, по своему. У меня есть проекты, на счету, которые я делал на C++. Почти уверен, что они до сих пор где-то там ещё работают (дело было 7 лет назад). Но кстати, это была CORBA – и это был гемор, как я это сейчас понимаю, по сравнению с тем, как это можно было бы легко и непринуждённо написать на Java.

    По поводу хороших специалистов и их кодов – в 90% компаний (не девелоперских) используются покупные решения в качестве ядра. Они покупают готовый продукт. И в сущности им похрен, на чём он написан. Громоздкие решения и на C++ получатся. Зависит от размера решения. Если достаточно набрать 2-3 хороших спецов для короткого проекта – это ок. Но когда надо 20 чел на 5 лет, тут уж полюбасу подтянутся тучные стада сидевелоперов и сварганят мамунегорюй.

    И еще ты ошибаешься. Спецы на плюсах не дороже. Я специально пересел на Java, потому, что хотел зарабатывать больше. Что-то изменилось за 7 лет? Сомневаюсь.
    >Потому нельзя говорить строго категорично “это — хуйня” или “то — лучшее”.
    именно это я и пытался сказать, аминь 🙂

  105. Hsvhlam:

    : в фортране есть такие штуки, как array operations, которые вообще анализа не требуют, бери да векторизуй.
    http://www.mcs.anl.gov/~itf/dbpp/text/no…
    Про R не в курсе – расскажешь?

  106. Peeef:

    : R как язык программирования – говнище. Не надо про него ничего рассказывать. Вдобавок у него нет компилятора, поэтому к обсуждению он вообще не относится.

  107. Xuaapp:

    : программеры JavaScript получают больше яваёбов. От 150 евра в час, ебанись!

  108. Sukon:

    : Как язык для эффективных матричных вычислений – вполне себе. А раз он Тюринг-полный, то и как язык программирования сойдет.

  109. Sukon:

    : *хелловорлд_на_яве.html*

  110. LanTunes:

    : я защитил диплом по теме “генерация фотореалистичных изображений методом трассировки лучей”, какое-то длинное у них пересечение..

  111. Peeef:

    : Ну они просто всё расписали, включая вычисления всех промежуточных векторов (n, ku, kv, r.Dir, r.Org) и пару не очень нужных проверок (например, на вырожденность треугольника).

  112. Ocser:

    : Не надо изобретать велосипедов. Visual age – папа эклипса, был написан на Smalltalk (тогда C++ еще только начинался), а вы из человека обезьяну делать собрались, новаторы

  113. LleLt:

    : дык для благого дела, для тестов! ха-ха

  114. Sukon:

    : Твой код напоминает мне выжимку из книжки Борескова и Шикина.

  115. Sukon:

    Еще бложик про CS education.

    Тыц!

  116. Arbam:

    детский сад 🙂

  117. Lagapp:

    : как скажешь

  118. Lagapp:

    : а кто ето кстати?

  119. Sukon:

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

  120. LanTunes:

    : они были взяты за основу.

  121. Aklre:

    : боресковым и шикиным

  122. XawSport:

    : “Java тормозит” неактуально уж лет 7-8 как. В начиная с версии 1.3 по 6 было сделана чёртова туча оптимизаций. Так что сейчас аналогичный код на C++ и на Java работает со схожей производительностью. Тормозит, скорее всего, не Java, а кривой код, который на ней написан. Тут уж, извините, в ногу выстрелить есть масса способов. Язык тут не виноват.

  123. XawSport:

    : Контрпример про биржи. LMAX, например, целиком на Java написан. Функциональность там по сравнению с другими биржами несколько ограниченная, но взамен они предоставляют желанный многими ultra low latency с 100К транзакций в секунду, на каждую из которых уходит менее 1 мс.

  124. XawSport:

    : и, да, чтобы не быть голословным – вот набор бенчмарков, которые показывают, что хоть Java немного отстаёт в производительности по сравнению с C++, этот разрыв не так велик, чтобы вопить “Java тормозит”.

  125. XawSport:

    : bullshit. к производительности зачастую предъявляются очень высокие требования.

  126. Peeef:

    : Ну жрать в 50 раз больше памяти это уже достаточный повод чтобы повопить.

  127. XawSport:

    : Но, во-первых, это про потребление памяти, а не про скорость работы, а, во-вторых, далеко не во всех задачах разрыв в 50 раз. В общем, правильно говорят, всё от задачи зависит. Есть те, на которые Java подходит меньше, чем С++.

  128. Peeef:

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

    То, что на ней можно быстрые алгоритмы писать это понятно, но это мало кого интересует.

  129. Aklre:

    : не спорю. если производительность – одно из начальных требований проекта. если нет и наняты загадочные индусы с опытом в J2EE я бы не ожидал быстрого кода.

  130. Aklre:

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

  131. Aklre:

    : gc абсолютно не обязательно должен происходить дискретно и агрессивно. я, далёкий от жавы, знаю две виртуальные машины, имеющие “непрерывный” коллектор.

  132. Peeef:

    : Когда я следил за Явой у меня было впечатление что все (включая Sun) только и делали что пилили для нее разные коллекторы: инкрементальные, в отдельном потоке, с хитрыми подсчетами ссылок, рекурсивными инкрементальными свипами, умными поколениями хипа, и чего там только не было. И тем не менее, Ява продолжает жрать память и весело притормаживать.

  133. XawSport:

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

  134. XawSport:

    : В общем случае гуи-приложения на Java – это досадная ошибка, ей-богу. Я разрабатывал такие 4 года, и могу сказать наверняка, что Swing непростительно устарел уже к 2006-му году, когда вышел.NET-овский WPF. К сожалению, Sun продолбала возможность занять эту нишу.

    Если говорить о тормозах, то постоянная сборка мусора – это ненормальная ситуация. Тут надо либо разбираться, где память утекает, либо дать больше памяти, если утечек нет, и просто действительно много памяти надо.

    Кстати, попадаются приятные исключения. Не скажу на Eclipse, но в Idea я провожу очень много времени и могу сказать, подтормаживает она редко. Это справедливо для версий 8+. При этом выделенных 512 Мб вполне хватает для проекта с >2K классов и кучей конфигов.

  135. XawSport:

    : Ага, а в 6up14 так они и вообще выпустили сборщик мусора, который может имеет предсказуемое время работы и настраивается. Допустим, не считает пользователь тормозами задержку в 100 мс раз в минуту, тюним сборщик мусора этими параметрами, и вуаля! Видимых тормозов нет.

  136. Lagapp:

    : Считать память в 2012 году — это смешно, ей-богу. У меня даже на рабочем ноуте 8 гигов стоит. Не потому что я мажор и олигарх, она действительно стоит копейки сейчас.

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

  137. Peeef:

    : У меня тоже на своем ноуте 4 гига, хотя я вообще бедный студент. Поэтому я на Яву не жалуюсь.
    Но я регулярно вижу людей, которые жалуются и в принципе понимаю их.

    Насчет наукоемкости Явового GC не поспоришь, но тем не менее банальный референс каунтинг, использующийся в большинстве других языков зачастую дает визуально более “резвый” результат чем все Явские изыски.

Добавить комментарий