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

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

P>>>так о чём речь? включение только <fstream> в один файл, увеличивает объём работы компилятора для одного файла на ~30k строк кода.
B>>>>Понятно что это неполноценое сравнивания но результат говорит сам себя разница в скорости не на проценты а в разы
P>>>ну так объём кода, который обрабатывает компилятор C++ больше не в разы, а на порядок или даже несколько порядков.

B>>Какой <fstream> вы сёрсы этих libav*** видели?

P>нет, не видел

B>>никаких std:: , <fstream> <map> 'ов и бустов
B>>единственые стандартные либы:
B>>#include <math.h>
B>>#include <stdio.h>
B>>#include <stdlib.h>

P>Вот только эти три h'а, добавляют ~3300 строк кода в файл. А ещё нужно учитывать что наверняка помимо стандартных инклюдов, наверняка в каждом файле инклюдится h'ы из самого проекта, которые в свою очередь подключают другие h'ы проекта.
P>грубо говоря, умножьте 900*3300.

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

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



B>>Так вот этот код (1500 файлов ИМЕННО КОДА)Дельфи генерирует (строит таблицы, оптимизирует и ещё хрен его знает что делает) быстрее в 3 раза чем генерация 960 файлов ИМЕННО КОДА VC++

P>без прекомпилированных заголовков, сравнение не корректно. так как в твоём случае, объём работы у C++ больше на пару лямов строк

Вот-вот, пример бессмысленной работы и, кстати, туча требуемых dll в примитивных программах.

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

F>>Но народ интересуется и сервис пользуется популярностью у шареварщиков, поэтому зарегил домен www.submit4torrents.com.

YK>А почему 4 а не 2?

Потому что "Софт должен быть бесплатным"

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

P>>>>так о чём речь? включение только <fstream> в один файл, увеличивает объём работы компилятора для одного файла на ~30k строк кода.
B>>>>>Понятно что это неполноценое сравнивания но результат говорит сам себя разница в скорости не на проценты а в разы
P>>>>ну так объём кода, который обрабатывает компилятор C++ больше не в разы, а на порядок или даже несколько порядков.
B>>>Какой <fstream> вы сёрсы этих libav*** видели?
P>>нет, не видел
B>>>никаких std:: , <fstream> <map> 'ов и бустов
B>>>единственые стандартные либы:
B>>>#include <math.h>
B>>>#include <stdio.h>
B>>>#include <stdlib.h>
P>>Вот только эти три h'а, добавляют ~3300 строк кода в файл. А ещё нужно учитывать что наверняка помимо стандартных инклюдов, наверняка в каждом файле инклюдится h'ы из самого проекта, которые в свою очередь подключают другие h'ы проекта.
P>>грубо говоря, умножьте 900*3300.
_>С чего это? Если у компилятора кривая изначально архитектура, то это нужно ставить ему в минус, а не в оправдание медленной работы.

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

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


P>а зачем тогда прекомпилированные заголовки по твоему?
P>"#include" это не "uses". В pascal'е include это по-моему {$L file.pas}


B>>Так вот этот код (1500 файлов ИМЕННО КОДА)Дельфи генерирует (строит таблицы, оптимизирует и ещё хрен его знает что делает) быстрее в 3 раза чем генерация 960 файлов ИМЕННО КОДА VC++

P>без прекомпилированных заголовков, сравнение не корректно. так как в твоём случае, объём работы у C++ больше на пару лямов строк

Повторюсь, я не использую "прекомпилированные заголовки" потому что в моём случае они наоборот, лишь увеличивают время компиляции (они пересоздаются при каждой компиляции). Их применение имеет смысл (ИМХО) при использовании таких "неизменяемых" либ как MFC и как раз таки QT, что бы не компилировать при каждом билде весь MFC или QT. У меня типичный опенсёрс проект БЕЗ постороних либ вообще, только рантайм library, только линкуемая (она не компилируется!) в конечный ехе. Потому при билде компилируются все файлы солюшена (960 файлов) И ТОЛЬКО ОНИ, больше ничего. Объем работы студии в моём случае — препроцес нескольких стандартных файлов заголовков (только проверка на коректность синтаксиса) и компиляция солюшена. Всё.
Тоже и в Дельфи. Но в на 50% больше объема проверки синтаксиса и в на 50% больше строк кода для компиляции. За время в три раза меньшее. Вроде объяснил по пальцам. В студии даже <windows.h> не подключается, он подключается лишь в файле кода .exe Дельфи же приходится парсировать весь vcl + sys + rtl.

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

P>>а зачем тогда прекомпилированные заголовки по твоему?
P>>"#include" это не "uses". В pascal'е include это по-моему {$L file.pas}
B>>>Так вот этот код (1500 файлов ИМЕННО КОДА)Дельфи генерирует (строит таблицы, оптимизирует и ещё хрен его знает что делает) быстрее в 3 раза чем генерация 960 файлов ИМЕННО КОДА VC++
P>>без прекомпилированных заголовков, сравнение не корректно. так как в твоём случае, объём работы у C++ больше на пару лямов строк

B>Повторюсь, я не использую "прекомпилированные заголовки" потому что в моём случае они наоборот, лишь увеличивают время компиляции (они пересоздаются при каждой компиляции).
А почему они у вас пересоздаются?

B>У меня типичный опенсёрс проект БЕЗ постороних либ вообще, только рантайм library, только линкуемая (она не компилируется!) в конечный ехе. Потому при билде компилируются все файлы солюшена (960 файлов) И ТОЛЬКО ОНИ, больше ничего. Объем работы студии в моём случае — препроцес нескольких стандартных файлов заголовков (только проверка на коректность синтаксиса) и компиляция солюшена. Всё.

Я же вам говорю, что эти стандартные заголовки добавляют ~3k кода в файл. Помимо стандартных, там же инклюдятся ещё и заголовки из самого проекта, которые в свою очередь включают другие заголовки, вот и получается дополнительные лямы кода на проект для компилятора.

B>Тоже и в Дельфи. Но в на 50% больше объема проверки синтаксиса и в на 50% больше строк кода для компиляции. За время в три раза меньшее. Вроде объяснил по пальцам. В студии даже <windows.h> не подключается, он подключается лишь в файле кода .exe Дельфи же приходится парсировать весь vcl + sys + rtl.
Прасить vcl+sys+rtl? он же уже распарсенный в dcu'шках (или как их там), или нет ?

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

P> H>Ты, разумеется, имеешь полное право на собственное представление о значении слова аналог

P> выдай своё видение "аналог std::map в каком-либо языке"

Я тебе уже привел TBucketList. Это аналог, нравится тебе это или нет.

P> H>Я тебе предлагал уже помедитировать над сценариями, где применимость TBucketList будет более чем оправданной. Предлагаю еще раз.

P> зачем? ту хрень которую показал ты, нельзя использовать и в 1% случаях где можно использовать std::map, ну и какой же это аналог?

Еще раз говорю — кури значение слова аналог

P> H>Ты молодец, что слово выделил, но после этих своих слов ты стал более уверен в собственной фантазии:
P> H>

Нет, я говорил о том, что тот компилятор, который в delphi скорей всего работает даже медленнее чем аналоги для c++

P> и?

Что и? Глупая фантазия, вот и все "и"

P> H>Намекаю: не может многопроходный компилятор обогнать однопроходный. Этого небыло раннее, борландовые паскаль-компиляторы всегда уделывали по скорости сишные компилеры, нет этого и сейчас.

P> Даю наводку: допустим есть язык someL, для него есть два компилятора:
P> первый многопроходный, который писался толковыми людьми. второй однопроходный, но писался расовыми индусами.

Вообще то мы говорим о вполне конкретном компиляторе, касаемо дельфей во всяком случае. А касаемо твоих теоретизирований... Если расовые индусы осилили написание однопроходного компилятора, там где толковым людям понадобилось писать многопроходный, стоит еще подумать, кто из них индус (как бы там нибыло твои теоретизирования теоретизированиями остаются и ничего не показывают)

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

B>Странно, а у меня она почему то не работает, я ставлю её в студии в Command Line/Additional Options — грузит только одно ядро, или вы собираете мейк файлом? Хотя какая разница...

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

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

P>> H>Ты, разумеется, имеешь полное право на собственное представление о значении слова аналог
P>> выдай своё видение "аналог std::map в каком-либо языке"
H>Я тебе уже привел TBucketList. Это аналог, нравится тебе это или нет.

слив засчитан

P>> H>Я тебе предлагал уже помедитировать над сценариями, где применимость TBucketList будет более чем оправданной. Предлагаю еще раз.
P>> зачем? ту хрень которую показал ты, нельзя использовать и в 1% случаях где можно использовать std::map, ну и какой же это аналог?
H>Еще раз говорю — кури значение слова аналог

и ещё раз, слив

P>> H>Ты молодец, что слово выделил, но после этих своих слов ты стал более уверен в собственной фантазии:
P>> H>

Нет, я говорил о том, что тот компилятор, который в delphi скорей всего работает даже медленнее чем аналоги для c++

P>> и?
H>Что и? Глупая фантазия, вот и все "и"

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

P>> H>Намекаю: не может многопроходный компилятор обогнать однопроходный. Этого небыло раннее, борландовые паскаль-компиляторы всегда уделывали по скорости сишные компилеры, нет этого и сейчас.
P>> Даю наводку: допустим есть язык someL, для него есть два компилятора:
P>> первый многопроходный, который писался толковыми людьми. второй однопроходный, но писался расовыми индусами.
H>Вообще то мы говорим о вполне конкретном компиляторе, касаемо дельфей во всяком случае. А касаемо твоих теоретизирований... Если расовые индусы осилили написание однопроходного компилятора, там где толковым людям понадобилось писать многопроходный, стоит еще подумать, кто из них индус (как бы там нибыло твои теоретизирования теоретизированиями остаются и ничего не показывают)

Твоё выказывание "не может многопроходный компилятор обогнать однопроходный", не верно — я тебе привёл пример, хоть и теоретический.
Твои слова о том, что компилятор delphi быстрее С++ точно такая же теоретизация и не подкреплена хорошими тестами(сравнение компиляции qt и vcl — это плохой тест), только ты почему-то себе позволяешь быть 100% уверенным в своей теоретизации.

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

P>А почему они у вас пересоздаются?

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

P>Я же вам говорю, что эти стандартные заголовки добавляют ~3k кода в файл. Помимо стандартных, там же инклюдятся ещё и заголовки из самого проекта, которые в свою очередь включают другие заголовки, вот и получается дополнительные лямы кода на проект для компилятора.

Ну не добавляют они код! То что они добавляют — это Название (Имя) функции-переменной-константы, которая будет импортироватся (компилятор на это по крайней мере, надеется) при линковке.

P>Прасить vcl+sys+rtl? он же уже распарсенный в dcu'шках (или как их там), или нет ?

Вот в Дельфи, если файл указан в "uses" компилятор ищет сначала соотв. dcu и парсит его () и если он не соответствует другим dcu'шкам по своей версии — перекомпилирует и его и всё что с ним связано. А связаны там юниты очень тесно. В общем при компиляции он проходит по всем dcu или (если нет dcu) ищет соотв. файл и компилирует его.

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

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

B>>Странно, а у меня она почему то не работает, я ставлю её в студии в Command Line/Additional Options — грузит только одно ядро, или вы собираете мейк файлом? Хотя какая разница...

YK>Нет, обычный проект, никаких makefile-ов. Эта опция может быть несовместима с другими опциями. Например я точно знаю про /Gm но компилятор, вроде, должен выдавать предупреждение по этому поводу.

Да да , было сообщение о /Gm и я не обратил на него внимания, все взоры были устремлены в "ПроцессЕксплорер" в жадных поисках новых инстансов cl.exe Буду экспериментировать дальше.

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

P>>А почему они у вас пересоздаются?
B>Потому что код у меня "активно изменяемый". После каждого изменения в коде ( и (или) в заголовках) они становятся "недействительными" и студии приходится их обновлять.

1. Я думаю вы врядли меняете более 10 файлов за заголовков перед каждой компиляцией
2. заголовки как правило используются не один раз, а многократно

P>>Я же вам говорю, что эти стандартные заголовки добавляют ~3k кода в файл. Помимо стандартных, там же инклюдятся ещё и заголовки из самого проекта, которые в свою очередь включают другие заголовки, вот и получается дополнительные лямы кода на проект для компилятора.
B>Ну не добавляют они код! То что они добавляют — это Название (Имя) функции-переменной-константы, которая будет импортироватся (компилятор на это по крайней мере, надеется) при линковке.

это называется декларация.
как вы думаете, что будет быстрее — компиляция проекта где все эти декларации предварительно разобраны (лексический, синтаксический и т.п. анализы) или компиляция проекта с довесоком в пару лямов деклараций?

P>>Прасить vcl+sys+rtl? он же уже распарсенный в dcu'шках (или как их там), или нет ?
B>Вот в Дельфи, если файл указан в "uses" компилятор ищет сначала соотв. dcu и парсит его () и если он не соответствует другим dcu'шкам по своей версии — перекомпилирует и его и всё что с ним связано. А связаны там юниты очень тесно. В общем при компиляции он проходит по всем dcu или (если нет dcu) ищет соотв. файл и компилирует его.

То есть вы хотите сказать, что vcl+sys+rtl при обычной работе(когда их код не меняется) постоянно пересобираются (всмысле соответсвующие dcu)?

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

P> слив засчитан
P> и ещё раз, слив

Я очень рад, что в школе тебя научили считать, жаль, что не научили думать.

P> H>Что и? Глупая фантазия, вот и все "и"

P> ну ты уверено утверждаешь что это глупая фантазия, ничем не подкрепляя свои слова — это как называется?

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

P> H>Вообще то мы говорим о вполне конкретном компиляторе, касаемо дельфей во всяком случае. А касаемо твоих теоретизирований... Если расовые индусы осилили написание однопроходного компилятора, там где толковым людям понадобилось писать многопроходный, стоит еще подумать, кто из них индус (как бы там нибыло твои теоретизирования теоретизированиями остаются и ничего не показывают)

P> Твоё выказывание "не может многопроходный компилятор обогнать однопроходный", не верно — я тебе привёл пример, хоть и теоретический.

Мои слова относятся к обсуждаемому компилятору, мне нет нужды теоретизировать

P> Твои слова о том, что компилятор delphi быстрее С++ точно такая же теоретизация и не подкреплена хорошими тестами(сравнение компиляции qt и vcl — это плохой тест), только ты почему-то себе позволяешь быть 100% уверенным в своей теоретизации.

Вообще, высокая скорость борландовых паскалевских компилеров это давно известный факт (быстрее были только от TopSpeed), и доказательство обратного лежит на авторе соответствующих тезисов. Дам еще один пример из жизни. У этого форума есть оффлайн клиенты, одним из которых является Avalon, ссылка на который есть у меня в теглайне. Клиент написан на C++ с использованием Qt, автор Anton Batenev. Вот посмотри

Автор: Anton Batenev
Дата: 06.04.11

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

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


P>1. Я думаю вы врядли меняете более 10 файлов за заголовков перед каждой компиляцией
P>2. заголовки как правило используются не один раз, а многократно

Достаточно изменить, даже случайно, время обращения к файлу. В моём проекте несколько *.h файлов прямо или косвено включены почти во все файлы кода, а огромный config.h состоящий из одних #define *** включен во все что движется, и в нем содержатся ключевые настройки, котороые приходится иногда менять. Так что precompiled header это не для него.

P>это называется декларация.
P>как вы думаете, что будет быстрее — компиляция проекта где все эти декларации предварительно разобраны (лексический, синтаксический и т.п. анализы) или компиляция проекта с довесоком в пару лямов деклараций?

P>То есть вы хотите сказать, что vcl+sys+rtl при обычной работе(когда их код не меняется) постоянно пересобираются (всмысле соответсвующие dcu)?

Что то вы меня запутали, изначально я речь вёл про компиляцию библиотеки "JediVCL" — состоящей из 1500 файлов кода, на которой я проверял скорость компиляции. При её сборке естесно они включают в себя через "uses" практически весь vcl+sys+rtl поэтому чтобы собрать всё это Дельфи парсирует всё что включено, затем сами эти 1500 файлов. Затем всё это (JediVCL) компилирует. За 20 секунд. И сравнивал с компиляцией единствено подходящего у меня по рамеру проекта на VC.

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

P>>То есть вы хотите сказать, что vcl+sys+rtl при обычной работе(когда их код не меняется) постоянно пересобираются (всмысле соответсвующие dcu)?

вот цепочка:
B>>>>Дельфи же приходится парсировать весь vcl + sys + rtl. (***)
P>>>Прасить vcl+sys+rtl? он же уже распарсенный в dcu'шках (или как их там), или нет ?
B>>Вот в Дельфи, если файл указан в "uses" компилятор ищет сначала соотв. dcu и парсит его () и если он не соответствует другим dcu'шкам по своей версии — перекомпилирует и его и всё что с ним связано
P>То есть вы хотите сказать, что vcl+sys+rtl при обычной работе(когда их код не меняется) постоянно пересобираются (всмысле соответсвующие dcu)?

что вы имели в виду в (***) ?

Здравствуйте, шароварная желочь, Вы писали:

ШЖ>Здравствуйте, CyberDemon, Вы писали:

CD>>Здравствуйте, YuriKobets, Вы писали:
YK>>>А почему 4 а не 2?
CD>>4 торрент трекера в базе сабмита?

ШЖ>засабмичивается с четвертого раза

Нет, потому что не 2ой эффект, а 4ной.

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

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

P>>>То есть вы хотите сказать, что vcl+sys+rtl при обычной работе(когда их код не меняется) постоянно пересобираются (всмысле соответсвующие dcu)?

P>вот цепочка:
B>>>>>Дельфи же приходится парсировать весь vcl + sys + rtl. (***)
P>>>>Прасить vcl+sys+rtl? он же уже распарсенный в dcu'шках (или как их там), или нет ?
B>>>Вот в Дельфи, если файл указан в "uses" компилятор ищет сначала соотв. dcu и парсит его () и если он не соответствует другим dcu'шкам по своей версии — перекомпилирует и его и всё что с ним связано
P>>То есть вы хотите сказать, что vcl+sys+rtl при обычной работе(когда их код не меняется) постоянно пересобираются (всмысле соответсвующие dcu)?

P>что вы имели в виду в (***) ?

Я имел в виду проверку нового компилируемого файла на соответствие его имеющимся. Нет, системные и vcl автоматически перекомпилироватся не будут, это делается через большой геморой. А если изменён один из пользовательских 1500 файлов и есть доступ к остальным 1499 исходникам от него зависящим, то они будут все вместе перекомпилированы