Часовой пояс: UTC + 3 часа




Начать новую тему Новая тема / Ответить на тему Ответить  Сообщений: 1137 • Страница 52 из 57<  1 ... 49  50  51  52  53  54  55 ... 57  >
  Пред. тема | След. тема 
В случае проблем с отображением форума, отключите блокировщик рекламы
Автор Сообщение
 

member+
Статус: Не в сети
Регистрация: 16.01.2004
Откуда: Estonia,Tallinn
berlimrus писал(а):
хорошего репетитора

Да вот найти такого проблема... 99% тех что доступны на рынке сами
Industrialice писал(а):
начинает писать на C# или Java и ему сразу начинает казаться что он просто от бога программист

Более того нужен не только (и даже не столько) хороший программист, но и хороший педагог (а таких и вовсе днём с огнём)

_________________
X99-TF/E5-2678v3+Evo212/2x16Gb-DDR4-Gloway-TYPE-a@2133-12-13-13-26/GTX1070TI/KINGSTON-SNV2S1000G



Партнер
 

Member
Статус: Не в сети
Регистрация: 12.09.2010
Откуда: Калининград
Aside писал(а):
Ну и ассемблер, как бы сказать, мертвый язык в определенном смысле

Тем не менее у него есть своя ниша из которой его никто никогда не вытеснит. В любом случае с ассемблером обязан быть знаком любой уважающий себя системный программист. Те, кто пишет performance-critical программы тоже. Это как минимум
И да, насколько я знаю, микроконтроллеры сейчас в основном на ассемблере и программируют


 

member+
Статус: Не в сети
Регистрация: 16.01.2004
Откуда: Estonia,Tallinn
Industrialice писал(а):
В любом случае с ассемблером обязан быть знаком

На поверхностном уровне да, на серьёзном же это очень узкий рынок...

Добавлено спустя 53 секунды:
Industrialice писал(а):
микроконтроллеры

Они тоже разные бывают, на многие из них давно есть компиляторы, причём весьма неплохие.

_________________
X99-TF/E5-2678v3+Evo212/2x16Gb-DDR4-Gloway-TYPE-a@2133-12-13-13-26/GTX1070TI/KINGSTON-SNV2S1000G


 

Member
Статус: Не в сети
Регистрация: 22.05.2010
Откуда: Москва
Ого, какая у нас тема, оказывается, существует :)
На самом деле абсолютно все равно на каком языке кодить. Учится за две-три недели синтаксис. Главное уметь алгоритмировать и правильно строить "каркас" программы. Ну и знать основные принципы ООП и процедурного кодинга для этого надо бы. И все... По сути, главное - алгоритм, реализация - дело последнее. Обычно каждый сам выбирает для себя направление (веб-кодинг, прикладное программирование, системное программирование) и потом углубляется в изучение :) Для тех, кто выбрал веб обязательно стоит знать php, jquery, уметь ajax-запросы писать, asp, mvc... Для системников (обычно) нужно знать принципы работы компилятора / транслятора, ассемблер маленько (чтобы понимать как будет отрабатывать имеющийся код), ну и остальные ЯВУ. Для прикладников хватит всех ЯВУ и поверхностных знаний всего вышеперечисленного. Это как бы необходимый минимум, человек, заинтересованный в повышении своей квалификации, будет стремиться к большему...

P.S. Микроконтроллеры отдельная ниша, тут, по сути, пишут и на C++ и на ассемблере понемногу, главное знать архитектуру, под которую писать. В частности, набор команд, адресацию и т.п.

_________________
Config: Ryzen 9 5900X * Gigabyte X570S UD * 32GB RAM * RTX 3080 10Gb * SSD/HDD | XBOX Series X
Origin:AccurceD
Steam:opv1988

https://pavel-orlov.com


 

Member
Статус: Не в сети
Регистрация: 28.03.2006
Industrialice писал(а):
Да там ребята такие были что на С++ у них даже с hello world были бы проблемы - но с C#, Java Script и SQL они управились

Ну это слишком притянуто за уши :)

Industrialice писал(а):
Я сейчас пишу на досуге 3д-движок на С/С++, с C# там делать тупо нечего - одни указатели везде и всюду.

То что Ваш движок будет построен на указателях , не означает, что 1) нельзя написать движок без указателей 2) нельзя написать его на C# 3) нельзя написать его на C# без указателей, потому что они там есть.

Industrialice писал(а):
На C# некоторые вещи в принципе невозможны

Приведите примеры, пожалуйста. Я бы на них посмотрел.
Industrialice писал(а):
не зря же microsoft пришлось разработать XNA чтобы и на .NET можно было пускай и сильно ограничено, но хотя бы как справляться с такими задачами

Здесь вы пытаетесь выдать
за аргумент то, что аргументом на самом деле не является. Смотрите: XNA это технология программирования, Framework, 1) на каком языке она написана и какой язык будет ее использовать - это вопрос десятый 2) те ограничения, которые там есть, - это ограничения самой технологии, к языку C# они отношения не имеют. 3) Если вы знакомы с этой технологией на достаточном уровне, то легко заметите, что существенных ограничений там как раз нет, по сравнению с DX 9.

Industrialice писал(а):
Про невозможность написания драйверов или операционных систем на C# можно даже и не упоминать.

Этот пример не показателен, потому, что , во-первых, C# - это не язык системного программирования. Легковая машина не предназначена для перевозки грузов в 10 тонн, понимаете? Но это не значит, что на ней нельзя ездить. Во-вторых: программирование драйверов это весьма специфический вид программирования, которым занимаются от силы 5-8% всех программистов, а то и меньше.

Industrialice писал(а):
Примеров на самом деле много можно найти - ведь чем выше язык, тем меньше у него возможностей.

Вот это как раз совершенно неверно. Ограничения определяются не языком, а его рантаймом. В случае C# - это .Net framework, в случае Java - виртуальная машина Java. Какие ограничения они накладывают - это весьма управляемо в теории. То, что на c# нельзя писать драйверы - это не ограничения языка, а мы здесь говорим именно про язык.

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

_________________
Первый огонь был получен людьми из-за перегрева.
Пессимист отличается от оптимиста датой наступления конца света.


 

Member
Статус: Не в сети
Регистрация: 12.09.2010
Откуда: Калининград
Aside писал(а):
То что Ваш движок будет построен на указателях , не означает, что 1) нельзя написать движок без указателей 2) нельзя написать его на C# 3) нельзя написать его на C# без указателей, потому что они там есть.

На DirectX или OpenGL Невозможно написать движок без использования указателей - потому как даже самые простые вещи в этих API подразумевают использование указателей - без них использование хотя бы небольшого набора функций нереально. В safe указателей в C# нету, в unsafe теряются многие преимущества C# и мне интересно чем вы тогда вообще обоснуете использование именно этого языка. Вам так захотелось - ну так мы мешать не будем, есть ведь люди которые, например, исключительно руками едят - даже суп. Всякие есть

Aside писал(а):
Приведите примеры, пожалуйста. Я бы на них посмотрел.

Драйвера, ОС и прочее системное программирование вам не катят за примеры?
Aside писал(а):
Здесь вы пытаетесь выдать за аргумент то, что аргументом на самом деле не является. Смотрите: XNA это технология программирования, Framework, 1) на каком языке она написана и какой язык будет ее использовать - это вопрос десятый 2) те ограничения, которые там есть, - это ограничения самой технологии, к языку C# они отношения не имеют. 3) Если вы знакомы с этой технологией на достаточном уровне, то легко заметите, что существенных ограничений там как раз нет, по сравнению с DX 9.

Простите за глупый вопрос, но вы много кодили на DirectX и на XNA?

Aside писал(а):
Этот пример не показателен, потому, что , во-первых, C# - это не язык системного программирования. Легковая машина не предназначена для перевозки грузов в 10 тонн, понимаете? Но это не значит, что на ней нельзя ездить. Во-вторых: программирование драйверов это весьма специфический вид программирования, которым занимаются от силы 5-8% всех программистов, а то и меньше.

Он не язык системного программирования хотя бы потому что у него нету для этого возможностей

Aside писал(а):
Вот это как раз совершенно неверно. Ограничения определяются не языком, а его рантаймом. В случае C# - это .Net framework, в случае Java - виртуальная машина Java. Какие ограничения они накладывают - это весьма управляемо в теории. То, что на c# нельзя писать драйверы - это не ограничения языка, а мы здесь говорим именно про язык.

Вот когда будет C# генерировать машинный код - тогда вы и сможете говорить что сказанное мною неверно. Сейчас C# неразрывно связан с .NET - так что говоря про C#, я имею полное право при этом подразумевать .NET. Точно также с Java

Aside писал(а):
В целом из того, что вы пишите, - это скорее лозунги, чем реальные факты. Не вводите ими в заблуждение тех людей, которые читают этот топик. Вы фанат какого-то отдельного языка или отдельной технологии, и недостаточно хорошо знаете остальное, возможно, у Вас еще опыт не набежал.

Вы приведите сначала Реальные контаргементы, а не переходите на "вот ты, да ты". В C# огромное количество всего берёт на себя язык - вам не нужно париться про стек, кучу, сегменты данных( то есть вообще про память ) - не нужно даже знать о их существовании. Человек может очень круто прогить на шарпе, но пока у него такие пробелы, ему во многие области вход закрыт
Тем более что C# полностью ООП-ориентирован - умея писать структурный код не так сложно освоиться с ООП, а вот слезать с ООП на структурный код - чёрт, я бы на мучения этого человека посмотрел бы. Хотя это слишком жестоко

Aside писал(а):
Вы фанат какого-то отдельного языка или отдельной технологии, и недостаточно хорошо знаете остальное

А вы ну так, не пробовали к себе эту цитату применить?


 

Member
Статус: Не в сети
Регистрация: 28.03.2006
Уважаемый Industrialice , я не вижу больше смысла с вами разговаривать, поскольку
1) Мой опыт программирования и квалификация куда больше, чем ваши, и вы не показали мне обратного
2) Вы не приводите никаких реальных аргументов и прячитесь за весьма общими проблемами, такими как "стек", "память", и прочие , я же в свою очередь привел вам несколько конкретных утверждений.
3) Это не тема для троллинга, который вы здесь пытаетесь начать :) Не вводите в заблуждение людей, которые сюда приходят, чтобы начать программировать, своим не вполне квалифицированным и аргументированным мнением :)

Удачи!

Добавлено спустя 13 минут 35 секунд:
Теперь я дам несколько комментариев по поводу того, что вы написали, чтобы люди не читали не вполне корректную информацию:
Industrialice писал(а):
На DirectX или OpenGL Невозможно написать движок без использования указателей -

И на DirectX и на OpenGL такой движок написать ВОЗМОЖНО.
(если кто-то в этом сомневается, я могу в PM рассказать , как это сделать)
Industrialice писал(а):
Драйвера, ОС и прочее системное программирование вам не катят за примеры?

Такое сравнение это все равно что сравнивать шахматиста и футболиста в игре в футбол, лопату и грабли в эффективности копания земли, и так далее. Такие сравнения НЕТ СМЫСЛА делать. Это и так понятно, что системные программисты должны ориентироваться не на C#. Исключение составляют программисты компиляторов, которые тоже относятся к системным программистам.

Industrialice писал(а):
Вот когда будет C# генерировать машинный код - тогда вы и сможете говорить что сказанное мною неверно. Сейчас C# неразрывно связан с .NET - так что говоря про C#, я имею полное право при этом подразумевать .NET. Точно также с Java

Это одно из самых популярных заблуждений людей, которые слабо знакомы с .Net. Запомните на всю жизнь: генерирует .Net машинный код, ГЕНЕРИРУЕТ. Механизм же этой генерации отличается от С++, вот в чем все дело.
Industrialice писал(а):
Тем более что C# полностью ООП-ориентирован - умея писать структурный код не так сложно освоиться с ООП

Умения писать структурный код и ООП код - это РАЗНЫЕ умения. Тот, кто сделал несколько проектов, понимают, почему это так.

_________________
Первый огонь был получен людьми из-за перегрева.
Пессимист отличается от оптимиста датой наступления конца света.


 

Member
Статус: Не в сети
Регистрация: 12.09.2010
Откуда: Калининград
Aside писал(а):
прячитесь за весьма общими проблемами, такими как "стек", "память", и прочие

Для ассемблерщика это действительно проблемы, для С/С++ программиста чуть в меньшей степени - но тоже. А вот для C# программиста - это вообще не проблема. Мы тут в теме про то, с чего начинать лучше - я высказал и аргументировал, а вы тут только свой любимый( видимо ) язык защищаете. В этом разница
Aside писал(а):
Мой опыт программирования и квалификация куда больше, чем ваши, и вы не показали мне обратного

Я, как вы сказали, прячусь за стеком и т.д., ну а вы за опытом прячетесь

Добавлено спустя 8 минут 45 секунд:
Aside писал(а):
И на DirectX и на OpenGL такой движок написать ВОЗМОЖНО.
(если кто-то в этом сомневается, я могу в PM рассказать , как это сделать)

Раз вы сами предложили - мы взяли попкорн и приготовились слушать
Aside писал(а):
Это и так понятно, что системные программисты должны ориентироваться не на C#. Исключение составляют программисты компиляторов, которые тоже относятся к системным программистам.

Вы меня просили привести пример того, что невозможно сделать на C#, я вам привёл. Какие тут могут быть претензии?

Aside писал(а):
Это одно из самых популярных заблуждений людей, которые слабо знакомы с .Net. Запомните на всю жизнь: генерирует .Net машинный код, ГЕНЕРИРУЕТ. Механизм же этой генерации отличается от С++, вот в чем все дело.

Are you fucking kidding me, вы думаете я не знаю как работает .NET? Я и писал немало на C#, курировал коммерческий проект, и дизассемблировал написанные на нём проги, пробовал делять кряки - но как работает сам .NET - увы и ах, вообще не в курсе. Не знаю ни что такое трансляторы, интерпретаторы и байт-код - просто мимо проходил, дверь была открыта...
Aside писал(а):
Тот, кто сделал несколько проектов, понимают, почему это так.

А я ни одного проекта не сделал, да. Вы прочитайте внимательно: я не сравнивал структурное программирование с ООП, я лишь сравнил то, насколько тяжело с одного вида программирования перейти на другое


 

Member
Статус: Не в сети
Регистрация: 28.03.2006
Пускай Industrialice и прочие упрямые юнцы пишет на низкоуравневых языках. Мы больше проектов сделаем. :)

_________________
Первый огонь был получен людьми из-за перегрева.
Пессимист отличается от оптимиста датой наступления конца света.


 

Junior
Статус: Не в сети
Регистрация: 01.03.2012
Industrialice писал(а):
У меня недавно знакомый, не программист по сути даже, выполнял проект, программа для завода, для лазерной установки - довольно неплохой сложности. Это если на С/С++ писать, на C# он не прочитал ни одной строки литературы, просто сел писать, в случае редких затыков спрашивал меня или на форуме что делать. В итоге - 7+ тысяч строк отборного гав-но-кода, но это работает - и хорошо работает. На языках типа С/С++ такое вообще нонсенс

Скорее всего, этот ваш знакомый ранее знал Паскаль (бейсик) или если ему за 30 возможно, что и фортран и фактически не использовал вообще никаких особенностей языка C#, просто наваял алгоритм, надеюсь хоть не в виде одной функции с телом в 7+ тысяч строк. Такое он мог бы сделать и на C/C++, не вижу почему нет.

Если я прав, вы его не правильно использовали :D Работа этого знакомого - аналитика, а не написание программ и ему надо было не C# давать, а MatLab или аналогичные программы. На C# уже кто-то должен был его перевести. Конечно, в идеале, на практике по разному бывает.

Один из мифов, что на C# проще писать без ошибок. До некоторой степени это так, понаделать тупых ошибок в работе с динамической памятью на нем почти невозможно. Зато возможно многое другое. От нерационального использования ресурсов, до неправильной работы с потоками.


 

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


 

Member
Статус: Не в сети
Регистрация: 20.03.2009
Откуда: Санкт-Петербург
Я думаю, что во фрилансе всё же гораздо больше доля веб-программирования. Большие проекты на java/c++ попадаются реже.

_________________
Задачи бывают простыми и очень простыми...


 

Danmerpro питон перл пхп что то из этого списка подходит? что то попроще для понимания начинающему?


 

Junior
Статус: Не в сети
Регистрация: 02.08.2012
rchpsin писал(а):
Danmerpro питон перл пхп что то из этого списка подходит? что то попроще для понимания начинающему?


Зависит от целей.
Если это сайтостроение - MVC фреймворк, фреймворку рознь...

--- РНР ---

РНР сейчас на стадии утилизации и от версии до версии много новых фич появляется, а то что люди сейчас используют быстро устаревает. Большинство хостингов на данном этапе развития среды РНР предлагают 5.2 версию.
Из нормальных 5.2 фреймворков можно выделить Yii и CakePHP.
Собственно одним из недостатков Yii является декларативный подход в шаблонизации...
Это скорее опция которая делает ваши шаблоны медленее)

Вообще принято в РНР решениях использовать кэширующие байт-код средства.
XCache, EAccelerator. Так же принято использовать регрессионное кэширование с TTL на основе memcached/redis.
Обычной ошибкой Yii программистов является кэширование всех запросов к БД...
Без "времени жизни" и вторичных модификация объектов в кэше.
Соответственно memcached пожирает вагон и маленькую тележку памяти, а устаревшие сущности в кэше заменяют актуальные.

РНР Шаблонизация дело добровольное... если использовать байт-кэширование проблем нет, без нее не очень - около 0.4-0.8 сек. отклик. В принципе альтернативой является использования С-ишных шаблонизаторов в виде плагина к РНР.
К ним относятся ctpp и blitz. Последний любят использовать всякие badoo и хаброводы.

Нативного ассинхрона в РНР нет... php-fpm => один запрос - один поток (и ограниченное кол-ство дочерних)
Есть там всякие fork'и PThread'ы и проч. геморой, но ничего нативного (прощай вертикальное масштабирование).
Есть возможность построения Disruptor'а на основе beanstalkd, gearmand, memcache-queue.
Таким образом можно ускорить обработку запросов в раз 5, но нужно самому писать обработку всех запросов и их валидацию, фреймворков поддерживающих это добро нет. Да и писать там не так уж и много - есть Symfony2 components а там обработчиков к очередям реализовать не проблема ( 1.5 года стажа хватит ;) )

Из перспективных РНР фреймворков на сегоднешний день можно выделить Symfony2.
Большинство кирпичей и велосипедов которые хотелось бы написать в нем уже есть.
Ооочень гибкая модульная архитектура, ничего подобного в других фреймворках (вообще во всех) нет.
Symfony2 использует плюшки РНР 5.3
Собственно РНР 5.3 быстрее 5.2... а 5.4 быстрее 5.3 =)

На 5.4 фреймворков нет.
РНР стремится к тому что бы реализовать все плюшки необходимые в повседневном РНР кодинге под капотом, по-этому от версии до версии вагон нововведений и изменений. Со временем это будет что-то среднее между Java/Scala и С++. =)
Так что через полгодика-год РНР быдлокодинг никогда не будет прежним)

--- РERL ---

Особого смысла изучать Perl я не вижу.
Байки про Perl-высоконагруз вводят меня в ступор, с таким же успехом РНР без кэшей будет в разa 2 быстрей.
Для меня Perl это bash на стероидах, отношение за 6 лет к нему не изменилось. Кому-то нравится кому-то нет.
... и сплошное горизонтальное масштабирование. Из нормальных фреймворков можно выделить Catalyst.

Почему Perl проггеров берут на работу:
1) Поддерживать существующие решения, не потому что они оптимальны или хорошо решают поставленные задачи, а просто потому что они написаны на Perl
2) Потому что в конторе любят Perl)

--- Python ---

По скорости питон что-то среднее между Перлом и PHP.
Особенно хочу отметить то что кэшированый РНР спокойно обгоняет питон.
Масштабирование тоже в основном горизонтальное... как и в остальных в этом списке.
Если хотите скорости на питоне стоит обратить внимание на llvm компилятор питона.
На сколько коректно под ним работает Djangо не имею ни малейшего понятия, однако слышал неоднократные истории успеха подобного изврата.

Де-факто сайтостроительства на питоне это Django.
Кодить просто и приятно... Синтаксис ужасно прост и понятен - таков уж питон.
По ощущениям напоминает Grails, но мой любимый Symfony2 ничем не проигрывает Django.

---

В общем лично мое мнение TOP5 фреймворков это

1. Play2 -> ассинхрон и вертикальное масштабирование везде и всегда, ибо Akka используется.
Очень сложно привыкнуть к шаблонизации на Scala. Но производительность решает. Идеален для SOA.
2. Grails2 -> ORM прост и до ужаса не навязчив. Ассинхрон Java нативный постредством контекстов. SOA в коробке.
3. Symfony2 -> Ибо просто и удобно. SOA возможно, но с костылями.
4. Django -> Просто удобно, но медленно... SOA по идее возможно, и структура костылей намного проще чем в РНР.
5. Yii -> расплодил кучу быдло-коддеров и хомячков, особенно во фрилансе. Просто дань моды, и есть много недоработок, но с напильником довольно неплохое решение. SOA, как и во всех РНР решениях, возможно посредством костылей иногда довольно сложной конструкции, требующих изобретения нановундервафли.

Я не рассматриваю C# ибо не люблю форточки и не вижу особых перспектив в форточном высоконагрузе, а Mono - УГъ.
Да и вообще лицензирование и подход к разработке мелкомягких меня вводит в ступор...

Добавлено спустя 16 минут 42 секунды:
Если рассматривать вопрос "что профитней"?

Собственно вопрос профитов в постсоветском пространстве стоит в виде выхлопа результатов работы.
Если это сайтостроительство, наибольший выхлоп дают Rails-подобные фреймворки и TDD/BDD.

Если это "програма для управления фрезерным станком"...
Тут собственно пофигу что С++ что C#, с хорошим скилом выхлоп будет одинаковым.
Единственным нюансом является то что С++ решения обычно менее требовательны к ресурсам.
По поводу построения UI на С++ ... лично мое мнение лучше Qt пока ничего нет.
Тут и кросс-платформенность и мета-объектная архитектура, и проблем с распределением памяти и сборщиком мусора нет.
С# юзают фанаты... и яро отстаивают свое зря потраченное время,
собственно я так говорю просто потому что имею довольно большой опыт разработки под различные платформы и языковые средства.
Так же это просто психологическая особенность СНГешников, ибо им трудно осознать что время было потрачено "типа как зря", и они сами воспринимают подобные высказывания как личную критику и "атаку собеседника."

Выхлоп в С# такой-же, но порог вхождения значительно выше.
Особенностью мелкомягкого подхода является "под капот с низким скилом не залезешь".
В Qt дела обстоят по-другому... хочешь под капот - пожалуйста.
Под капотом используется около 10тка оригинальных подходов, и найти русскоязычное толкование не проблема.
+ все опенсорсное.

У Qt LGPL лицензия - в проприетарщине использовать можно, просто нужно будет поставлять отдельно DLLками.
Если писать проприетарное С# ... не знаю как там с лицензиями, но точно не все так чисто и прозрачно.
По-любому денежку мелкомягким рано или поздно придется платить.

Добавлено спустя 10 минут 20 секунд:
На самом деле, учитывая психологические недуги моих заказчиков и исполнителей, могу сказать что
Смысл не в том что
... бы заработать много денег здесь и сейчас
... бы получить готовый рабочий (хоть как-то) продукт здесь и сейчас
... бы нанять кучу народа и ждать от них быстрого выхлопа
... я начальник, а ты должен выполнять любые мои требования за деньги
... у меня есть деньги, а у тебя их нет!
... вот я сделал у меня работает - значит это оптимальное решение
... бы написать и забыть про повторное использование кода в других проектах
... бы писать тесты сразу же после старта работ
... бы ориентироваться на масштабирование ещё до старта работ
... бы жертвовать производительностью ради удобства

Подобное отношение не совместимо с IT бизнесом.
Просто постсоветские (и не только) психологические расстройства...

Добавлено спустя 37 минут 51 секунду:
По поводу ембедедов, и высказываний "ассемблер мёртв и жив только в микроконтроллерах"....
Это вы наверное вспоминаете быдлокурсач по AVRках

1) ARMы дааавно вытеснили PIC/AVR/MSP430 по соотношению цена/енергопотребление/начинка :-P
2) Ну вот представте себе ситуацию в AVRках и x86 всего 4 регистра общего назначения, а в ARM - 27.
Я не представляю себе человека способного решить задачу по раскраске графов в 27 цветов, и оформить это в ASMе.
Да и в 4 цвета человек оптимально не разукрасит... по крайней мере GCC справляется с этой задачей намного лучше.
Вообще сейчас 80% контроллеров прогрмируется на С. А компиляторы в худшем случае на основе GCС, в лудшем на основе LLVM.
Последний просто дико оптимизирует все и всея при правильных заклинаниях.
Конечно порт архитектуры с генетическим алгоритмом для раскраски графа... нужно ещё написать :-)
и как известно не все идут оптимальными путями, а предпочитают пути с наибольшим выхлопом,
хотя трудозатраты всего лишь на 10-20% больше.

В общем Cortex-m0 Cortex-m3, это STM32 и LPC**** - наиболие перспективны в встраиваемых системах.
Так же стоит обратить внимание на mips решения, в некоторых случаях они обходят ARMы.


 

Member
Статус: Не в сети
Регистрация: 24.06.2003
Откуда: Москва
mopc.sladkoff большое спасибо за развернутый ответ. Мне, как php-разработчику было интересно прочитать, много незнакомых штук обнаружил =)
Меня единственное, что смущает, это утверждение, что Symfony2 однозначно лучше Yii. По функционалу конечно это так, а вот по скорости приложений и разрабоки, а также удобству отладки?

_________________
.


 

member+
Статус: Не в сети
Регистрация: 16.01.2004
Откуда: Estonia,Tallinn
mopc.sladkoff писал(а):
Выхлоп в С# такой-же, но порог вхождения значительно выше.

Ох не сказал бы...

mopc.sladkoff писал(а):
Подобное отношение не совместимо с IT бизнесом

Я это понимаю, ты это понимаешь, 99% заказчиков нет... Они чаще всего считают что смысл именно во всём том что ты перечислил... И это обидно...

Добавлено спустя 2 минуты 56 секунд:
mopc.sladkoff писал(а):
Я не рассматриваю C# ибо не люблю форточки и не вижу особых перспектив в форточном высоконагрузе

в высоконагрузе да, в коммерческом применении другое дело, если программа "выстрелила" то пользователь просто купит более быстрый комп...

_________________
X99-TF/E5-2678v3+Evo212/2x16Gb-DDR4-Gloway-TYPE-a@2133-12-13-13-26/GTX1070TI/KINGSTON-SNV2S1000G


 

Member
Статус: Не в сети
Регистрация: 12.09.2010
Откуда: Калининград
mopc.sladkoff писал(а):
в x86 всего 4 регистра общего назначения

В x86 в 6 регистров общего назначения, и 14 в x86-64. И это если считать только целочисленные
По поводу остального вспомнились слова из песни группы Машина времени, "Не стоит прогибаться под изменичивый мир, пусть лучше он прогнётся под нас". Особенно где фраза про то, что человек зря потратил время программируя на C# и не хочет это признавать - чисто из-за своего упрямства. Может он удовольствие получил, да и основополагающие принципы программирования везде одни и те же - с чего ему вдруг признаваться что он время зря потратил? На работе не пригодилось? Какой кошмар


 

Junior
Статус: Не в сети
Регистрация: 02.08.2012
2 Industrialice

Я не супер ASMо-коддер. Могу ошибаться... пишу порт Scala под LLVM =)
Рассматривал ассемблеры различных архитектур 3 года назад... может чего и напутал.
В основном работаю с микроконтроллерами и FreeRTOS. Иногда вшиваю линь, но редко.
В любом случае я имел ввиду то что человек не сможет распределить все ресурсы процессора лучше чем это сделает генетический алгоритм
в купе с несколькими нейронками... Нейронка обучающаяся ген. алгоритмом сейчас просто "бич моды оптимизации",
а в уме такое не посчитаешь :-)
-----

2 Vladson

Обычно люди развивают знание Сишки на уровне С -> С++ -> C# или Java.
Я начал с джавы, но как-то нужно было закодить магазинчег на ASP.NET... и С# не оказался большой проблемой.
Лично я считаю что порог вхождения в "подкапотную С#" значительно выше.
В контексте С++ я подразумеваю использование Boost'ов и Qt...
C qt дело обстоит более двояко.
Порог вхождения ниже просто потому что разобраться с работой UI, сокетов, WebKit'а, потоков, сигналов-слотов намного проще.
С другой стороны способы реализации синглетонов, свойств / полей, мета-объектов ложится на старый-добрый MOC, и там начинается магия.
В принципе не сильно её там и много...
Зная С++ даже на начальном уровне ООПа, и понимая принципы построения шаблонов проектирования,
с Qt разобраться проще. И не нужно учить новый язык...

По поводу объёма комерческих выхлопов (время/объём) С# не сильно обгоняет С++ решения...
Проблема скорее не в сложности освоения, и не в количестве выхлопа,
а в том что пряморуких С# коддеров больше чем С++ных, фанаты != пряморукие,
и тем не мение на сегодняшний день C# более разрекламирован.
Учитывая новый стандарт плюсов... чаши весов все более и более склоняются в сторону C#.
-----

2Kryos

Я и не говорил что Symfony2 намного быстрее Yii, симфония намного удобней. А в продакшене разницы особой нет.
В архитектуре... Yii использует ActiveRecord, симфония - ObjectMapping.
Обое на DependencyInjection, что как-никак упрощает кэширование.
Огромная разница в скорости работы прослеживается на этапе разработки, из-за того что в симфонии очень много чего компилируется/кэшируется.
Это переупаковка классов, кодогенерация, разбор yml/xml (или что там у вас), сборка шаблонов.
В Yii этого всего нет... по-этому бытует предрассудок что симфония медленей, но это не так.
Собственно с точки зрения производительности Symfony2 выигрывает из-за Doctrine,
так как он очень неплохо оптимизирует выборки и Join'ы при переупаковке классов (кэширование AppKernel).
В обоих фреймворках нужно задавать TTL для объектов хранимых в Memcached/XCache, или что вы там используете.
У симфонии есть отличный механизм http-кэширования с правильной раздачей параметров кэширования страниц... это редкость для РНР в принципе :crazy:

-----

Самым "быстрым" в плане производительности я считаю Play2 фреймворк с Java offheap кэшированием посредством недокументированных функций JVM, а не Ehcache и прочей лабуды. Так кэшируют Одноклассники, и довольно неплохо кэшируют :hi:.
А скорость работы достигается за счет использования механизма актеров Scala/Akka.


 

Member
Статус: Не в сети
Регистрация: 12.09.2010
Откуда: Калининград
mopc.sladkoff писал(а):
Я не супер ASMо-коддер. Могу ошибаться... пишу порт Scala под LLVM =)Рассматривал ассемблеры различных архитектур 3 года назад... может чего и напутал

В 32-битном х86 общего назначения регистры это eax, ebx, ecx, edx, esi, edi. При желании можно запушить( или вообще не юзать стэковые фреймы ) указатель на фрейм стэка ebp и юзать для своих целей его. При ещё большем желании можно скинуть указатель на вершину стэка esp в память и также его поюзать. Итого 8 регистров получается, которые можно юзать по своему усмотрению для решения конкретной задачи - может я ещё чего-то не знаю. Этого должно быть достаточно для большинства типичных задач, для каких-нибудь научных, конечно, вряд ли - но там есть всякие архитектуры типа Intel Itanium, где 128 целочисленных регистров


 

Junior
Статус: Не в сети
Регистрация: 02.08.2012
Спасибо Industrialice, матан вспомнил... :shock:
Я не фанат ассемблера, больше по теории построения компиляторов и методов оптимизации алгоритмов.
Считаю что проще изучить псевдо-код LLVM'а... и уметь писать под большинство архитектур, и даже под видеокарты)
При этом не заморачиваясь с ассемблером. В простой жизни он не очень-то и нужен.
А для оптимизации чего-то абстрактного, но часто встречающегося в жизни, лучше написать очередной проход к компилятору, закомитить и помочь сообществу. Так профита поболее.


Показать сообщения за:  Поле сортировки  
Начать новую тему Новая тема / Ответить на тему Ответить  Сообщений: 1137 • Страница 52 из 57<  1 ... 49  50  51  52  53  54  55 ... 57  >
-

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 3


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Перейти:  

Лаборатория














Новости

Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB | Kolobok smiles © Aiwan