вызов функции на С - Версия для печати +- DC-SWAT Forum (http://www.dc-swat.ru/forum) +-- Форум: DreamShell (/forum-3.html) +--- Форум: Programming (/forum-28.html) +--- Тема: вызов функции на С (/thread-2096.html) |
RE: вызов функции на С - megavolt85 - 13.02.2014 21:33 SI{AY писал(а):так что ищите у себя узкие места. Да тут как бы и искать нечего, я уже раньше писал что SD карта у меня от дядюшки Ляо и четвёртого класса. RE: вызов функции на С - SI{AY - 13.02.2014 22:59 все карты уже давно от дядюшки ляо. Сколько брал ничем они не отличаются. Уже давно большая часть всего ток там и делается) Так что Вы рано сдаетесь. Если я праивльно прикинул, что скорость Вашего варианта, что скорость утилиты из комплекта DS, примерно одинаковы) Может дело реализации в KOS? у японца то похоже совсем самописаня. Протестите, будет ли результат лучше чем у Вас http://www.theisozone.com/downloads/dreamcast/other/dreamcast-sd-ripper-v-11-by-jj1dom/ тогда точно будет видно в карту упирается или в реализацию RE: вызов функции на С - megavolt85 - 14.02.2014 08:11 PHP код: <panel x="40" y="115" width="150" height="50"> Как в lua сохранить введённый текст в переменную? RE: вызов функции на С - SWAT - 14.02.2014 08:11 Да я думаю еще флешка косячит, надо бы другую попробовать. У меня тоже есть флешки, которые работают примерно на такой же скорости. А вот с DMA cybdyn верно сказал, сам по себе он скорости не прибавит, а вот если пустить его в параллель записи на флешку, тогда будет толк. А то у тебя простаивает проц пока ждет DMA, а ведь в этом то и вся его суть, чтобы разгрузить проц на другие задачи, пока данные передаются. Но эта задача уже не совсем простая, тут без тредов и их синхронизации не обойтись. В DS есть команда для тестирования скорости, попробуй: Код: speedtest /sd/file.bin В RC1 она правда с косячком, но в целом измерению он не мешает. В RC2 я ее подправил и улучшил немного. RE: вызов функции на С - SWAT - 14.02.2014 08:28 (14.02.2014 08:11)megavolt85 писал(а): Как в lua сохранить введённый текст в переменную? Открой скрипт файл менеджера, там все есть что тебе нужно. Если вкратце: PHP код: local app = DS.GetAppById(THIS_APP_ID); Понятное дело что не нужно каждый раз все это дергать, это как правило делается на этапе инициализации приложения, а потом уже манипулируешь только нужными виджетами. Правда не пойму зачем тебе lua, логику приложения можно так же в модуле и написать. RE: вызов функции на С - megavolt85 - 14.02.2014 08:38 я консольную утилиту написал, а теперь костыль прикручиваю в виде GUI. доберусь до модулей, перепишу код. Мне так проще си изучать SWAT писал(а):В DS есть команда для тестирования скорости Про тест скорости я в курсе и судя по нему скорость рипа должна быть в 2,5 раза выше RE: вызов функции на С - SWAT - 14.02.2014 14:41 Тебе не переписывать надо будет, а просто дописать недостающий модульный код. А по поводу теста скорости, покажи результаты плиз. RE: вызов функции на С - megavolt85 - 14.02.2014 18:55 Код: speedtest /sd/test.bin RE: вызов функции на С - SWAT - 15.02.2014 10:28 Ну результаты как минимум не выдающиеся. Показывай код свой. RE: вызов функции на С - megavolt85 - 15.02.2014 14:20 PHP код: // номер трека, первый сектор, количество секторов,тип диска,путь к файлу Вот кусок отвечающий за чтение и запись. Правда он не совсем валидный, в плане того что сектора 2352 не будут писаться Сижу вникаю как использовать треды. RE: вызов функции на С - SWAT - 15.02.2014 15:44 Для DMA нужно чтобы буфер был в no cache area, иначе есть шанс словить косяка в данных. Вот кусок из httpd-ack, на который я ориентировался при создании кастомных функций для чтения диска и на которых основан код рипа GD на SD самого автора этого мода: PHP код: #define MAX_SECTOR_READ 128 Как видишь буфер у него гораздо больше. И не нужно его в стек запихивать, будет overflow. Стек не резиновый (всего 64кб на сколько я помню на тред), лучше динамически память выделять в таких случаях. Я думаю что он не спроста такое количество считывает за раз, попробуй и ты. RE: вызов функции на С - megavolt85 - 15.02.2014 21:55 Приму к сведению, но без тредов я вижу не обойтись, если хочется выжать максимум. У меня в голове уже крутится одна идейка как это всё организовать RE: вызов функции на С - cybdyn - 15.02.2014 23:35 может как вариант с применение прерываний, смотря что проще. в тредах вроде надо заводить мъютексы или чтото подобное для синхронизации вообщемто можно проще, отправляем команду читать данные по дма. первый раз ждём флага о завершнии дма. далее перед тем как писать эти данные на карту, отправляем команду приводу на считывание следующей порции данных. и к мемонту завершения записи первой порции думаю что дма от второй порции уже завершится, проверяем это и опять считываем след порцию c диска, и пишем вторую порцию.... и так в цикле. т.е. пока пишем готовую порцию - параллельно будет считываться следующая... и не надо потоков и т.д дPугой вопрос правильно инициализировать команда чтобы по дма считывалось... RE: вызов функции на С - megavolt85 - 16.02.2014 00:22 Прерывания не дадут максимальной скорости, а второй вариант я как раз и хочу организовать, только Цитата:пока пишем готовую порцию - параллельно будет считываться следующая...для этого нужен отдельный поток, иначе программа будет ждать завершения считывания (или я не правильно понимаю смысл одно/много поточных приложений?) RE: вызов функции на С - cybdyn - 16.02.2014 00:43 а что треты (или потоки как я понял,)) ) не по прерываниям чтоли переключаются))? , вроде используется таймер? или есть у проца спец возможность переключать? я выше описал способ - по сути чтение с привода какбы происходит без участия проца в то время пока пишем в карту, и как бы и не нужны ни треты, ни прерывания а треты - тут палка о двух концах, переключение потоков будет постоянно рвать передачу в карту, ну если там как то с приоритетами поработать может картина измениться... треты применяют в какихнить многозадачных системах, когда разные приложния параллельно запускаются. RE: вызов функции на С - megavolt85 - 16.02.2014 01:04 треты это потоки, они не переключаются, а выполняются паралельно, без них не проиграть видеоролик со звуком (в одном потоке выводим картинку в другом звук, а основная программа обрабатывает пользовательский ввод) ни написать игру. рассмотрим на примере игры, в игре должен быть поток для вывода графики, поток для вывода звука, поток для обработки команд пользователя и т.д. допустим у нас стрелялка и мы сделали три выстрела, для каждого летящего патрона программа создаст отдельный поток RE: вызов функции на С - MetalliC - 16.02.2014 01:40 ничего там параллельно не выполняется. заведен таймер, скажем на 1/1000 секунды, на котором висит шедулер потоков, и который крутит их как карусель, один-другой-третий и тд, каждый по чайной ложке кванта времени (1/1000с в нашем примере). так все ядра операционок пашут, и ессно есть эффектики которые cybdyn описал. RE: вызов функции на С - megavolt85 - 16.02.2014 03:20 MetalliC писал(а):ничего там параллельно не выполняется.имелось ввиду в рамках одной программы. вызвав функцию программа будет ожидать завершения работы этой функции, затем продолжит свое выполнение, в случае с потоком ,основная программа выполняется параллельно с программой в созданном потоке, а за тем как проц исполняет код в каждом потоке и с какой периодичностью их переключает нас не волнует, это задача ядра. По поводу глюков при использовании потоков, тут уже всё зависит от того, как реализована много-поточность в ядре. Откройте диспетчер задач и посмотрите сколько там процессов запущенно, условно возьмём что каждый процесс это один поток, но как ни странно и музыка в наушниках играет и торент качается и буквы на форуме читаются, причем всё одновременно и ничего не побилось ,а потоков в диспетчере мы насчитали не один и даже не тридцать P.S. совсем забыл, предположим что у нас есть устройство способное принимать данные быстрее чем может отдать GD-Rom и есть два диска (CD-Rom и GD-Rom) с одинаковыми по объёму дорожками с данными, при этом GD диск спишется быстрее чем CD. GD-ROM работает в режиме CAV (постоянная угловая скорость) поэтому, чем ближе данные к концу диска, тем выше скорость их чтения. Отсюда вопрос, какая же средняя скорость чтения штамповки, может один мегабит при текущей реализации программы это нормально, а максимум можно будет выжать два мегабита? RE: вызов функции на С - SWAT - 16.02.2014 07:14 К слову о тредах. Я совсем забыл тебе подсказать еще одну оптимизацию. Дело в том, что в DS видео рендеринг находится в отдельном потоке, поэтому имеет смысл его заблокировать на время записи данных на SD. Или вообще на весь процесс, но тогда все на экране замерзнет конечно. PHP код: LockVideo(); В KOS контекст для тредов переключается с частотой в 100Hz. Тебе чтобы реализовать такую асинхронную работу, для начала нужно написать свою функцию для чтения секторов, которая будет работать асинхронно, а не ждать результата. А сам результат будешь отлавливать на прерывании. RE: вызов функции на С - cybdyn - 16.02.2014 14:41 если треты исполняются на одном проце (ядре) то параллельно тут ничего не работает - а каждый поток исполняется процем в выделенный квант времени - или время до переключения на др. поток. идея потоков тут сводиться к некой псевдо-параллельности, есть понятия "приоритетности", не знаю точно есть ли возможно выделить этих квантов больше чем 1 , или как то увеличить время смены, т.е если поток по карте то естесно ему нужно больше времни так же потоки выполняют полезную функцию арбитража доступа разных процессов к одноу источнику данных. например в игре надо с диска считывть с одного места видео, с другого аудио, в некий момент, надо текст подгрузить, 3д модели обновить. в потоках поэтому можно каждому процессу выделить время чтобы тот прочитал порцию данных и далее передать привод другому потоку. и так по очереди. опять же учитывая приоритеты))) например аудио чтобы работало без пауз |