Это распространено для прототипа на языке более высокого уровня? [закрыто]

В настоящее время я играю над идеей начать проект, который намного превосходит мои нынешние способности в программировании на языке, с которым у меня очень мало реального опыта (C). Было бы полезно создать прототип на языке более высокого уровня, с которым я более знаком (например, Perl / Python / Ruby / C #), просто чтобы я мог получить общий дизайн?

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

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

Использование C не делает ваше приложение быстрее. Если у вас есть возможность выбрать другой язык программирования для вашей платформы, я настоятельно рекомендую его.

Как сказал Билл Харлан :

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

Если вы действительно можете предсказать проблемы с производительностью, подумайте об использовании C ++. cprogramming.com очень красиво говорит :

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

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

Это было бы нецелесообразно, потому что а) части тех языков, которые переводят непосредственно в C, не будут проще, и б) части, которые не переводятся непосредственно в C, будет сложнее переписать в C, чем если бы вы написали их на С во-первых.

Это не вопрос с категорическим ответом да или нет. Позвольте мне взвесить анекдот.

Пример 1

Мне было поручено перенести игру, написанную на Java, на Flash, AS3. На первый взгляд, это может относительно гладко происходить. В конце концов, вы можете считать такую ​​работу более четкой, чем обычная работа с клиентом, потому что у вас уже есть полностью встроенная функциональная спецификация в форме исходной игры. Java и AS 3 являются высокоуровневыми языками, и AS3 имеет много общих черт с Java, таких как структуры пакетов, единичное наследование / множественный интерфейс, строгая типизация (opt-in) и понятия публичной / защищенной / частной переменной и объявления функций. В то время я все еще был очень зелен в Java и совершенно не знаком с исходным кодом. Так что я просто нырнул, чтобы увидеть, что я мог найти, надеясь, что это будет быстро и легко.

Как оказалось, автор кода попытался создать абстрактный движок, который мог бы быть перенесен из Java в некоторую неопределенную другую среду. Это дало мне надежду, что это будет просто в порт. К сожалению, вместо этого я обнаружил, что я смотрю на перспективу переизобретения самой Flash поверх Flash без использования Threads. Как оказалось, буквальный порт просто был бы плохой идеей ... кошмаром производительности. Кроме того, в игре реализован собственный пользовательский язык сценариев, что означало бы создание парсера и лексера для этого языка, если бы я надеялся использовать все исходные файлы исходных данных.

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

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

Пример 2

Заметив, что делал разработчик Java, пытаясь создать переносимую кодовую базу, я начал делать что-то подобное для себя в своей работе с Flash ... писать код, который не сильно зависит от расширения классов flash.display. *, Например, и используя композицию для создания представлений. Не слишком полагаться на flash.event. * И вместо этого писать собственную легкую систему передачи сообщений, не привязанную, в частности, к языку или платформе. Я недавно закончил игру, используя упомянутую платформу, и хотел посмотреть, будет ли легко перенести ее на C # (язык, который я знаю так же, как и на Java и AS3), как проект Unity 3D. Как оказалось, это было гораздо успешнее! Потому что я думаю более свободно в AS3, чем в C #, благодаря тому, что уже написанные алгоритмы сэкономили массу времени. Все, что мне нужно было сделать, это просто изменить синтаксис, который не

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

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

Кроме того, с помощью псевдокода вы получите лучшее понимание того, как на самом деле работает ваша система.

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

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

Вы можете создать прототип алгоритма - сгладить ошибки проектирования базовой логики, используя определенно язык «очень высокого уровня» (скажем, Matlab, возможно, Ruby). Используйте его, чтобы доказать, что ваш алгоритм работает и работает правильно, а затем внедрить его с нуля на «низкоуровневом» языке.

Вы не многого выиграете, если выберете C ++ или даже Java или C # в качестве «высокого уровня», а C - «низкого уровня», потому что увеличение читабельности не будет значительным, а «перевод» будет все еще довольно болезненным и довольно ошибочным. склонный. Идея суть в том, что движок вашего проекта в реализации высокого уровня не должен занимать больше, чем один-два экрана, быть легким для понимания, легким для чтения, и все предостережения должны быть до боли очевидны - по сути, работающий, работающий блок диаграмма.

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

Так что это определенно проблема C / C ++, хотя есть несколько довольно хороших реализаций Java.

Разработка правильных алгоритмов, которые хорошо работают, намного проще на языке более высокого уровня. Обычно это случай нескольких вариантов и сравнения результатов. Затем вы можете перевести «выигрышный» алгоритм на C.

Компромиссное решение может состоять в том, чтобы написать начальную реализацию на одном из языков JVM более высокого уровня (на ум приходят Jython, Groovy), а затем переместить класс за классом на Java, когда реализация стабилизируется.

Я не думаю, что это обычное дело, но это сделано. Один из самых проницательных архитекторов, с которыми я когда-либо работал, использовал его моделирование на Python, а затем реализовывал этот код на C ++.

В общем, чтобы сделать это стоящим, я думаю, что вам действительно нужно выполнять сложные и высоко оптимизируемые алгоритмы, которые нелегко выразить простым языком на целевом языке. Для большинства ситуаций «реального мира / бизнеса» относительно легко выразить намерение высокого уровня на том же языке, на который мы нацелены, и реализация на указанном языке отвечает нашим требованиям к производительности, поэтому нет необходимости / желания моделировать на более высоком уровне. Уровень языка.

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

В настоящее время я работаю над проектом, который написан на C «из-за производительности» (это было первоначальной мотивацией), но, действительно, если его профилировать, он показывает, что большую часть времени он тратит на ожидание других систем (БД, другие приложения, написанные на Java, "события" на сокете).

Если вы используете неправильный алгоритм, вы также получаете плохую производительность в C (например, если вы выполняете линейный поиск по ключу, «поскольку C не имеет хеш-таблиц и мы не хотим использовать другие библиотеки», вы идете медленнее, чем если бы вы сделать это с языком, который имеет хеш-таблицы или аналогичные, как C ++, Java, C #, Python ... и т. д.)

Если вы вынуждены делать это в C по какой-либо причине, то создание прототипа на другом языке, который вы знаете, для меня не так уж плоха, только если вы создаете прототип, зная, какие «проблемы» у вас возникнут в реальной реализации C, что сложно, если вы не уверены в C. (вы скоро обнаружите, например, что у библиотек C / C std нет контейнеров, просто «простой» массив; вам нужны не-std библиотеки). Более того, C не является OO, поэтому, если вы создаете прототипы в OO, это будет сложнее.

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

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

Я программировал на Ассемблере и Си в прошлом, и, хотя это очень круто, так близко к металлу, в настоящее время их использование очень ограничено.

Есть так много вещей, которые будут препятствовать производительности, поэтому я сомневаюсь, что вы когда-нибудь достигнете той части, где сам язык является ограничивающим фактором. Это учитывая, что это C против C #.

Скажем, вы получаете повышение производительности на 10% -15% по языку. Это ничто по сравнению с увеличением порядка получения правильного алгоритма.

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

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

Мне интересно, каков твой план на самом деле создать его в C? Собираетесь ли вы создать прототип и затем изучить C, а затем перекодировать его в C? Мне это кажется немного похожим на общеизвестные «глаза больше живота», которые, я думаю, привлекают многие программисты при изучении новых технологий (я знаю, что знаю). Я имею в виду, что вы пытаетесь спроектировать что-то, что явно чувствительно к производительности, даже не зная тонкостей языка, на котором, по вашему мнению, это в конечном итоге необходимо написать, в основном вы хотите начать разработку приложения на C до того, как Знайте C, когда лучше потратить время, сначала изучая C, а затем вы сможете лучше понять, как написать желаемое приложение. Возможно, я ошибся в вопросе, и вы намереваетесь передать его другому программисту для сборки программы на C,

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

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

Оценивая некоторые возможности:

1 . Вы создаете прототип на python и пишете программное обеспечение на C.

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

Какой бы код вы ни написали на python, он не будет использоваться в конечном программном обеспечении. Но это может помочь, если вы передаете свой прототип кому-то, кто умеет читать на Python и писать на C. Здесь, прототипирование может помочь донести идею .

Этот метод подходит для проверки логической выполнимости решения.

2 . Вы создаете прототип на C и пишете программное обеспечение на C.

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

Этот метод подходит для тестирования как логической, так и технологической осуществимости решения.

3 . Вы можете рассмотреть некодирующие способы прототипирования в зависимости от имеющейся проблемы.

Если это какой-то кусок логики и идей, которые вы хотите прототипировать; псевдокод , блок-схемы и блок-схемы на бумаге тоже хороши.

Если это прототип пользовательского интерфейса, рассмотрите какой-нибудь инструмент макета пользовательского интерфейса или еще раз, статью.

Я думаю, что вы должны создать прототип на языке, с которым вы знакомы (Pytho / Ruby / C # что не так), чтобы:

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

Позже вы можете использовать инструмент профилирования, чтобы найти области горлышка бутылки. Реализовать в C / C ++. Повторите шаг выше несколько раз, кто знает, что ваш прототип может быть «достаточно быстрым»!

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

Один проект, в котором я принимал участие, использовал такой подход: разработка математической библиотеки для архитектур Cell / BE и Power7. Функции были смоделированы в Haskell (с использованием CoCoNUT), а выходные функции были в оптимизированной сборке для конкретной целевой архитектуры.

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

Пища, хотя, я надеюсь, что вы не голодаете :)

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

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

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

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

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

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

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

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

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

Я думаю, что известность Си вполне заслужена, потому что великолепный продукт Unix был написан на Си. Однако, по сравнению с людьми, которые знают Си лучше, я довольно скептически отношусь к тому, почему его следует использовать. Говорят, что Кен Томпсон (после написания первой версии Unix на ассемблере) начал писать Unix на Фортране, но сдался через неделю или месяц и начал использовать C, который разрабатывался его коллегой Кеном Ритчи в в то же время.

Недавно я был поражен, прочитав, что Fortran работает быстрее, чем C и C ++.

Ричард Маллинс