Lazy Cjow Rhrr wrote: > Как-то и хочется поспорить, но времени — увы. Хотя я уже большую часть > доводов высказал, можно детально по косточкам разобрать ранги, > коньюнкции, причастия (adverbs) и остальные элементы, как это
Причастия, коньюнкции, и т.д. — варианты записи функций высшего порядка. > завязывается в гармоничный клубок и посмотреть аналогичные решения на > других языках. А потом долго дискутировать, принципиальные они или > косметические... > > Резюмирую. > Уникальность и первенство в реализации сочетания идей выше вроде > сомнений не вызывает, и это хорошо.
Более того, я согласен, что многие из идей по отдельности дают иногда
преимущество в удобстве, уникальны (считая APL/J/K родственными) и,
соответственно являются первыми, при этом очень хорошо продуманы и
реализованы. > С другой стороны я готов согласиться, что в некотором виде эти идеи > витали в воздухе до APL (тем более до J/K).
При этом я это говорю только про семантические идеи.
Синтаксические идеи — действительно уникальны. > > Вот. Я предлагаю
Согласен.
Но! Это неофициальные результаты. Такая ситуация связана с тем, как администрируются бенчмарки TPC. Поскольку стандартной имплементации бенчмарков нет, то членам TPC (членство стоит ессно нехилых денег) выдаются правила, которым должны следовать при создании своей имплементации. Если вдруг кто-то побивает рекорд, то он потом долго и нудно доказывает что он не верблюд до тех пор, пока результаты не будут официально подтверждены.
Поэтому у больших контор типа IBM, Oracle и т.п. за имплементацию и защиту TPC бенчмарков отвечают целые департаменты, чего маленькая контора KX себе позволить не может.
Можно загрузить, погонять и удостовериться самомоу.
В readme к tpcd:
[we expect kdb to be 10-100 times faster and scale better than other DBMS's.]
PS>>вот я и хочу сказать что класс за 1000 строчек это пример плохого дизайна архитектуры, либо отсутствие постоянного рефакторинга кода...
IT>Либо отсутствие в языке таких средств как #region.
Это фича языка или среды разработки?
От чего, от чего, от чего тах хорошо?
Потому что кто-то любит программиста
<< RSDN@Home 1.2.0 alpha rev. 647>>
Здравствуйте, Mamut, Вы писали:
PS>>>вот я и хочу сказать что класс за 1000 строчек это пример плохого дизайна архитектуры, либо отсутствие постоянного рефакторинга кода...
IT>>Либо отсутствие в языке таких средств как #region.
M>Это фича языка или среды разработки?
Думаю и того и другого. Сегодня эти вещи уже вполне осязаемого начинают зависеть друг от друга.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Такие рузультаты идут в топку. А выводы делаемые на них выглядят не честно.
Слова же про то что люди создали минимум в 10 раз более быстрый сервер и при этом не могут найти денег на публикацию тестов выглядят не слишком серьезно. Ведь отрыв в тестах в 10 раз гарантирует невероятные прибыли в течении будквально года, а то и месяцев. Любой банк даест денег столько сколько нужно.
У Оракла тоже как-то раз результат был в 10 или даже в 100 (сейчас не помню) раз быстрее остальных. Потом выяснилось, что они смашейничали. Использовали кэширование результатов вметсо вычисления. С тех пор TPC изменили и теперь TPC-C больше такое машейничество не позволяет.
Если их слова не откровенная лож, то скорее всего какой нибудь машейничество.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Lazy Cjow Rhrr wrote: > Можно загрузить, погонять и удостовериться самомоу. > В readme к tpcd: > [we expect kdb to be 10-100 times faster and scale better than other > DBMS's.]
Нереально. В разы — еще возможно, но не на порядки.
Насколько я понимаю, у них там заточка на in-memory DB, то есть большая
часть нужных для запросов данных держится резидентно в памяти. Особенно
учитывая, что столбцы таблиц они хранят по-отдельности. Это может в
некоторых ситуациях дать ооооочень неплохой прирост производительности,
но в общем случае все равно будет быстрее какой-нибудь Oracle.
Здравствуйте, Pyro Sun, Вы писали:
PS>Кто как считает? Какой размер класса в строках оптимален для понимания того что там происходит?
PS>Из своих наблюдений пришел к выводу что класс должен быть меньше 1000 строчек. PS>Да и 1000 это пожалуй великовато.
Ну, это не всегда верно. Например, при разработке контролов под .NET. Взять хотя бы события. Допустим, у нас есть 5-6 событий. К ним нужно добавить события вида PropertyChanged, причём ещё и свойств 8-9. Т.е получается около 15 событий. Для каждого из них нужно создать статический объект, написать add/remove код, OnEvent, комментарии к событиям и к On'ам. Получается, что до 500 строчек кода уходит только на события. Причём код весьма тривиальный и однообразный, его можно делать из сниппетов, а можно генерировать. Хорошо что в .NET есть #region, а начиная со второй версии — partial классы.
Думаю вопрос надо ставить не так. Скорее, на читабельность кода влияет количество строк в файле, не считая типовой код. С тем, что не следует делать файлы из более чем 1000 строк согласен. А вообще, производительность работы зависит не только от количества строк в файле, но и от количества публичных неунаследованных методов/свойств в классе, от количества классов в пространстве имён (пакете), от количества файлов в папке и т.д.
Нужно носить в себе еще хаос, чтобы быть в состоянии родить танцующую звезду.
Здравствуйте, Lazy Cjow Rhrr, Вы писали: LCR>Но! Это неофициальные результаты. Такая ситуация связана с тем, как администрируются бенчмарки TPC. Поскольку стандартной имплементации бенчмарков нет, то членам TPC (членство стоит ессно нехилых денег) выдаются правила, которым должны следовать при создании своей имплементации. LCR> Если вдруг кто-то побивает рекорд, то он потом долго и нудно доказывает что он не верблюд до тех пор, пока результаты не будут официально подтверждены.
Трендеж беззастенчивый.
1. Спецификации TPC доступны всем и совершенно бесплатно.
2. Если есть сомнения или проблемы с пониманием, то можно взять full disclosure report по любому из тестов, проведенных Большими Пацанами, и посмотреть, как они интерпретировали спецификации.
3. Никто ничего нудно не доказывает. Результаты публикуются сразу после тестирования, но имеют соответствующий статус, пока их не рассмотрят педанты из комитета. Вот, к примеру, результат IBM уже полтора года In Review, и ничего. LCR>Поэтому у больших контор типа IBM, Oracle и т.п. за имплементацию и защиту TPC бенчмарков отвечают целые департаменты, чего маленькая контора KX себе позволить не может.
Конечно целые департаменты. Достаточно посмотреть в цены top50 решений TPC, чтобы понять, что миллион TPC-C ни одна мелкая контора не потянет. Потому как для этого нужно только оборудования баксов эдак на миллион. С другой стороны, есть low-end тесты, в которых стоимость решения ~ $30000 с учетом софта и цен на серверное железо. Аналог приведенного результата можно собрать в современной России, ограничившись ~ $3000.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Конечно целые департаменты. Достаточно посмотреть в цены top50 решений TPC, чтобы понять, что миллион TPC-C ни одна мелкая контора не потянет. Потому как для этого нужно только оборудования баксов эдак на миллион. С другой стороны, есть low-end тесты, в которых стоимость решения ~ $30000 с учетом софта и цен на серверное железо. Аналог приведенного результата можно собрать в современной России, ограничившись ~ $3000.
Не, не, Синклер, ты не прав! Если наша КулСубд действительно в 100 раз круче топового паравоза, то ей не составит труда побить всех на железе продающеся в соседнем магазине офисных товаров. 100 раз это ну очень много .
А то что это трындеж беззастенчивый я склонен с тобой согласиться.
ЗЫ
А вообще очень интересно послушать логическое обоснование того как же можно на одном железе быть в 100 раз быстрее конкурентов при этом не мухлюя. Никак применяются торсионные поля.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Sinclair,
LCR>>Но! Это неофициальные результаты. Такая ситуация связана с тем, как администрируются бенчмарки TPC. Поскольку стандартной имплементации бенчмарков нет, то членам TPC (членство стоит ессно нехилых денег) выдаются правила, которым должны следовать при создании своей имплементации. LCR>> Если вдруг кто-то побивает рекорд, то он потом долго и нудно доказывает что он не верблюд до тех пор, пока результаты не будут официально подтверждены.
S>1. Спецификации TPC доступны всем и совершенно бесплатно.
+1. Моя ошибка, неверный источник.
S>2. Если есть сомнения или проблемы с пониманием, то можно взять full disclosure report по любому из тестов, проведенных Большими Пацанами, и посмотреть, как они интерпретировали спецификации. S>3. Никто ничего нудно не доказывает. Результаты публикуются сразу после тестирования, но имеют соответствующий статус, пока их не рассмотрят педанты из комитета. Вот, к примеру, результат IBM уже полтора года In Review, и ничего.
Вот именно, что ничего. Эти 2 "типа опровержения" и означают, что ты должен "долго и нудно доказывать что ты не верблюд", если представишь соответствующее решение. Здесь я прав.
В мэйл-листе kxsystems в последнее время стали часто всплывать апелляции к TPC, так что возможно результаты появятся в будущем.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>В мэйл-листе kxsystems в последнее время стали часто всплывать апелляции к TPC, так что возможно результаты появятся в будущем.
Сомневаюсь. Принципы, проложенные в основу дизайна kdb, несколько отличаются от традиционных.
Вот выдержки из обсуждения пятилетней давности.
I'm curious how KDB would stack up against these numbers and whether Kx has any plans to post TPC scores.
IBM's new world record is 2733 queries per hour (QphH), with a system cost of $347/QphH.
— Microsoft's old world record was 1699 QphH at $161/QphH.
— Microsoft achieved its score by using eight PIII 700MHz Intel processors on a single server; IBM used 16 PIII 700MHz processors spread across a four-node cluster.
-----
kdb would do about 14000 QphH with 16 p3 700MHZ
>and whether Kx has any plans to post TPC scores.
it would be fun but tpc-h says vertical partitioning is not allowed.
-----
(Why not send it in with a question about why arbitrary rules should be allowed to hinder progress...?)
-----
They freely acknowledge this problem, and "address" it by stating categorically that any changes would result a different benchmark (not "tpc-h").
[The implicit assumption is that vertical partitioning requires a lot of work and that they're not really excluding any meaningful database implementations with this rule. But implicit assumptions are hard to address in explicit conversation.]
An important part of TPC is how fast you can back out of incomplete failed transactions.
KDB is designed to eliminate all work on failed transactions -- that's one of the reasons it's fast.
So far, no one has exhibited much interest in building a superstructure around KDB to benchmark doing pointless work then undoing it.
Until that's done, KDB would not be suitable for TPC.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>>>Но! Это неофициальные результаты. Такая ситуация связана с тем, как администрируются бенчмарки TPC. Поскольку стандартной имплементации бенчмарков нет, то членам TPC (членство стоит ессно нехилых денег) выдаются правила, которым должны следовать при создании своей имплементации. LCR>>> Если вдруг кто-то побивает рекорд, то он потом долго и нудно доказывает что он не верблюд до тех пор, пока результаты не будут официально подтверждены.
S>>1. Спецификации TPC доступны всем и совершенно бесплатно. LCR>+1. Моя ошибка, неверный источник.
Кстати, никакой ошибки нет. Спецификации доступны всем, но стандартной реализации ("имплементации") нет. Каждый реализует в меру своей интерпретации спецификаций а потом сдает это дело на аудит.
Трурль,
LCR>>В мэйл-листе kxsystems в последнее время стали часто всплывать апелляции к TPC, так что возможно результаты появятся в будущем.
Т>Сомневаюсь. Принципы, проложенные в основу дизайна kdb, несколько отличаются от традиционных. Т>Вот выдержки из обсуждения пятилетней давности. Т>
tecnical discussion about KDB guts
Т>Как видно — сплошной мухлеж.
Всё понятно, спасибо. Короче итог:
1. TPC — это прежде всего "пеар", который неизвестно окупится или нет. Наличие официальных тестов позволяет привлечь лишь внимание потенциальных клиентов (тем, кто давно и плотно подсел на M$, Oracle etc. это пустой звук). Но этого "пеара" не будет по причине номер два.
2. Архитектурные различия таковы, что представить эффективную реализацию бенчмарков TPC, устраивающую остальные стороны невозможно.
Следовательно, единственно 100% работающий способ привлечь новых клиентов — это конкретно и обстоятельно, в тесном контакте с клиентами, продемонстрировать альтернативный более быстрый способ решения задач клиента. Чем как я полагаю ребята из KX и занимаются.
Здравствуйте, VladD2, Вы писали:
VD>Слова же про то что люди создали минимум в 10 раз более быстрый сервер и при этом не могут найти денег на публикацию тестов выглядят не слишком серьезно. Ведь отрыв в тестах в 10 раз гарантирует невероятные прибыли в течении будквально года, а то и месяцев. Любой банк даест денег столько сколько нужно.
Скорость никого не интересует. Будь они в 1000 раз быстрее Ms-Sql, всё равно они его не переплюнут. Вкладываться нужно не в скорость, а в рекламу.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
Если нам не помогут, то мы тоже никого не пощадим.
1.1.4 stable rev. 510
.
