Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Joker6413, Вы писали:
J>>Был у меня знакомый дельфист. Он принципиально не разбирался с механизмами, а дергал компонентны из сети и крайне наивным образом использовал многопоточность и т.д. Его системы глючили всегда и он всегда ругал win последними словами.
VD>И что характерно, хотя я знаю ВыньАПИ довольно хорошо, но готов ругать его не меньше твоего Дельфиста.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, jazzer, Вы писали:
J>>Многопоточность с сопутствующими ей проблемами синхронизации никуда не денется, каким бы языком, фреймворком и осью ты ни пользовался. J>>Если ты не собираешься писать исключительно однопоточные программы, конечно.
VD>Очень даже денется. Следующие 7 лет как раз эта проблема будет очень активно решаться.
Она решается вот уже последнии лет 30 — 40, а воз и ныне там — самое революционное изобретение, которое произошло на этом поприще, это введение Эдсгаром Дейкстрой считающего семафора в 1968 году! Так что думаю и в ближайшие 7 лет ничего кардинального не придумают. Как синхронизировали семафорами, так и будем синхронизировать... Как рисовали фишечки на диаграммах многопоточности, так и будем рисовать... И .NET тут ничем не поможет...
Для автора поста (не знаю как вас по имени):
в вашем нынешнем возрасте, лучше не забивать себе голову ни WinAPI, ни .NET`ом — это ещё успеется, а может наоборот не успеется (к тому моменту, как вы закончите обучение — это всё может уже умереть), а, как правильно сказали, выучить математику, алгоритмизацию и банальную архитектуру ЭВМ. Покопайтесь в ассемблере — потом вы этого уже сделать не сможете (времени не будет), а приготиться знания низкого уровня могут очень сильно для дальнейшего понимания работы высоких технологий и архитектур.
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
Mr. None wrote:
> Она решается вот уже последнии лет 30 — 40, а воз и ныне там — самое > революционное изобретение, которое произошло на этом поприще, это > введение Эдсгаром Дейкстрой считающего семафора в 1968 году!
Я бы рекомендовал посмотреть на функциональные языки с понятием
параллельной композиции, например.
DK>Лохи, пишущие на native-компилируемых компиляторах будут локти себе кусать, видя как легко ты используешь .NET в достижении своих проблем, тогда как им приходится делать в два раза больше действий на их устранение!
J>Многопоточность с сопутствующими ей проблемами синхронизации никуда не денется, каким бы языком, фреймворком и осью ты ни пользовался. J>Если ты не собираешься писать исключительно однопоточные программы, конечно.
мне почему-то кажется, что с появлением CELL в конце концов будут выпускать компиляторы, автоматически шинкующие код на потоки,
и подход к многопоточности СИЛЬНО изменится (проблема, не пропав, перейдёт в другую плоскость)
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Joker6413, Вы писали:
J>>Был у меня знакомый дельфист. Он принципиально не разбирался с механизмами, а дергал компонентны из сети и крайне наивным образом использовал многопоточность и т.д. Его системы глючили всегда и он всегда ругал win последними словами.
VD>И что характерно, хотя я знаю ВыньАПИ довольно хорошо, но готов ругать его не меньше твоего Дельфиста.
Не сказать чтобы я был WinApi гуру, но при разработке ругал пока только себя за нерадивость.
Здравствуйте, Mr. None, Вы писали:
MN>Она решается вот уже последнии лет 30 — 40, а воз и ныне там
Она решается очень вяло, так как массовому рынку это не нужно. Для не массового рынка решеения давно есть.
MN> — самое революционное изобретение, которое произошло на этом поприще, это введение Эдсгаром Дейкстрой считающего семафора в 1968 году!
Да, нет. Это ты остановился на 68-ом году. А наука давно ушла вперед.
MN> Так что думаю и в ближайшие 7 лет ничего кардинального не придумают.
Ну, что же. Подождем. Время рассудит.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, OnThink, Вы писали:
OT>мне почему-то кажется, что с появлением CELL в конце концов будут выпускать компиляторы, автоматически шинкующие код на потоки, OT>и подход к многопоточности СИЛЬНО изменится (проблема, не пропав, перейдёт в другую плоскость)
В Цел, как я понял, нет кучи полноценных ядер. Там есть как бы сопроцессоры эффективно решающие узкий класс задач. Типа следующий шаг SIMD. Так что тут скорее будут уместнее библиотеки заточенные под процессор.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Joker6413, Вы писали:
J>Не сказать чтобы я был WinApi гуру, но при разработке ругал пока только себя за нерадивость.
Ничго. Со временем это иногда проходит.
Ради хохмы попробуй засечь время которое тебе потребуется, чтобы написать программку последовательно переключающую режим сглаживания шрифтов в Windows XP.
условия такие... Запоминашь текущий режим, перебираешь перключашь режим склаживания, выводишь месседжбокс (чтобы увидить результат). В конце востанавливашь исходный режим. Под режимами я понимаю: "Выключено", "Стандратный", ClearType.
Засеки время, а потом покажешь нам это время и опишешь свои эмоции. А потом я опишу как я вижу это АПИ и сколько времени уйдет у меня на тот же пример.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>В Цел, как я понял, нет кучи полноценных ядер. Там есть как бы сопроцессоры эффективно решающие узкий класс задач. Типа следующий шаг SIMD. Так что тут скорее будут уместнее библиотеки заточенные под процессор.
в цел в нынешнем виде — восем обработчиков ячеек алгоритмов/данных и один разруливатель/дробилка на базе PowerPC. Узких классов задач нет. Есть узкая применимость на данный момент, но это скорее всего детская болезнь.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Joker6413, Вы писали:
J>>Не сказать чтобы я был WinApi гуру, но при разработке ругал пока только себя за нерадивость.
VD>Ничго. Со временем это иногда проходит.
VD>Ради хохмы попробуй засечь время которое тебе потребуется, чтобы написать программку последовательно переключающую режим сглаживания шрифтов в Windows XP.
VD>условия такие... Запоминашь текущий режим, перебираешь перключашь режим склаживания, выводишь месседжбокс (чтобы увидить результат). В конце востанавливашь исходный режим. Под режимами я понимаю: "Выключено", "Стандратный", ClearType.
VD>Засеки время, а потом покажешь нам это время и опишешь свои эмоции. А потом я опишу как я вижу это АПИ и сколько времени уйдет у меня на тот же пример.
Я тебе уже написал эту прогу (мессага пока висит в ожидании отправки в янусе, посему ссылку дать прям ща не могу). Заняло по прикидкам: ~3 сек — запуск сюхи. ~5-10 сек — запуск MSDN, ~30-60 сек поиск в нем где же в нужной функции описания нужных констант. 60-90 сек набор проги. компиляцию — не засекал. мат в сторону отсутствия в комплекте .h моей старенькой 6-й сюхи пары требуемых констант. ~n — выковыривание нужного .h с 7-й сюхи с рабочего компа + прописание их define-ами в прогу. компиляция. ~3 сек — первая поптыка исправления бага MS (передача константы вместо адреса на нее — задокументированный баг (фича) в части WinAPI функций. кто то в микрософт сильно любит такой метод передачи параметров), компиляция — готово.
сам прикинь сколько получилось.
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Я тебе уже написал эту прогу (мессага пока висит в ожидании отправки в янусе, посему ссылку дать прям ща не могу). Заняло по прикидкам: ~3 сек — запуск сюхи. ~5-10 сек — запуск MSDN, ~30-60 сек поиск в нем где же в нужной функции описания нужных констант. 60-90 сек набор проги. компиляцию — не засекал. мат в сторону отсутствия в комплекте .h моей старенькой 6-й сюхи пары требуемых констант. ~n — выковыривание нужного .h с 7-й сюхи с рабочего компа + прописание их define-ами в прогу. компиляция. ~3 сек — первая поптыка исправления бага MS (передача константы вместо адреса на нее — задокументированный баг (фича) в части WinAPI функций. кто то в микрософт сильно любит такой метод передачи параметров), компиляция — готово. CC>сам прикинь сколько получилось.
Ну, у тебя получается чуть быстрее чем открыть студию. Надо было не прикидывать, а просто засечь.
Я вот убил добрый час пока разобрался во всем этим барахлом.
Так вот теперь можешь сравнить этот трах с использованием человеческого АПИ
Мне нужно знать только имя класса, нажать "." и вписать "F". Далее комплит подскажет мне имя свойства. Далее когда я напишу "=" мне будет выдан список вариантов. В итоге вместо:
Здравствуйте, VladD2, Вы писали:
VD> Ну, у тебя получается чуть быстрее чем открыть студию. Надо было не прикидывать, а просто засечь.
когда писал не думал о том, что ты засечь попросишь... я наткнулся на твою мессагу "попробуйте написать"... про время там не было.
VD> Я вот убил добрый час пока разобрался во всем этим барахлом.
виноват кто? тот кто против задокументированного в описании API написал хак...
VD> Так вот теперь можешь сравнить этот трах с использованием человеческого АПИ
мне всегда не нравились такие API (вернее обертки) тем, что они скрывают происходящие на самом деле процессы. Если бы это был родной API системы — тогда да, другое дело.
А с WinFX проблема не в том что API переделан, проблема в том, что использование этого API ограничивается искусственно только managed вызовами.
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>мне всегда не нравились такие API (вернее обертки) тем, что они скрывают происходящие на самом деле процессы.
А что тут скрывается? АПИ (я уже о моем варианте) декларирует, что позволяет узнать или переключить сглаживание. Оно честно выполняет свое предназначение.
Ты просто привык к кривым оберткам к кривым АПИ. Собственно будь АПИ примям и обертки бы не понадобились бы. Ну, или были бы совсем простенькими.
CC>Если бы это был родной API системы — тогда да, другое дело.
Дык я и говорю, что ВыньАПИ прив, и что чтобы не быть кривым ему нужно выглядеть приблизительно "так".
CC>А с WinFX проблема не в том что API переделан, проблема в том, что использование этого API ограничивается искусственно только managed вызовами.
Вот мне и странно, что почему-то АДО.НЕТ дергать из неуправляемого кода желения нет, а Индигу — есть.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Mr. None, Вы писали:
MN>>Она решается вот уже последнии лет 30 — 40, а воз и ныне там
VD>Она решается очень вяло, так как массовому рынку это не нужно. Для не массового рынка решеения давно есть.
Где-то я это уже слышал....
"Java и C++ так популярны потому что за ними стоят крупные корпорации. За Обероном их нет!" — цититрование вольное, но я думаю вы поняли о чём я .
MN>> — самое революционное изобретение, которое произошло на этом поприще, это введение Эдсгаром Дейкстрой считающего семафора в 1968 году!
VD>Да, нет. Это ты остановился на 68-ом году. А наука давно ушла вперед.
Всё может быть. Приведите, пожалуйста, примеры удачных решений хотя бы некоторых проблем в сфере многопоточной разработки. Это не наезд, не проверка знаний, я просто хочу узнать — может и вправду есть что-нибудь революционное, что я упустил (только не упоминайте активных объектов — они уже оскомину набили, а толку с них весьма мало).
MN>> Так что думаю и в ближайшие 7 лет ничего кардинального не придумают.
VD>Ну, что же. Подождем. Время рассудит.
Ок, через 7 лет я вас найду и напомню вам ваши слова .
Компьютер сделает всё, что вы ему скажете, но это может сильно отличаться от того, что вы имели в виду.
OnThink wrote:
> мне почему-то кажется, что с появлением CELL в конце концов будут > выпускать компиляторы, автоматически шинкующие код на потоки, и подход > к многопоточности СИЛЬНО изменится (проблема, не пропав, перейдёт в > другую плоскость)
В VS 2005 уже есть такая поддержка в виде OpenMP для С++. Другое
дело, что в императивных языках компилятор сам не может определить
семантику многих используемых переменных и ее приходится явно прояснять
(в OpenMP с помощью #pragma). Так что, я думаю, мы вскоре увидим большее
распространение функционального стиля.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Joker6413, Вы писали:
J>>Не сказать чтобы я был WinApi гуру, но при разработке ругал пока только себя за нерадивость.
VD>Ничго. Со временем это иногда проходит.
VD>Ради хохмы попробуй засечь время которое тебе потребуется, чтобы написать программку последовательно переключающую режим сглаживания шрифтов в Windows XP.
Offtop
Вопрос был вот в чем:
А>Нужно ли знать такие вещи как мьютексы, именованные каналы, почтовые ящики,
А>многопоточность, управление процессами, объекты ядра Windows и т. п.,
Т.е. нужно ли понимать как работают обьекты системы. Шрифты тут вовсе не при чем. То что Api сложный — это не оспариватся, посмотри в сторону реализации маршалинга.
Здравствуйте, Mr. None, Вы писали:
MN>Всё может быть. Приведите, пожалуйста, примеры удачных решений хотя бы некоторых проблем в сфере многопоточной разработки.
1. Использование неизменяемых объектоы.
2. Комуникация между объектами с помощью неизменяемых сообщений.
3. Повышение декраративности в программировании.
MN> Это не наезд, не проверка знаний, я просто хочу узнать — может и вправду есть что-нибудь революционное, что я упустил (только не упоминайте активных объектов — они уже оскомину набили, а толку с них весьма мало).
Революции нужны там где долгое время небыло эволюции. С многопоточностью все проще. Эвалюция была, но ее результаты были не востребованы. Сейчас они востребованы и в ближайшие годы прийдут в массы.
MN>Ок, через 7 лет я вас найду и напомню вам ваши слова .
Не забудь.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Надо было не прикидывать, а просто засечь.
.
.
