Памяти - чем больше, тем лучше. Потому что программописатели, чем дальше, тем меньше признают такую штуку, как оптимизация кода и их поделия становятся все более прожорливыми до оперативки и прочих ресурсов.
Память - это прежде всего кэш. А кэш - это скорость. Труд программиста дорог, а память гораздо более дешевая. Поэтому, если нужна производительность, то куда дешевле отожрать памяти, чем несколько месяцев гонять программера, чтобы он там супер-пупер алгоритмы придумывал.
Да, бывают исключения. Например, программинг под сим-карты или pos-терминалы, где килобайт на вес золота, или дата-майнинг, где данные могут занимать терабайты, и в память их ну никак не запихнуть все сразу.
А в обычных случаях нефига ее экономить, память эту. Труд программиста намного, намного дороже.
Ну и про ядра. Тут такая штука, разрабатывать многопоточные приложения надо уметь. Это совершенно другой мир разработки. Обычно все хорошо умеют в один поток. А один поток физически не может выполняться на многих ядрах параллельно. Однако если запилить многопоточное приложение, то ему хоть 100 ядер дай, оно найдет чем их занять.
Скажем, если мы пилим какой-нить рендеринг, то он обычно очень хорошо параллелится. И скорость растет почти линейно с ростом количества ядер.
Не зря на видеокартах этих ядер сотни или даже тысячи.
Это всегда нужно было делать явно. Процессор может выполнять несколько команд параллельно, да, но это до первого ветвления, и там может быть такой undo неприятный, если предсказатель ветвления не угадал, плюс это делается в рамках одного ядра. Но я не встречал нигде, чтобы компилятор сам догонял, какие куски кода можно параллелить, а какие нет. Даже простейший цикл без вдумчивого обзора не поймешь, можно запускать параллельно или нет.
К тому же просто так параллелить код - это неправильный подход. Скажем, если это поток вебсервера, то код его параллелить как раз не нужно, так как параллелизация обеспечивается самим веб-сервером, там каждый запрос, грубо говоря - отдельный поток.
Comments 79
тоже хотел про калибровку написать, но уже опередили
в общем мастерок поленился качественный потс написать и притащил какое-то гуано
Reply
Поэтому нельзя сказать, сколько нужно памяти на самом деле. Нужно ровно столько чтобы хватало всем.
Reply
Reply
Да, бывают исключения. Например, программинг под сим-карты или pos-терминалы, где килобайт на вес золота, или дата-майнинг, где данные могут занимать терабайты, и в память их ну никак не запихнуть все сразу.
А в обычных случаях нефига ее экономить, память эту. Труд программиста намного, намного дороже.
Reply
Скажем, если мы пилим какой-нить рендеринг, то он обычно очень хорошо параллелится. И скорость растет почти линейно с ростом количества ядер.
Не зря на видеокартах этих ядер сотни или даже тысячи.
Reply
Reply
Reply
К тому же просто так параллелить код - это неправильный подход. Скажем, если это поток вебсервера, то код его параллелить как раз не нужно, так как параллелизация обеспечивается самим веб-сервером, там каждый запрос, грубо говоря - отдельный поток.
Reply
Reply
Reply
Reply
Reply
Ваша запись попала в топ-25 популярных записей LiveJournal. Подробнее о рейтинге читайте в Справке.
Reply
Leave a comment