Страницы: Пред. 1 2 3 4 5 6 7 След.
RSS
Возможности разработки взаимодействия с БД (выбор инструментов), Javascript ИЛИ VBScript
 
Цитата
JeyCi написал:
прилагаю файл со скриптом JS - правильно ли написан??
Это форум по Excel и VBA, откуда здесь кто может знать, правильно или нет написан скрипт на JS?
Не уж то нет форумов, где обсуждается JS?
 
Цитата
Karataev написал: по Excel и VBA,
был вопрос и по vbscript...  если вы не хотите читать сначала - то и не постите...
да ещё и тема в курилке (как положено)...
- поэтому ваш троллинг не имеет оснований... пройдите мимо - поберегите нервы... за Excel и VBA идите в Основную ветку
Изменено: JeyCi - 15.06.2019 19:36:40
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
большеват оказался VS... кстати нашла норм. альтернативу - SharpDevelop - есть даже какие-то тесты и Profiler...
---
вот только вопрос по Профайлеру нарисовался - скрин прилагаю - т.е. когда мы видим такое - значит есть повод задуматься "чего же приложение так тормозит" (хоть количество милисекунд и не критично) - но всё-таки есть повод задуматься, как ускорить работу приложения??... правильно ли я понимаю смысл профилировщика? или он показывает ещё какую-то более важную информацию?

p.s/
т.е. на скрине я пометила логически вытекающие вопросы из увиденного (правильно ли смотрела?) - повод подумать, как с увиденным бороться? [т.е. переписать-оптимизировать код]... вопрос про unsafe - смутил !unsafe...
p.p.s.
это, думаю последний вопрос, чтобы начать разрабатывать логично/корректно... а так - win_form уже получилась :) - осталось синтаксис нарабатывать опытом... thanks a lot всем... буду передавать sql-комманды в управлюющий код (благо на с-подобном уже пробовала это дело - из void в void ходить)
p.p.p.s
кстати поняла: Консоль тут не при чём (в кодировании на c#) -- мы ведь при создании проекта можем выбрать Консольное приложение ИЛИ Win_Form ИЛИ любое другое... а увидеть какую-либо переменную в SharpDevelop и на C# можно и в Locals и в Messagebox.Show... (и не надо тянуть в консоль  :oops: )
Изменено: JeyCi - 18.06.2019 15:38:27
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
JeyCi написал: по Профайлеру
хотя да - в Visual Studio Profiler пошире -
Первое знакомство со средствами профилирования
Профилирование приложений в Visual Studio 2010
Профилировщик выделения памяти Visual Studio
Изменено: JeyCi - 18.06.2019 17:49:56
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
стоит отметить, что в создании корректного проекта и его сборки на C/C++ важную роль играют не только компоновщик и линкер, линкеры... однако и такой нюанс - 20 ловушек переноса Си++ - кода на 64-битную платформу придётся учитывать...
===
а для C# стоит помнить особенности Работы с потоками в C# (CSThreading)...
также - хотя IO потоки в принципе дело небыстрое и неблагодарное при записи файлов, что также, как и любую отрисовку форм, можно приписать к  выражению "Хороший интерфейс - это невидимый интерфейс"... всегда лучше всё делать в память... насколько её хватает...
но т.к. даже в .NET можно применить unsafe mode ( Небезопасный код в C#), то в таких случаях память придётся контролировать самостоятельно...
===
p.s.
и после всего написанного кода в Visual Studio подробности:
Компоновка, компиляция и построение проекта
Производительность компиляторов С++
Изменено: JeyCi - 24.06.2019 13:03:57
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
JeyCi написал:что-то крутится в памяти, что ADO.NET при каждом следующем вызове в приложении выполняет +1 запрос (в придачу к предыдущим) -- т.е. странность какая-то есть у него: выполняет все предыдущие и последний заданный, и выводит результаты последнего (в консоль например)
нашлось - уточню - вот и странность - причина: Ленивые вычисления функционального языка - по сути LINQ
Цитата
Суть явления под названием «ленивые вычисления» заключается в том, что вычисления откладываются до тех пор, пока не понадобится их результат.
поэтому выполняет эти вычисления каждый раз, как они понадобятся... снова и снова (от начала  исходных данных и до конца, куда надо) - не беря в переменную...  :(
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
JeyCi написал:
Производительность компиляторов С++
ссылка на Шарп, а не на Плюсы)
Изменено: bedvit - 22.06.2019 21:13:58
«Бритва Оккама» или «Принцип Калашникова»?
 
Цитата
bedvit написал: на Плюсы)
ух как у них с линками и переходами по ним... вобщем поправила  8) ... а вообще, там можно отразить оглавление слева вверху "Показать меню" (что я и сделала), но при переходе с него по линкам на др статьи - адрес web не меняется (меняется только если выкинуть линк на новую вкладку)...
p.s.
а вообще там достаточно интересные статьи...
p.p.s
кстати где-то на хабре встретила статью, что у Visual Studio 2017 есть какоё-то bug, приводящий к overflow при или после компиляции C++...
Вобщем 2019 будет понадёжнее для unsafe code, полагаю...
Изменено: JeyCi - 23.06.2019 12:09:36
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
JeyCi написал:
кстати где-то на хабре встретила статью, что у Visual Studio 2017 есть какоё-то bug, приводящий к overflow при или после компиляции C++...
не слышал про такое, найдите ссылку почитаю. А вот реальные отличия студии 2019 от 2017.
Цитата
JeyCi написал:
Вобщем 2019 будет понадёжнее для unsafe code,
в С#.NET eсть unsafe, в С++ весь код небезопасный, там нет такого понятия. Стреляй в ногу сколько угодно.
Изменено: bedvit - 24.06.2019 00:10:56
«Бритва Оккама» или «Принцип Калашникова»?
 
Цитата
bedvit написал: найдите ссылку почитаю.
благо под рукой в истории bug в Visual Studio 2017
вот, возможно, по вашему линку речь об этом:
Цитата
•Exception safety correctness problems wherein the node-based containers like list, map, and unordered_map would become corrupted were fixed. During a propagate_on_container_copy_assignment or propagate_on_container_move_assignment reassignment operation, we would free the container’s sentinel node with the old allocator, do the POCCA/POCMA assignment over the old allocator, and then try to acquire the sentinel node from the new allocator. If this allocation failed, the container is corrupted and can’t even be destroyed, as owning a sentinel node is a hard data structure invariant. This was fixed to allocate the new sentinel node from the source container’s allocator before destroying the existing sentinel node.
P.S.
Цитата
bedvit написал: С++ весь код небезопасный
:) уже поняла... добавила линк на пример в #65
Изменено: JeyCi - 24.06.2019 13:42:14
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
и всё-таки век живи - век учись...
Функциональное программирование для всех --
"легкость добавления потоков, не утруждая себя думами о стандартных проблемах, которые неизбежно сопровождают многопоточные приложения!"...
хоть и "недостатки ленивых вычислений"...
====
LINQ как шаг к функциональному программированию --
"функциональное программирование vs. императивное программирование - чтобы не бегать циклами со всеми вытекающими удобствами"...
и о проблемах делегатов в самом LINQ,
также особенности использования списков...
====
значит ВОТ и споcоб ускорения не в ущерб читаемости: -- где надо - перейти от ООП к ФП... что и можно реализовать в C#...
(хоть сам Excel и многопоточен, полагаю, поскольку в его настройках есть свойство "использовать все ядра" [наверно, знает, для чего использует]... но код написанный на vba лишь прямолинеен)
p/p/s
хотя LINQ можно использовать и в составе C++, и VB, и C# (вроде встречалось такое)
Изменено: JeyCi - 29.06.2019 10:19:30
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
JeyCi написал:
значит ВОТ и споcоб ускорения не в ущерб читаемости: -- где надо - перейти от ООП к ФП...
Вот ФП на VBA. Ссылка раз, ссылка два.
Попробуйте перейти. О результатах напишите.
Цитата
JeyCi написал:
(хоть сам Excel и многопоточен, полагаю, поскольку в его настройках есть свойство "использовать все ядра" [наверно, знает, для чего использует]... но код написанный на vba лишь прямолинеен)
Потому как язык С/С++ поддерживает многопоточность (в том числе функции в .xll), а VBA - нет.
«Бритва Оккама» или «Принцип Калашникова»?
 
перейти-то - перешла, а о результатах ещё, наверно, рано... - надо как-то идеи пробовать вставлять в свой  проект - тогда и результаты будут... а вообще - интересно (оттуда по линку) - Функциональные интерфейсы… в VBA ... хотя тоже стоит с умом выбирать - C#. Абстрактные классы или интерфейсы ...
p.s.
вообще, попробую поискать С++ или  С# для создания Хранимых процедур в Access (типа такого, по логике) -- читала где-то о возможности такого манёвра... хотя SQL-яз сам по себе тоже функциональный, полагаю... но многопоточность на нём не организовать... (если вдруг понадобится - только на 2х серверах объединённых если)...
ну и, как всегда, ускорение загрузки и парсинга json-файлов интересует для вставки потом в бд... конечно, если будут результаты - отпишусь... (но думаю, не скоро - т.к. по сути это будут уже не переделки к имеющемуся, а совсем новая история)
p.p.s
спасибо за линки !!
Изменено: JeyCi - 29.06.2019 20:12:15
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
JeyCi написал:  Функциональные интерфейсы… в VBA
хотя да... например при использовании 1,33000 параметрОВ в sub Test_7 получаем Overflow (на 32000 ещё ок - и даже быстро)... [2 ядра 2,8 ггц, ram 2 gb] 32x ОС...
действительно, наверно, потому что многопоточность в VBA не организовать - а то, может [на JS], и выкрутиться удалось бы... ?.. !хотя всё равно ресурсов не хватило бы... :(
(да и писан тот код для скриптовых языков с использованием ScriptControl Ref в Tools[vbe], хоть и реализация объектной модели [?COM], насколько поняла?)
Изменено: JeyCi - 30.06.2019 12:58:38
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
JeyCi написал: и парсинга json-файлов
- JSON.NET... ?
:D  A CLR-resident JSON serializer/deserializer for SQL Server
Цитата
But I Hate The CLR! Yes, I do, and here's why... CLR memory exists outside your SQL Server's normal memory pool
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
JeyCi написал: получаем Overflow
bedvit, всё-таки один нюанс остаётся под покровом моей неинформированности (без вас не могу предположить как гуглить)...
? - как рациональнее распорядиться кучей и стэком в памяти (особенно стэком!) - чтобы на 2гб ram творить чудеса на С++... - чтобы суметь всё! (пусть даже за счёт мЕньшей скорости успевать всё укладывать в память, но не превышать её) - как-то порционно обрабатывать входящие данные?.. или многопоточность спасёт даже для скорости при ограниченной памяти?
p.s.
понятно, что нужно какие-то деструкторы писать... но как расчитать момент их включения (например при порционной обработке) ?.. или для ограниченных ресурсов есть какие-то другие более эффективные алгоритмы для С++?.. (чтобы не попасть в overflow)
p.p.s
хочется, конечно, также, как на сервере,  - читать память, а не хранить в памяти… но, наверно, не дано...
ну и например, если брать поштучно json-файлы [для цели порционно], то ведь процедурная природа С++ не даст ни цикл создать, ни модульность для передачи в функцию … а писать для каждого json свой обработчик – тоже не вариант… надо сразу брать всё…
можно даже, оформив это всё в один массив json-синтаксисом… но тогда [даже если памяти на это хватит] потом разбирать строку [которая по сути в с++ есть массив символов] – есть ли лимит у длины такого массива?.. и опять же вопрос память тут и нарисуется (overflow)… если данных уж больно много…
наверно, всё-таки нет более адекватного варианта – кроме как использовать CLR для зацикливания и С++ как dll … или через unsafe mode организовывать парсинг в рамках CLR  цикла – наладив взаимодействие между ними…
думаю, на голом С++ - не всё так радостно, как скорость может порадовать…
Изменено: JeyCi - 30.06.2019 07:37:11
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
[и не в мощи железа всё дело!]
Overflow
Цитата
I - обычно это значит что есть проблемы с рекурсией, в большинстве случаев когда задаётся этот вопрос - нету условия выхода из рекурсии. –
II - Еще появляется, когда вы объявляете слишком большой локальный массив (внутри функции). Обычно размер стека ограничен несколькими мегабайтами
и ответ:
Цитата
Как избавиться? Опять же, можно просто в настройках компилятора поднять размер стека.
Но надежнее и лучше - посмотреть, нет ли слишком глубокой (вплоть до бесконечности) рекурсии, заменить локальные массивы на выделяемые динамически.
int f()
{
   int a[1000000];
практически гарантированно даст переполнение стека. В отличие от
int f()
{
   int * a = new int[1000000]; // Только не забудьте потом удалить...
или
   vector<int> a(1000000);
Словом, смотрите, кто съедает много стековой памяти, и избавляйтесь от него...
или др вариант - не самый лучшмй (т.к. iostream тоже не быстрая идея):
Цитата
- На диск его записывай, этот массив, на диск...
- Точно мне все время еще говорит о нехватке виртуальной памяти! Значит на диск . А скока надо места?
- Ровно 3000*3000*sizeof(твой_тип_данных) байт. ))
p.s.
Там еще объявлять массивы в файле с раширением h надо для ускорения . а я так прям в .срр писал их . Короче заработало без Stack overflow.
в принципе есть идеи - c++ избежать overflow... и для рекурсии:
Цитата
От стековерфлоу теоретически есть много вариантов избавиться:
1) переписать в хвостовую рекурсию (если язык поддерживает оптимизацию ТСО)
2) оптимизировать алгоритм, оставляя его рекурсивным, но с меньшим заполнением стека
3) разнести вычисления по потокам со своими стеками, переписать эвалюатор на итеративный, выбрать другой язык и т.п.
(4) ну и как всегда выбор правильного типа для данных... и правильное обращение с ним - например, как и с float...
p.s.
:qstn: значит 3-й вариант - это всё-таки тоже вариант??... не понятен залог успеха этого варианта - как и за счёт чего?
p.p.s
Как избежать переполнения
Как избежать переполнения целого числа
Как избежать переполнения стека рекурсивной функции
вобщем, по-байтово считать память !!!.....  :idea: ... полагаю, стэк всё равно ? не задать на весь ram, как хочется (почти весь за исключением уже использованного ос)
Изменено: JeyCi - 30.06.2019 08:03:23
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
C++ какой нужен размер стека - речь о стеке вызовов... или при нескольких потоках - их образуется несколько... не путать со структурой данных "стеком" как контейнером...
Цитата
JeyCi написал: полагаю, стэк всё равно ? не задать на весь ram, как хочется
Максимальный размер стека для программы C/C +?
поэтому и приходится мониторить глубину дерева при, например, рекурсивном обходе...
[как и в PQ, полагаю, когда говорят что там нет циклов, есть только рекурсия.. т.к. ФЯ]
===
Цитата
JeyCi написал: с использованием ScriptControl Ref в Tools[vbe]
в #73 - наверно, всё равно не добиться потоков...
хотя для web - выход избегать overflow: Переполнение стека вызовов JavaScript, SetTimeout и снижение производительности AJAX  - может, ScriptControl хотя бы такое осилит в работе c JavaScript?
===
Увеличение размера стека (Си, Си++)
To set this linker option in the Visual Studio development environment
Изменено: JeyCi - 30.06.2019 10:28:16
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
а вообще, понравилось  :D
Цитата
-- Мне нужно запустить не 4 и не 10 потоков а более 2000 - каким образом это осуществить
-- а зачем? можно полюбопытствовать? если такой зверинец глюкнет, то будут большие проблемы.... ОЧЕНЬ большие проблемы....
Изменено: JeyCi - 30.06.2019 10:28:40
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Вот когда вы сами познакомились с функциональным программированием, вы наверное поняли, что не везде его можно использовать и профита нет. А отказ от циклов, в пользу рекурсии (плюс отказ от динамических переменных, в силу модели вычислений без состояний) жрет стек. Итого не вижу целесообразности в использовании ФП, кроме особо специфичных задач.
По стеку - переходите на кучу. Это нормальная практика в С++ для больших структур (массивы, строки, и т.д.). Стек хоть и быстрее, он многим меньше кучи и используется под хранение параметров функции, локальные переменных и другой информации, связанная с функциями.
Разделить выполнение кода в С++ потокам вообще не проблема. Только нужно понимать, что алгоритм должен поддерживать распараллеливание (не любой алгоритм можно эффективно расспаралелить) и количество потоков, обычно не должно превышать количества логических ядер на вашем ЦП. Для чего вам 2000 потоков, у вас 2000 ядерный ЦП? Ну и будут потоки стоять в очередь на логическое ядро, как в последовательном процессе, плюс затраты на выделение потока.
Изменено: bedvit - 30.06.2019 12:16:32
«Бритва Оккама» или «Принцип Калашникова»?
 
Цитата
bedvit написал: Ну и будут потоки стоять в очередь на логическое ядро, как в последовательном процессе, плюс затраты на выделение потока.
вот хорошо сказано !!!
дополню (как знаю) : главный поток - всё равно всегда один и он контролирует начала и завершения остальных потоков... и всё равно не завершится пока не завершаться все доп. потоки... спасибо, что дополнили, что они в очереди на ядро ЦП ... и что
Цитата
bedvit написал: количество потоков, обычно не должно превышать количества логических ядер на вашем ЦП.
всё интересное, что остаётся в HDD - это rpm-характеристика... 7200 конечно быстрее чем 5400... но и поломки при некачественной сборке более вероятны (т.к. скорость вращения шпинделя больше)
===
теперь к слову о разрядности ОС (к чему в принципе привязан и допустимый RAM)...
зачем мне больше 32x, если таких цифр у меня в принципе не будет в ценах... надо только прикинуть размер массива символов строк возможный (из всех моих json-ов, полагаю) ... чтоб не превысить 32x разрядов (насколько понимаю)... хотя на кибере хороший топик (Как отловить переполнение границ типа (INT)? ) - и один из ответов последней страницы:
Цитата
1) Задавать такие рамки, чтоб даже после перемножения все влезало.
2) Использовать double который переполнить практически нереально. Зато ошибки округления там могут возникнуть.
3) Таки писать свой класс для чисел.
множить размер массива символов строковой переменной я точно не буду...  :idea:  а посчитать - можно и double'ом обозвать  8)
===
и к слову о RAM - да, наверно, до 3-х можно увеличить - если 2гб для Access (хоть и не весь он лезет в ram, а лишь его интерфейс и функционал)... а к данным драйвер просто подключение делает...
а само по себе увеличение RAM ради 64x-разрядности мне по боку, полагаю  :qstn: ... да и быстрее 64, чем 32, - при одинаковых алгоритмах и количеству данных - не будет при более мощной ram, если её нет смысла использовать?? [мощность ЦП всё равно, наверно, поважнее будет?]
===
Цитата
bedvit написал: По стеку - переходите на кучу.
мне показалось, что Реализация стека за счёт … стека вызовов  -- как раз и есть один из примеров вашего предложения?... где стэк (контейнер) в стэке, а стэк вызовов можно назвать кучей [вобщем сам код]?
Обязательно приму на рассмотрение. Благодарю.
p.s.
вот такие промежуточные выводы пока... если в чём критически ошибаюсь - черканите please... в любом случае - спасибо за наводку резкости в моих глазах и моём зрении  ;)  на 'скорости'
p.p.s
и самое главное :) при рекурсии Дерево то лучше делать квадратным, чем глубоким... 8) но тут я пока слеповата... надо ходить в google
Изменено: JeyCi - 30.06.2019 23:28:02
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Цитата
JeyCi написал: зачем мне больше 32x, если таких цифр у меня в принципе не будет в ценах... надо только прикинуть размер массива символов строк возможный (из всех моих json-ов, полагаю) ... чтоб не превысить 32x разрядов (насколько понимаю)...
Какие преимущества дает 64 битная Windows?... и остальное в том же духе... но для дом. пк и целей программирования, описанных выше (не  берём в расчёт саму тяжёлую Visual Studio) , - 64x роли не сыграют... имхо... если и придётся писать какой обработчик json.файлов - то файл подкачки на жёстком диске мне, наверно, вряд ли понадобится? - это ведь не громадное приложение будет... всё в ram влезет...
64-битная Windows. Преимущества и недостатки.... и то же самое ... просто не совсем могу разграничить понятия - битность OS(=> допускает ram size для, я так полагаю, для динамической подгрузки из неё, вместо с жёсткого диска) и мои потребности в размере стэка и кучи ?? (которые надо закодировать в c++ и распорядиться ими)... хотя, наверно, если ~1 mb стэка (1 048 576 (220) байт. = байт сост из 8 бит) -- а Недостатки 64-разрядной системы:
Цитата
Многие структуры данных в 64-битных программах имеют размер 8 байт (64 бит). Поэтому программы занимают на 10–20% больше места на жестких дисках, чем соответствующие 32-битные версии с 4-байтными структурами.
-- вобщем, значит ли это, что я смогу больше запихать в стэк??.. мне вот как раз-таки кажется, что в в стэк [на 64x] я смогу запихать меньше (хоть и с бОльшей точностью числа)... и скорость считывания этих бит м.б. медленнее при сопоставимой cpu (хотя конечно цп64 сама по себе по-мощнее)... в общем, если не собираюсь делать ни видео ни каширной графики - то, наверно, и не прибавит скорости переход на 64x??... по-логике... или как распорядиться этой доп. битностью с пользой для самописного C++ [стэка и кучи] (или по скорости или по размеру)??...
p.s.
честно говоря, всегда думала, что 64x изобрели для разукраски той же windows7, и подгрузки этого добра из ram... а не для увеличения возможностей бытовых юзеров... (не имею ввиду крупные корпорации с большим потоком бизнес-инфо, прокручивающейся за день через их железо и софт)
Изменено: JeyCi - 30.06.2019 16:35:06
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Ух, сколько всего вы намешали в кучу.
Цитата
JeyCi написал:
остаётся в ЦП - это rpm-характеристика... 7200 конечно быстрее чем 5400... но и поломки при некачественной сборке более вероятны (т.к. скорость вращения шпинделя больше)
ЦП - это центральный процессор, это не HDD.
Перешли на х64 вынуждено, т.к. х32 не поддерживает адрессацию памяти более 4 Гбайт на все процессы. Это мало в современном цифровом мире.
Стек использовать надо с умом, он ограничен. Куча это общая память, ее столько, сколько у вас оперативки, даже больше с учетом файла подкачки. Пользуйтесь этим мощным ресурсом.
«Бритва Оккама» или «Принцип Калашникова»?
 
Куча (память)
Размещение данных в памяти, стек, куча, указатели С++
Изменено: bedvit - 30.06.2019 18:07:36
«Бритва Оккама» или «Принцип Калашникова»?
 
Цитата
bedvit написал: ЦП - это центральный процессор, это не HDD.
я там вроде и указала что понимаю это как CPU в #82...  :oops: ой вижу в #81 косяк - исправила... (ведь, действительно, имела ввиду hdd, просто мысли бежали вперёд рук на клавиатуре)
p.s.
честно говоря, отходила... и по дороге вспомнила, что предыдущим постом вы как раз и советовали кучу, а я всё на автомате про стек  :oops: - вернулась, чтобы дописать по ветке, а вы уже и линки оставили... thanks... вобщем всю память имела ввиду - и кучу, и стэк... пошла знакомиться с вашими линками...
Цитата
bedvit написал: Перешли на х64 вынуждено, т.к. х32 не поддерживает адрессацию памяти более 4 Гбайт на все процессы. Это мало в современном цифровом мире.
вот это меня и смущает... может, для моих целей (если начну писать с++ код) будет очень даже достаточно?.. (у меня пока 32x)... при всех целях, которые описала выше: в длинной арифметике не нуждаюсь, а если что и потребует памяти - то только массив символов строк (всех 500 файлов json - ещё не посчитала сколько это в символах - но можно ведь size его и double'ом задать)...
получу ли я очень большой выигрыш, если начну писать для 64x (и переходить на 4гб ram) ?? как посчитать на сколько выигрыш будет (есть ли такой способ для расчёта с использованием битности ОС и (г или м)байт кучи и стэка?
или такое посчитать - это, действительно, намешала я чего-то ?  :oops:
===
(просто думала, что куча - это часть памяти, где выполняется сам написанный код)
всё - вопрос снимается после вашего
Цитата
Куча это общая память, ее столько, сколько у вас оперативки, даже больше с учетом файла подкачки.
= thanks a lot !!
Изменено: JeyCi - 30.06.2019 23:31:37
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
но есть ведь и другой смысл кучи - Двоичная куча - или это всё про одно? (именно такое творится в ram?) [или это - разные слова, как птица для биологов и для юзеров пк]...
вопрос снимается - вот и линк - Свободное хранение (куча, динамическое распределение ...) ... там же линк на учебник по С++
Изменено: JeyCi - 30.06.2019 19:20:55
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Под какую архитектуру и платформу писать определяет заказчик. Но динамика такова, что больше х64 решений. Думаю доля под эта архитектуру будет увеличиваться. Х32 уже устарел. А скорость работы в основном это правильный алгоритм/логика.
«Бритва Оккама» или «Принцип Калашникова»?
 
Цитата
bedvit написал: А скорость работы в основном это правильный алгоритм/логика.
+1
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Прошу прощения у модераторов за то, что тема так разрослась - с пользой для общего дела...
Предлагаю переименовать в "Возможности разработки взаимодействия с БД (выбор инструментов)"
Изменено: JeyCi - 30.06.2019 23:36:34
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
 
Зачем и когда нужно использовать указатели в C++?
- понравился последний ответ по линку
Цитата
Если кратко, то экономия памяти и тактов проца, когда алгоритм не сложный, это не заметно, но вот вы делаете генерацию мира в 2D игре и перебираете в цикле десятки сотен тысяч массивов с тысячами элементами, и каждый раз проц берет и по одному копирует каждый элемент массива в новый
И вот ваша генерация жрет 5 минут и 10 гигабайт ОЗУ, вместо 10 секунд и 50 мегабайт
...значит, всё-таки с указателями понадёжнее...
чтобы не гадать на кофейной гуще, кто вам отвечает и после этого не совершать кучу ошибок - обратитесь к собеседнику на ВЫ - ответ на ваш вопрос получите - а остальное вас не касается (п.п.п. на форумах)
Страницы: Пред. 1 2 3 4 5 6 7 След.
Наверх