Чьи программсты "башковитее"

Главная Форумы Шашечные программы Шашечные программы Чьи программсты "башковитее"

Просмотр 15 сообщений - с 121 по 135 (из 159 всего)
  • Автор
    Сообщения
  • #391618
    Jury
    Участник

    2NS: Восьмерка сырая еще, да и слишком дорого, нет смысла в переходе. Есть и еще минусы, но эти основные. А для 7.7 терминал замечательная среда. В SQL для семерки особого смысла нет, память не так уж и поедается. У программистов конечно же двухядерники.
    Кстати, вопрос распараллеливания вычислений очень даже интересует меня в плане разницы в производительности 3D игр между 2х и 4хядерными процессорами. И еще вопрос. Насколько сложно создать генератор ЭБ с возможностью использования многоядерности, а особенно с возможностью распределенной генерации?

    2ВЕТЕР1515: Забавные у вас представления о бизнесе. Деньги вообще должны работать, а брать двухядерники для того, чтобы на нем крутился офис и терминальная сессия — это простой денег, их лучше на зарплату тратить, больше толку будет. Ну а трата 50ти рублей на системник — это скорее бахвальство, нежели аргумент в споре.

    #391619
    NS
    Участник

    2NS: Восьмерка сырая еще, да и слишком дорого, нет смысла в переходе. Есть и еще минусы, но эти основные. А для 7.7 терминал замечательная среда. В SQL для семерки особого смысла нет, память не так уж и поедается. У программистов конечно же двухядерники.
    Кстати, вопрос распараллеливания вычислений очень даже интересует меня в плане разницы в производительности 3D игр между 2х и 4хядерными процессорами. И еще вопрос. Насколько сложно создать генератор ЭБ с возможностью использования многоядерности, а особенно с возможностью распределенной генерации?

    По порядку:
    1. Функционал Восьмерки (УПП), и возможности встроенного языка просто не сравнимы с семеркой. CRM, Бюджетирование, многопередельное производство, ведение бухгалтерского учета по нескольким фирмам в одной базе (БП), отличнейший механизм для регистрации изменений (УРБД), все кто имеет достаточно денег и достаточно возможностей давно уже перешли на восьмерку, несмотря на её неотлаженность и сырость конфигураций.

    2. Семерка без SQL живет только в «небольших организациях» из-за ограничений файловых баз (переиндексация в случае аварийного завершения, ограничение на размер файлов, сложность восстановления файловых баз в случае аварии). Большая база на ДБФ просто не живет.

    И даже выгрузка более-менее большой семерочной ДБФ базы невозможна — ограничение на размер .DAT файла. А на SQL можно делать Бекап средствами SQL.
    Правда никто не мешает ставить терминал + SQL (Два сервака соединенных гигабитным каналом)

    3. 3D Играми я не занимаюсь, но могу предположить что большой выигрыш возможен, так как для всех алгоритмов AI существуют эфективные параллельные алгоритмы (например поиск пути).
    Всё упирается в трудозатраты написания (распараллеливания всех алгоритмов АI и расчета Физики) под произвольное число процессов.

    4. Многопотоковый генератор ЭБ достаточно прост. Простейшее описание было на сайте Чинука. Параллелится отлично, еще лучше чем Альфа-Бета. (как и остальные задачи ретроспективного анализа/динамического программирования) То есть на четырех ядрах можно ожидать выигрыша в быстродействии практически в четыре раза. Правда если не упираемся в скорость жеских дисков (объемы оперативной памяти).

    #391620
    plus600
    Участник

    Например в Dam 2.2 такого нет…
    Максимальная «бесконечность» там 120 минут.
    И аналитическая функция считается как-то «дико».
    Возможно к ней надо привыкнуть?
    Но я так и не смог добиться от Dam 2.2 того, чтобы она загрузила 3-х шашечную базу окончаний, и показывала Win, Loss, Draw.



    Не было такой функции в Plus 600.
    (Потому в свое время я выбрал не её, а «Тундру». К тому же в пакете они предлагали и программу в поддавки (которая в стратегических планах практически беспомощна, хотя комбинации видит).)

    Я говорю — НЕ БЫЛО.
    Возможно уже есть.

    Было всегда, может быть не в таком явном виде. Для проф версии максимально возможное время составляет 9999 минут.

    #391621
    Fenix
    Участник

    Было всегда, может быть не в таком явном виде. Для проф версии максимально возможное время составляет 9999 минут.

    Но почему 9999 минут?
    Почему вообще — МИНУТ?

    В «Тундре» — «Контроле времени» — «Установка вручную» — «Не ограничено», и далее СОВЕРШЕННО понятная и удобная аналитичка.

    Почему не задать глубину ПОЛУХОДАМИ?
    😳 В «Тундре», например анализ просто останавливается на 63-х полуходах… 😳 В принципе, это продолжительность партии в русских шашках.

    #391622
    plus600
    Участник

    А какая разница? В обоих случаях смысл тот же самый — время явно превышает «ограниченное». Я, например, в таком случае просто ставлю 6000 минут и еще не разу не попадал под ограничение времени :)

    #391623
    DDDNOEDDNE
    Участник

    Я не собираюсь спорить. Кому не нравится двухъядерник, может смело отправляться в каменный век.

    Антон, как ни странно, но иногда и сис-админ говорит верные вещи.
    Действительно, для многих программ (бухгалтерских на 100%) особо мощной машины не требуется, все равно ресурсы не используются и это будет только лишняя трата денег.
    Другое дело это программы графики: 3D Studio, Corel, Photoshop, AutoCad и д.р. Вот для них уже требуются гораздо более мощные машины, хотя и на старых они будут работать.
    А вот современные игрушки, не потянут старые машины, но прежде всего из-за видеокарты.

    #391624
    Fenix
    Участник

    А какая разница? В обоих случаях смысл тот же самый — время явно превышает «ограниченное». Я, например, в таком случае просто ставлю 6000 минут и еще не разу не попадал под ограничение времени :)

    Разница?…
    Конечно же кружку чая можно донести до рта и правой рукой и левой…
    Только правша и левша будут иметь СВОЕ МНЕНИЕ! 😉

    #391625
    plus600
    Участник

    Аналогия спорная. Какая разница какой пункт меню выбирать «6000 минут» или «без ограничения»? Разница только в названии. Разве не так? Смысл режимов ведь совпадает.

    #391626
    DDDNOEDDNE
    Участник

    Конечно же кружку чая можно донести до рта и правой рукой и левой…

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

    #391627
    Jury
    Участник

    По порядку:
    1. Функционал Восьмерки (УПП), и возможности встроенного языка просто не сравнимы с семеркой. CRM, Бюджетирование, многопередельное производство, ведение бухгалтерского учета по нескольким фирмам в одной базе (БП), отличнейший механизм для регистрации изменений (УРБД), все кто имеет достаточно денег и достаточно возможностей давно уже перешли на восьмерку, несмотря на её неотлаженность и сырость конфигураций.

    2. Семерка без SQL живет только в «небольших организациях» из-за ограничений файловых баз (переиндексация в случае аварийного завершения, ограничение на размер файлов, сложность восстановления файловых баз в случае аварии). Большая база на ДБФ просто не живет. И даже выгрузка более-менее большой семерочной ДБФ базы невозможна — ограничение на размер .DAT файла. А на SQL можно делать Бекап средствами SQL.
    Правда никто не мешает ставить терминал + SQL (Два сервака соединенных гигабитным каналом)

    Из того, что Вы написали кое-что есть и на семерке. Но тут наверное я был несколько не точен, я не описал начальные условия просто. Для организации в сотню рабочих мест семерка без SQL тянет отлично. Что касается выгрузки, то мне не обязательно пользоваться штатными средствами. К слову сказать сырость у восьмерки не только в конфигурациях, пока еще есть и в ядре. Но это уже отдельная тема…

    #391628
    Fenix
    Участник

    Аналогия спорная. Какая разница какой пункт меню выбирать «6000 минут» или «без ограничения»? Разница только в названии. Разве не так? Смысл режимов ведь совпадает.

    Возможно дело было в чем-то другом?
    Помнится я просто не мог вывести «Plus600» на режим АНАЛИТИЧКИ. Программа всё время порывалась сделать ход, или рисовала какой-то (мне совершенно не нужный) график, или просто не реагировала на предложение остановить анализ… А уж вернуть обратно ход в позиции — никогда. Только через новую расстановку!

    Впрочем, я и разбираться особо не стал… :?
    У меня была ПОСЛУШНАЯ «Тундра».
    ==========================
    Сейчас, ориентируясь на наш разговор, я заставил «ДОЛГО ДУМАТЬ» Dam 2.2! Но пока не могу добиться того, чтобы в одном из окон высвечивались ВСЕ ХОДЫ с АНАЛИТИЧЕСКОЙ функцией… Пока завис только — лучший вариант, просчитываемый в данный момент.
    Или это зависит от УРОВНЯ ИГРЫ? A, B, C, D… Знатоки: а?

    #391629
    NS
    Участник

    Из того, что Вы написали кое-что есть и на семерке. Но тут наверное я был несколько не точен, я не описал начальные условия просто. Для организации в сотню рабочих мест семерка без SQL тянет отлично. Что касается выгрузки, то мне не обязательно пользоваться штатными средствами. К слову сказать сырость у восьмерки не только в конфигурациях, пока еще есть и в ядре. Но это уже отдельная тема…

    На семерке всё это есть… В отдельных конфигурациях!
    Например Рарус CRM — отдельная конфигурация, никакого производства в нем нет (и бюджетирования тоже). Если сравнивать функционал семерочного и восьмерочного CRM-а (того-же Раруса) — то сравнивать нечего. Семерочный по сравнению с восьмерочным это просто детская игрушка.

    На сотню рабочих мест ДБФ база? :)
    Тянет отлично до того момента как умрет. После этого наконец пригласят спеца, который переведет базу на SQL :)

    Вы в курсе, что ограничение ДБф базы — 2Гига на файл, при этом она умирает значительно раньше?
    Можете рассказать хотя-бы один способ перевода большой ДБФ базы на SQL? Представте ситуацию — база умирает, вы берете последнюю живую базу и пытаетесь перевести её под SQL, но не можете, выгрузка не работает, ограничение на размер .DAT файла :)
    Потом, база выросла, переиндексация занимает час, Сдвиг точки актуальности (пересчет итогов) Занимает сутки, обрезать базу не возможно и т.д.
    Плюс к этому — в хороших руках SQL значительно быстрее работает.
    О надежности я уже не говорю — SQL на порядки надежнее ДБФ-а.

    #391630
    Jury
    Участник

    Торговля самописная, до описанных ужасов еще далеко, да и можно обрезать базу, не проблема. Об ограничениях в курсе. Насчет более быстрой работы SQL спорить не буду, но слышал всякое. В основном то, что SQL к 1С притянута за уши, то есть данные так же гоняются по сети, механизмы запросов, хранимых процедур и прочее не используется. Что касается перевода большой базы, то главное конфигу перекинуть, данные я могу и своими обработками поперекидывать, способов достаточно. Давайте наверное по части 1С остановимся, слишком оффтоп, не только для темы, но для сайта в целом.

    #391631
    NS
    Участник

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

    Хранимые процедуры используются. Механизмы запросов есно используются :)
    В чистом виде — то на то и выходит по скорости примерно одинаково (что-то быстрее на SQL, что-то на ДБФ), но!
    Хранимые процедуры давно переписаны, есть куча компонент расширяющих функционал. Например:
    http://kb.mista.ru/article.php?id=361
    Под SQL всё это намного проще, и существует в значительно более шщироком ассортименте.
    И нармально написанная база под SQL (с использованием прямых запросов, например при помощи 1c++ либо ToySQL) работает на порядки быстрее чем ДБФ, это не говоря уже о значительно большей надежности, отсутствии переиндексаций при аварийном завершении работы, возможности использования встроенных средств Сиквела для проверки целостности базы (сколько времени занимает тестирование и исправление ДБФ базы? :) ), и для её исправления. Средства SQL для ведения транзакций и возможных откатов, и средства SQL для исправления полетевших баз.

    База ДБФ рано или поздно умрет (вырубился файловый сервак например, никаких контролей в случае аварийного прерывания записи в ДБФ у 1С нет) И это выльется в огромные убытки для фирмы (если база действительно на 100 пользователей и она действительно важна).
    База SQL надежней на порядки, и если всё-таки даже и случится неприятность, то восстановить её можно намного быстрее и дешевле.

    http://www.forum.mista.ru/topic.php?id=18698
    http://www.forum.mista.ru/topic.php?id=26757
    И тут двух мнений быть не может. Не найдется такого признанного спеца, который бы всерьез утверждал что на 100 пользователей имеет смысл оставлять ДБФ базу. Только SQL. Иначе просто подстава для фирмы.

    #391632
    DDDNOEDDNE
    Участник

    Господа, вернитесь в тему. Вы ушли в глубокий оффтоп. Теме «Чиь программисты башковитее», а вовсе не в достоинствах и недостатках SQL сервера.
    Вопрос же темы очень интересный. Я раньше считал, что русские программисты умнее западных. А потом понял, что нет. Интерсно то (об этом я уже писал), что на школьном уровне русские превосходят американцев, а вот дальше идет отставание.
    Почему так? Может дело в том, что высшее образование стало платным и многим недоступным, в него ринулась масса бездарей, которые и снизили общую подготовку спецов. Косвенно это доказывается тем, что при СССР советские матемитики по крайней мере не уступали американским.

Просмотр 15 сообщений - с 121 по 135 (из 159 всего)
  • Для ответа в этой теме необходимо авторизоваться.