CASTRO пишет: Поверьте, машинного времени при работе неоптимизированного под конкретную машину софта тратится зачастую куда больше.
А зачем перекомпиливать библиотеки многократно?
Почему узких специалистов? Дистрибутив Gentoo, например, весьма распространён.
Я не знаю, зачем Вы мне дали указание перекомпилировать библиотеки Root. Значит, Вы их компилируете каждый раз при компиляции своей программы. Это глупо и очень не эффективно.
Понятия не имею, что такое Gentoo, он у нас не используется, у нас собственная разработка.
Внимание! Данное сообщение содержит исключительно личное мнение автора. Есть основания полагать, что оно может не отвечать критериям научности.
Поверьте, машинного времени при работе неоптимизированного под конкретную машину софта тратится зачастую куда больше.
А зачем перекомпиливать библиотеки многократно?
Почему узких специалистов? Дистрибутив Gentoo, например, весьма распространён.
Я не знаю, зачем Вы мне дали указание перекомпилировать библиотеки Root. Значит, Вы их компилируете каждый раз при компиляции своей программы. Это глупо и очень не эффективно.
Понятия не имею, что такое Gentoo, он у нас не используется, у нас собственная разработка.
Не перекомпилировать, а скомпилировать из исходников. Разницу улавливаете? Один раз. Вы снова встаёте в позицию человека, который мало что знает/понял, но который радостно раздаёт свою оценку.
Olginoz пишет: Пляски с бубном бывают, когда пытаешься dll-ку написанную на одном языке и собраннуюв одной системе, морально устаревшей и имеющей ошибки в компиляторе,использовать на другом языке во вполне приличной системе.
А не хотите плясок с бубном в вашей любимой Visual Studio? Вы, Ольга, просто не знаете вообще, о чем говорите. Пусть одна совершенно качественная и полностью отлаженная сторонняя библиотека собрана под VC++ 2015, а ваш полностью отлаженный проект в VC++ 2017. Каждая из частей по отдельности будет работать великолепно и безо всяких багов. Но если вы их соедините вместе - с большой вероятностью (зависящей от рук архитектора) вы приплыли, потому что у вас теперь по меньшей 2 (ДВЕ) библиотеки CRT, каждая из которых ожидает, что она единственная в адресном пространстве исполняемого процесса.
Цитата
У Вас совершенно несправедливое поверхностное суждение
Нет, просто ваши ответы - на уровне Junior C/C++ developer'а. Собеседование в имеющуюся у меня в подчинении группу математиков-программистов вы бы не прошли.
Цитата
В современной системе с управляемым кодом - один.
Вы не ответили на вопрос, а ушли от него. Да, managed среды были придуманы как раз для того, чтобы насильно править кривые руки. Но в вашей же любимой Visual Studio в unmanaged C++ коде может быть сколь угодно много разных CRT, даже если используется одна и та же версия студии.
Цитата
Вы представляете себе, сколько бы тратилось машинного времени и людских ресурсов при многократном перекомпилировании не маленьких библиотек в виндах?
Вы просто не представляете себе, о чем вообще пытаетесь рассуждать. В данном случае вы в корне неправы, и серьезные проекты (включая компоненты самой операционной системы) точно так же в Windows перекомпилируются целиком, как и в Linux. Причина одна и та же - необходимость иметь единственную CRT на весь исполняемый код. В противном случае возникает ситуация, которая называется "пересечение объектом границ CRT" (crossing CRT boundary).
Вот тут вкратце обзор данной проблемы:
Так что полная пересборка кода - это отнюдь не прихоть опенсурсной среды Linux. Это прежде всего способ избежать указанной выше проблемы для сохранения целостности системы.
Если для вас это все слишком много букв, вот вкратце описание примера, влекущего за собой проблему:
Цитата
// Get hindcast data from our special library, observationData // variable will keep the newly allocated memory buffer // on success and null otherwise. float *observationData = MyObservationLib::getHindcastData();
// Check if we've got some data and perform accordingly if (0 != observationData) { // Do whatever you need and then clean up our buffer to release // the memory previously allocated by getHindcastData function ... free(observationData); // <-- Crash happens right here }
Если CRT одна, то код работает безо всяких проблем, поскольку здесь нет никакой ошибки (кроме проблемы дизайна). Если CRT разные, то могут случаться краши, поскольку выделение памяти происходит в одной CRT, а освобождение в другой, которая ни сном ни духом про выделенный блок памяти.
Внимание! Есть полагание основать, что личное мнение содержит исключительно сообщение автора. Оно может не отвечать, что соответствует научности по критериям данности.
На физическом объекте может работать и много девайсов-компьютеров разных систем, связанных в сеть и синергично решающих задачу достижения какой-то цели(если такая, конечно, есть).
BETEP IIEPEMEH пишет: Собеседование в имеющуюся у меня в подчинении группу математиков-программистов вы бы не прошли.
Я не просилась в Вашу группу математиков-программистов, я просила приемлемую для меня работу-задачу на дому, по физике. Вот, сижу в одной комнате с Наташами, для них я слишком умная, для Вас я слишком глупая. И куда мне податься?
Внимание! Данное сообщение содержит исключительно личное мнение автора. Есть основания полагать, что оно может не отвечать критериям научности.
Пляски с бубном бывают, когда пытаешься dll-ку написанную на одном языке и собраннуюв одной системе, морально устаревшей и имеющей ошибки в компиляторе,использовать на другом языке во вполне приличной системе.
А не хотите плясок с бубном в вашей любимой Visual Studio? Вы, Ольга, просто не знаете вообще, о чем говорите. Пусть одна совершенно качественная и полностью отлаженная сторонняя библиотека собрана под VC++ 2015, а ваш полностью отлаженный проект в VC++ 2017. Каждая из частей по отдельности будет работать великолепно и безо всяких багов. Но если вы их соедините вместе - с большой вероятностью (зависящей от рук архитектора) вы приплыли, потому что у вас теперь по меньшей 2 (ДВЕ) библиотеки CRT, каждая из которых ожидает, что она единственная в адресном пространстве исполняемого процесса.
Цитата
У Вас совершенно несправедливое поверхностное суждение
Нет, просто ваши ответы - на уровне Junior C/C++ developer'а. Собеседование в имеющуюся у меня в подчинении группу математиков-программистов вы бы не прошли.
Цитата
В современной системе с управляемым кодом - один.
Вы не ответили на вопрос, а ушли от него. Да, managed среды были придуманы как раз для того, чтобы насильно править кривые руки. Но в вашей же любимой Visual Studio в un managed C++ коде может быть сколь угодно много разных CRT, даже если используется одна и та же версия студии.
Цитата
Вы представляете себе, сколько бы тратилось машинного времени и людских ресурсов при многократном перекомпилировании не маленьких библиотек в виндах?
Вы просто не представляете себе, о чем вообще пытаетесь рассуждать. В данном случае вы в корне неправы, и серьезные проекты (включая компоненты самой операционной системы) точно так же в Windows перекомпилируются целиком, как и в Linux. Причина одна и та же - необходимость иметь единственную CRT на весь исполняемый код. В противном случае возникает ситуация, которая называется "пересечение объектом границ CRT" (crossing CRT boundary).
Вот тут вкратце обзор данной проблемы:
Так что полная пересборка кода - это отнюдь не прихоть опенсурсной среды Linux. Это прежде всего способ избежать указанной выше проблемы для сохранения целостности системы.
Если для вас это все слишком много букв, вот вкратце описание примера, влекущего за собой проблему:
Цитата
// Get hindcast data from our special library, observationData
// variable will keep the newly allocated memory buffer
// Check if we've got some data and perform accordingly
if (0 != observationData)
{
// Do whatever you need and then clean up our buffer to release
// the memory previously allocated by getHindcastData function
...
free(observationData); // <-- Crash happens right here
}
Если CRT одна, то код работает безо всяких проблем, поскольку здесь нет никакой ошибки (кроме проблемы дизайна). Если CRT разные, то могут случаться краши, поскольку выделение памяти происходит в одной CRT, а освобождение в другой, которая ни сном ни духом про выделенный блок памяти.
Я не дочитала ссылку, ночь и спать хочется, но идея понятна. Я не собираю ПО из разных версий студио, во-первых в этом нет необходимости, во-вторых я избегаю смешивать разные версии систем и разные системы программирования вообще. Программы, созданные в разных системах, лучше запускать отдельными дочерними процессами. Неуправляемый код это код, созданный в старых версиях студио. Для неуправляемого кода COM объектов применяются другие методы освобожнения памяти.
* * * Первобытный строй - никого невозможно заставить быть рабом. Рабовладельческий строй - рабы есть, но их надо кормить, поить и заставлять работать. Крепостное право - рабы кормят-поят себя сами, но все-таки их надо заставлять работать. Дикий капитализм - рабы сами приходят в рабство, сами себя кормят и поят, и сами себя заставляют работать. "Свободный мир" - рабы сами приходят в рабство, сами себя кормят и поят, и сами себя заставляют работать. Более того, они считают себя свободными и им это нравится.
Кризис современной философии проистекает из неудовлетворенности ею самою собой, т.е. из невозможности соответствовать установленным ею для себя критериям, которым, однако, более удовлетворяет современная реальная наука.
Петр Тайгер пишет: "Свободный мир" - рабы сами приходят в рабство, сами себя кормят и поят, и сами себя заставляют работать. Более того, они считают себя свободными и им это нравится.
В том числе такие свободные рабы могут заставлять себя разгадывать загадочные намёки (какого-то хитроумнонго и стеснительного правителя), а могут и не заставлять, поступая так, как поступают неправильные рабы, которые в том числе могут показывать языки(в выразительных формах лопат, колбас, трубочек и в д.р. формах) и кукиши(выразительно конфигурируемые в ореолах разных статических и динамических поз, принимаемых неправильными рабами на выразительных фонах).
В отличие от кроманьонских социумов, у социальных насекомых информация о стратегических планах кодируется в генах(им так нравится - такая пенсия).
Вам несколько раз уже разные люди говорили - идите на площадки фрилансеров (к примеру fl точка ru или freelance точка ru). При том, что вам всего то нужна прибавка к пенсии (т.е. можете выставлять очень низкую стоимость часа), вы составите серьезнейшую конкуренцию студентам.
Цитата
Неуправляемый код это код, созданный в старых версиях студио.
Да щаз. Unmanaged код можно запросто создавать хоть в Visual Studio 2017. Более того, в managed коде можно запросто делать вставки unmanaged кода да хоть на ассемблере, или делать вызовы к функциям unmanaged библиотек. Это просто две стороны одной медали. Странно только, что это я вам про это рассказываю.
Цитата
Я не собираю ПО из разных версий студио, во-первых в этом нет необходимости, во-вторых я избегаю смешивать разные версии систем
Потому что работаете в одиночку. А проекты, которые вы пытались собрать по указанию CASTRO - продукт коллективного труда. И в таких вещах вызов ./configure - обычно первое, что делают перед сборкой проекта. Причем не только в Linux - тот же кроссплатформенный Qt под Windows собирается через точно такое же конфигурирование. Но это на самом деле мелочи. Самое важное, что происходит при конфигурирование под Linux - поиск зависимых библиотек (dependencies) и проверка настроек окружения. Поскольку используются найтивные средства платформ (т.е. unmanaged средства), то важна и битность системы, и порядок байтов (endianness), и доступность тех или иных возможностей процессора. В итоге один и тот же правильно написанный код можно собирать под разные железяки. У нас, к примеру, час кода модели работает на обычных многоядерных Xeon'ах, а часть "выгружается" на ускорители Xeon Phi, реализующие архитектуру Intel MIC. На них вроде бы "тот же Linux", да не тот же, и хотя в основе каждого ядра ускорителя лежит архитектура x86, без специальной перекомпиляции кода под данную конкретную архитектуру ничего работать не будет.
Внимание! Есть полагание основать, что личное мнение содержит исключительно сообщение автора. Оно может не отвечать, что соответствует научности по критериям данности.
Портал журнала «Наука и жизнь» использует файлы cookie и рекомендательные технологии.
Продолжая пользоваться порталом, вы соглашаетесь с хранением и использованием
порталом и партнёрскими сайтами файлов cookie и рекомендательных технологий на вашем устройстве.
Подробнее
