Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 47
во-первых, не писать, а собирать.
у хорошего программиста программа одинаково хорошо работает и под 64 бита и под 32. разница только в том, как ты ее скомпилишь.
во-вторых, имхо 32-битных компов с разными архитектурами куда больше чем 64.
а вообще man make ;)
у хорошего программиста программа одинаково хорошо работает и под 64 бита и под 32. разница только в том, как ты ее скомпилишь.
во-вторых, имхо 32-битных компов с разными архитектурами куда больше чем 64.
а вообще man make ;)
Да, но только как быть с Freeware, но не OpenSource ПО? \
И давай спросим у Гугля. 64 бита популярнее.
И давай спросим у Гугля. 64 бита популярнее.
Уже довольно давно сижу на Debian x86-64. Проблем нет. Правда, я не использую Skype и другие только-бинарные прогарммы.
Пост навеян попытками установить Адобовский флэш-плеер в Мозиллу. Полтора часа танца с бубнами.
Кстати, ситуация просматривается и под Win. Драйвера на мой тв-тюнер ни в какую не живут на 64-битном железе - слетают после перезагрузки. Производитель - MSI. Год назад отписал на поддержу - ответили "Known problem, will be fixed in new release". Жду до сих пор.
Кстати, ситуация просматривается и под Win. Драйвера на мой тв-тюнер ни в какую не живут на 64-битном железе - слетают после перезагрузки. Производитель - MSI. Год назад отписал на поддержу - ответили "Known problem, will be fixed in new release". Жду до сих пор.
Не вдаваясь в проблему софта, а зачем покупать новое железо, если старое хорошо работает? Вам деньги девать некуда больше? Или это следствие рекламы?
Не вдаваясь в проблемы - как человек, на дух не переносящий INTEL, приобрел год назад комп взамен старому, ибо пора было. Осознанно знал, что покупаю.
Деньги есть куда девать. А рекламы АМД, в отличие от, в России почти нет.
Деньги есть куда девать. А рекламы АМД, в отличие от, в России почти нет.
Что имеется в виду под словом пора?
Под словом пора подразумевается замена морально устаревшего компьютера, на котором крайне медленно работают CAD/CAM системы, ПО для работы с графикой, обработки изображений и пр. Самообучение в этой жизни еще никому не мешало.
"морально устаревший компьютер" - сугубо субъективное утверждение. Нельзя ожидать от всех окружающих аналогичного отношения к вопросу.
Согласен абсолютно, это субъективное понятие. Тем не менее, люди покупают новое железо. Это и покупатели первого компьютера, и приобретающие серьезную рабочую станцию. Как же быть с ними?
Любая ,уважающая себя компания, которая хочет зарабатывать деньги, будет стараться охватить как можно больше юзеров, как отсталых, так и продвинутых. При условии того, что они являются ее целевой аудиторией.
В случае если ПО разрабатывается в складчину/единолично - решение в руках разработчика.
Ну а выбор всегда за вами.
В случае если ПО разрабатывается в складчину/единолично - решение в руках разработчика.
Ну а выбор всегда за вами.
Об этом уже сказано и пересказано много раз. Если вкратце:
- Переписывать под 64 bit имеет смысл только приложения, которые реально могут это преимущество использовать. Т.е. софт, занимающийся какими-то расчётами. Для пользователя это могут быть программы кодирования мультимедиа, обработки 2D/3D графики... да и, пожалуй, всё. Тот же Skype вряд ли выиграет в производительности.
- Не всё зависит от программиста. x64 компиляторы есть далеко не для всех ЯП, и, даже если нужный компилятор найдётся, портирование перекомпиляции.
Таким образом, знания программиста, и тем более его финансовые возможности имеют довольно слабое отношение к нехватке x64 софта.
- Переписывать под 64 bit имеет смысл только приложения, которые реально могут это преимущество использовать. Т.е. софт, занимающийся какими-то расчётами. Для пользователя это могут быть программы кодирования мультимедиа, обработки 2D/3D графики... да и, пожалуй, всё. Тот же Skype вряд ли выиграет в производительности.
- Не всё зависит от программиста. x64 компиляторы есть далеко не для всех ЯП, и, даже если нужный компилятор найдётся, портирование перекомпиляции.
Таким образом, знания программиста, и тем более его финансовые возможности имеют довольно слабое отношение к нехватке x64 софта.
>портирование перекомпиляции.
портирование =/= перекомпиляции.
М, а остальным пользователям просто тихонько покурить в стороне? ;)
Я ставил в параллель Убунту х64 и х32, разница была заметра даже по времени загрузки. Покупая себе систему на х64, я был искренне уверен, что необходимый мне софт (те же CAD/CAM системы) скоро будут использовать всю мощь.
И, для дополнения. Я помню время, когда при сборке ядра был выбор между AMD K6 и AMD К6-2. Но только разница в одной простой вещи - сейчас Linux-версии позиционируются как десктопные. Я соберу из исходников, 99,9% хабровчан - тоже. Но рынок на нас не заканчивается...
Я ставил в параллель Убунту х64 и х32, разница была заметра даже по времени загрузки. Покупая себе систему на х64, я был искренне уверен, что необходимый мне софт (те же CAD/CAM системы) скоро будут использовать всю мощь.
И, для дополнения. Я помню время, когда при сборке ядра был выбор между AMD K6 и AMD К6-2. Но только разница в одной простой вещи - сейчас Linux-версии позиционируются как десктопные. Я соберу из исходников, 99,9% хабровчан - тоже. Но рынок на нас не заканчивается...
>Я ставил в параллель Убунту х64 и х32, разница была заметра даже по времени загрузки.
Я не могу сказать, за счёт чего идёт выигрыш во времени загрузки. Но вполне допускаю, что там может быть какая-то оптимизация. Но опять же - тут раз на раз не приходится. Могу предположить, что большинство обычных программ, используемых на оыбчном десктопе от 64-битности ничего не выиграют.
Кстати, как-то баловался с Suse 32 и 64 - разницы не видел никакой...
Я не могу сказать, за счёт чего идёт выигрыш во времени загрузки. Но вполне допускаю, что там может быть какая-то оптимизация. Но опять же - тут раз на раз не приходится. Могу предположить, что большинство обычных программ, используемых на оыбчном десктопе от 64-битности ничего не выиграют.
Кстати, как-то баловался с Suse 32 и 64 - разницы не видел никакой...
К вопросу о разнице. Ещё пару лет назад купил Атлон64 "какой-то"+... Так вот, специально установил винду 64. Разницу вообще не заметил, с тем лишь моментом, что меньше ПО было 64х разрядным. А для 32х разрядов существовал эмулятор. Который спокойно это всё запускал...
Если рассказывать о разрядности на пальцах, то по моему 32х-разрядное приложение если откомпилировать 64х разрядным компилятором - ничего не изменится. Это как если на заводе человек загружает в тачку 32 килограмма угля (раздающий конвейер даёт только 32кг) и несёт в другое место. Так вот если тачку человеку дать на подъёмность в 64кг, то носить он будет всё-равно по 32, поскольку конвейер раздаёт 32...
Для этого надо менять алгоритм (ставить конвейер на 64кг). И не во всех случаях это сделать просто. Часто (практически во всех случаях), нужно менять элементы алгоритмов обработки данных. А это уже не тривиальная задача...
Если рассказывать о разрядности на пальцах, то по моему 32х-разрядное приложение если откомпилировать 64х разрядным компилятором - ничего не изменится. Это как если на заводе человек загружает в тачку 32 килограмма угля (раздающий конвейер даёт только 32кг) и несёт в другое место. Так вот если тачку человеку дать на подъёмность в 64кг, то носить он будет всё-равно по 32, поскольку конвейер раздаёт 32...
Для этого надо менять алгоритм (ставить конвейер на 64кг). И не во всех случаях это сделать просто. Часто (практически во всех случаях), нужно менять элементы алгоритмов обработки данных. А это уже не тривиальная задача...
> Если рассказывать о разрядности на пальцах, то по моему 32х-разрядное приложение если откомпилировать 64х разрядным компилятором - ничего не изменится.
Ещё как изменится. На большинстве 64-битных архитектур sizeof(int) = 4, sizeof(void *) = 8. И попробуйте объяснить подавляющему большинству среднестатистических "программистов на Visual C++", что в int указатель не всегда вмещается.
А бывает так, что sizeof(int) = 8, и тогда расскажите этим же программистам, что int — это, оказывается, не "32-битное беззнаковое целое".
Но суть в том, что хорошие программы должны писаться с учётом стандартов, а не с ориентацией на одну платформу. Если программист знает, что такое int согласно стандарту, и использует его только так, как положено, то его программа будет компилироваться и работать нормально на любой архитектуре.
Ещё как изменится. На большинстве 64-битных архитектур sizeof(int) = 4, sizeof(void *) = 8. И попробуйте объяснить подавляющему большинству среднестатистических "программистов на Visual C++", что в int указатель не всегда вмещается.
А бывает так, что sizeof(int) = 8, и тогда расскажите этим же программистам, что int — это, оказывается, не "32-битное беззнаковое целое".
Но суть в том, что хорошие программы должны писаться с учётом стандартов, а не с ориентацией на одну платформу. Если программист знает, что такое int согласно стандарту, и использует его только так, как положено, то его программа будет компилироваться и работать нормально на любой архитектуре.
извиняюсь, не уточнил... не раз встречал код, где вместо обычного sizeof(int) используется просто значение "4". это, конечно, уже недочёт программисту, но что-то много так пишут... или я так просто встречал)))
поэтому даже если размер хранилища (переменной) увеличится, то программа не узнает об этом.
поэтому даже если размер хранилища (переменной) увеличится, то программа не узнает об этом.
sizeof(void *) увеличится, а sieof(int) — нет. И уже указатель нельзя преобразовать в int — будет overflow.
Эээ... вообще-то под x86_64 int тоже длиннее. Причем из-за этого может не работать тот софт, что подразумевает 4 байта а не 8.
Абсолютно не обязательно длинее:
$ cat f.c
#include <stdio.h>
int main(int argc, char *argv[])
{
printf("%d\n", sizeof(int));
}
$ gcc f.c
$ ./a.out
4
$ gcc -v | grep Target
Target: x86_64-linux-gnu
$ uname -m
x86_64
$ file a.out
a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.8, dynamically linked (uses shared libs), not stripped
И вообще, x86_64 бывают разные :)
$ cat f.c
#include <stdio.h>
int main(int argc, char *argv[])
{
printf("%d\n", sizeof(int));
}
$ gcc f.c
$ ./a.out
4
$ gcc -v | grep Target
Target: x86_64-linux-gnu
$ uname -m
x86_64
$ file a.out
a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.8, dynamically linked (uses shared libs), not stripped
И вообще, x86_64 бывают разные :)
Угу. Вот еще по этой теме:
http://www.viva64.com/articles/Forgotten_problems_%28rus%29.html
http://www.viva64.com/articles/20_issues_of_porting_C++_code_on_the_64-bit_platform_%28rus%29.html
http://www.viva64.com/articles/Forgotten_problems_%28rus%29.html
http://www.viva64.com/articles/20_issues_of_porting_C++_code_on_the_64-bit_platform_%28rus%29.html
Для C и C++ компиляторы уже давно есть. А если программу писали люди думающие, и с рассчётом на будущее, и все платформенно-зависимые хаки вынесены отдельно, то портирование <приближённо равно> перекомпиляция.
И для каких же языков нет компиляторов для 64 бита :) Ну вобщем да, есть такие - Борланд пролопушили и у них нет делфи для 64 бита, поэтому и тотал коммандер насколько я знаю только 32х битный. А вот у опенсурса все гораздо лучше, фрипаскаль и соответственно лазарус умеют 64 бита не только нативно, но и кросскомпиляцией, так что это беда программиста, что он облажался при выборе языка.
>Ну вобщем да, есть такие - Борланд пролопушили и у них нет делфи для 64 бита
Обещают уже в этом году (см. роадмап).
>тотал коммандер насколько я знаю только 32х битный
Нет, он ещё и 16-битный был до последней версии (для Win 3.1). Отсутствие 64-битного компилятора - не единственная причина, там вообще используется компилятор от второй версии Delphi - он даёт более компактные и быстрые бинарники.
Ещё одна причина, по которой переход на 64 бита для TC затруднён - изменения в плагиновом API. Придётся переписывать сотни существующих плагинов, а многие авторы их уже давно не поддерживают.
Да и не будет для TC никакой выгоды от 64 бит. Разве что CRC будет быстрее считать, да плагины, которые большие объёмы данных обрабатывают, будут чуть быстрее работать (при условии, опять же, что и их портируют).
> А вот у опенсурса все гораздо лучше, фрипаскаль и соответственно лазарус умеют 64 бита не только нативно, но и кросскомпиляцией, так что это беда программиста, что он облажался при выборе языка.
Не могу сказать про это ничего. Ни разу не видел ни одного стоящего приложения, скомпиленного тем или другим.
Но вообще уходим мы от темы. Я своим первоначальным постом хотел сказать лишь, что винить программиста - глупо. Подождите, 64 битный софт года через три-четыре возьмёт своё. 32 бита тоже не сразу пришли - 386 процессор эвона когда появился, а 16-битный софт только со времени 95 винды стал исчезать (да и то, только к XP пропал почти совсем).
Обещают уже в этом году (см. роадмап).
>тотал коммандер насколько я знаю только 32х битный
Нет, он ещё и 16-битный был до последней версии (для Win 3.1). Отсутствие 64-битного компилятора - не единственная причина, там вообще используется компилятор от второй версии Delphi - он даёт более компактные и быстрые бинарники.
Ещё одна причина, по которой переход на 64 бита для TC затруднён - изменения в плагиновом API. Придётся переписывать сотни существующих плагинов, а многие авторы их уже давно не поддерживают.
Да и не будет для TC никакой выгоды от 64 бит. Разве что CRC будет быстрее считать, да плагины, которые большие объёмы данных обрабатывают, будут чуть быстрее работать (при условии, опять же, что и их портируют).
> А вот у опенсурса все гораздо лучше, фрипаскаль и соответственно лазарус умеют 64 бита не только нативно, но и кросскомпиляцией, так что это беда программиста, что он облажался при выборе языка.
Не могу сказать про это ничего. Ни разу не видел ни одного стоящего приложения, скомпиленного тем или другим.
Но вообще уходим мы от темы. Я своим первоначальным постом хотел сказать лишь, что винить программиста - глупо. Подождите, 64 битный софт года через три-четыре возьмёт своё. 32 бита тоже не сразу пришли - 386 процессор эвона когда появился, а 16-битный софт только со времени 95 винды стал исчезать (да и то, только к XP пропал почти совсем).
Ну в какой-то мере я согласен, стоит заметить, что основная проблема с переходом на 64 бита все-таки у проприетарных проектов. ОпенСорс (читай Линукс:) не испытывает совершенно никаких трудностей - страдают только пользователи которым нужны закрытые программы. Тот же тотал коммандер, будучи с окрытыми исходниками уже бы был на 64 бита да и все его плагины до кучи. Насчет выгоды, может я и не прав но тем не менее: в 64х битной ос запуск 32х битных программ по идее будет пожирать больше ресурсов, правда не имею понятия в какой степени - все таки система должна следить за вызовами 32х битных приложений и перенаправлять их для использования соответствующих библиотек. На винде по крайней мере это делается так. Вот ссылка на соответствующую информацию http://blog.not-a-kernel-guy.com/2006/08…
>Тот же тотал коммандер, будучи с окрытыми исходниками уже бы был на 64 бита да и все его плагины до кучи.
Нет, не нужно этого! У TC есть свой цикл развития, который соблюдается уже много лет. Хорошая программа приносит разработчику деньги, как стимул продолжать разработку. К тому же, когда контроль над разработкой и развитием ведётся одним человеком - оно как-то спокойнее. Группа со-разработчиков, предлагающих идеи и занимающаяся альфа-тестингом - хорошо. Но распыление кода - не очень хорошо для подобного проекта.
Можно провести эксперимент. Как известно, FAR с версии 1.80 ушёл в опенсорс. Мажорная версия TC была на этот момент 7.0. Давайте подождём до выхода TC 7.5 (по моим прикидкам это будет вторая половина 2009 года) и сравним количество и качество улучшений в том и другом менеджере.
Нет, не нужно этого! У TC есть свой цикл развития, который соблюдается уже много лет. Хорошая программа приносит разработчику деньги, как стимул продолжать разработку. К тому же, когда контроль над разработкой и развитием ведётся одним человеком - оно как-то спокойнее. Группа со-разработчиков, предлагающих идеи и занимающаяся альфа-тестингом - хорошо. Но распыление кода - не очень хорошо для подобного проекта.
Можно провести эксперимент. Как известно, FAR с версии 1.80 ушёл в опенсорс. Мажорная версия TC была на этот момент 7.0. Давайте подождём до выхода TC 7.5 (по моим прикидкам это будет вторая половина 2009 года) и сравним количество и качество улучшений в том и другом менеджере.
> Да и не будет для TC никакой выгоды от 64 бит.
Да и не нужно никакой выгоды. Лично я хочу иметь чистую 64-битную систему без 32-битных библиотек и остального вороха ненужных вещей для поддержки 32-битных программ. И у меня такая система работает. Да, возможно в 64 битах преимущество получает только 0,1% процент кода. Но зато у меня в памяти не висит 64-битная и 32-битная копия одной и той же библиотеки ради какой-то одной программы. Таких программ (и 32-битных библиотек) у меня нет.
Да и не нужно никакой выгоды. Лично я хочу иметь чистую 64-битную систему без 32-битных библиотек и остального вороха ненужных вещей для поддержки 32-битных программ. И у меня такая система работает. Да, возможно в 64 битах преимущество получает только 0,1% процент кода. Но зато у меня в памяти не висит 64-битная и 32-битная копия одной и той же библиотеки ради какой-то одной программы. Таких программ (и 32-битных библиотек) у меня нет.
Вот это, пожалуй, единственная причина - единство архитектуры. Но тут остаётся только ждать, когда оно будет достижимо.
Лично я хочу иметь чистую 64-битную систему без 32-битных библиотек и остального вороха ненужных вещей для поддержки 32-битных программ.— Доктор, когда я делаю вот так (заводит правую руку себе за спину, изгибается, выворачивает руку и хватает себя за левое плечо), у меня что-то хрустит в правом боку. Я умру?
— А вы так не делайте.
Вы сами себе придумываете ограничения, а потом жалуетесь, что что-то не работает. Если у вас не (как вы выражаетесь) морально устаревший комп, вы никак не заметите потерю производительности от наличия 32-битной подсистемы.
Стэн, ты не прав. Под ДОС очень даже появляеццо, я уж молчу про OS/2 ;) А все разговоры об "устаревшем" оборудовании — происки маркетологов, а ты ведёсся.
Оксид, мы не будем вспоминать про замечательное ПО от ПФР, которое данные может воспринимать только с диска "А" (производство дискет и дисководов прекращено, если я не путаю, 15 инюня прошлого года). Мы так же не будем говорить про ПО от IBM, которое не сомгло даже установиться на мой комп. Мы говорим о том, что реально нужно людям. Происки маркетологов - это реклама Core2Quad, который работает дай бог на 50% от своей мощности.
Кривые руки, точнее кривые мозги, некоторых хм, хм "программистов" как-то мало отношения имеют к железу и нормально написанному софту. По поводу дисководов и дискет... вряд-ли их производство прекращено ибо (Surprise!) не прекращён выпуск современных плат с шиной ISA. Другое дело что это не мэйнстрим, а пром. компьютеры. Кстати, а что за ПО от IBM не смогло поставиться на твой комп. Просто интересно. :)
Наибольшая часть проблем с софтом в контексте современных трендов - 64-битными процессорами, многоядерными/многопроцессорными системами - вызвана не программистами, не проприетарной/свободной моделью разработки, а языками программирования. Существует же множество великолепных языков программирования, в которых о размере "байта" и "инта" пользователь не беспокоится совершенно (ибо он либо жёстко зафиксирован, либо наоборот выводится динамически), в которых параллельность вычислений обеспечивается примитивами языка (и например, любая программа по определению параллельна - например, APL и R), или в которых хотя бы многопоточность и проблемы с нею связанные (синхронизация, обмен информацией между потоками) реализована опять же на уровне языка (с лёту вспоминается Erlang, на котором написано не только куча телекоммуникационного софта, но и некоторые кластерные сервисы Amazon)...
... Но нет, люди предпочитают писать на C++ и Java, "ручками" учитывать размеры разных типов переменных, создавать новые потоки посредством внешних библиотек. (Пожимая плечами) Сами себе злобные буратины.
... Но нет, люди предпочитают писать на C++ и Java, "ручками" учитывать размеры разных типов переменных, создавать новые потоки посредством внешних библиотек. (Пожимая плечами) Сами себе злобные буратины.
Skype и Flash работают по 64 битным Linux. Как минимум под Ubuntu, правда с кучей плясок с бубном :(
Сейчас точно все не вспомню, сам несколько дней на форумах провел, но как минимум стоит поставить getlibs, это помоему все основное решало.
Сейчас точно все не вспомню, сам несколько дней на форумах провел, но как минимум стоит поставить getlibs, это помоему все основное решало.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
64 бит и программисты.