Предоставление определенных версий на 64 бита программного обеспечения
Цвета - это уровень вашего индекса, поэтому используйте его для указания цветов. Измените строку кода на:
counts.plot(kind='bar', title='Counts by Wine Color and quality',
color=counts.index.get_level_values(1), alpha=.7)
В этом случае просто оказывается, что matplotlib может интерпретировать значения в вашем индексе в виде цветов. В общем, вы могли бы сопоставить уникальные значения распознаваемым цветам, например:
color = counts.index.get_level_values(1).map({'red': 'green', 'white': 'black'})
pandas что-то делает с порядком построения, но вы всегда можете вернуться к matplotlib для более надежной циклической обработки цветов. Хитрость заключается в том, чтобы преобразовать color в категориальную переменную, чтобы она всегда отображалась после groupby, позволяя указывать только список ['red', 'white']
import matplotlib.pyplot as plt
wine_df['color'] = wine_df.color.astype('category')
counts = wine_df.groupby(['quality', 'color']).count()['pH'].fillna(0)
ind = np.arange(len(counts))
plt.bar(ind, height=counts.values, color=['red', 'white'])
_ = plt.xticks(ind, counts.index.values, rotation=90)
plt.ylim(0,150) # So we an see (9, white)
plt.show()
6 ответов
Архитектурные преимущества Intel x64 по сравнению с x86
- большее адресное пространство
- более богатый набор регистров
- может связаться против внешних библиотек или загрузить плагины, которые являются 64-разрядными
Архитектурная оборотная сторона x64 режима
- все указатели (и таким образом много инструкций также) поднимают 2x память, сокращая эффективный размер кэша процессора в половине в худшем случае
- не может связаться против внешних библиотек или загрузить плагины, которые являются 32-разрядными
В приложениях я записал, я иногда видел большие ускорения (30%) и иногда видел большое замедление (> 2x) при переключении на 64-разрядный. Большие ускорения произошли в перемалывании чисел / приложения обработки видеоданных, где я был ограничен регистром.
Единственное большое замедление, которое я видел в своем собственном коде при преобразовании в 64-разрядный, из крупного преследующего указатель приложения, где один компилятор сделал некоторую действительно плохую "оптимизацию". Другой компилятор сгенерировал код, где различие в производительности было незначительно.
Преимущество портирования теперь
Написание совместимого кода на 64 бита не то, что твердые 99% времени, после того как Вы знаете, что не упустить. Главным образом это сводится к использованию size_t и ptrdiff_t вместо интервала при обращении к адресам памяти (я принимаю код C/C++ здесь). Это может быть боль для преобразования большого количества кода, который не был написан, чтобы быть знающие 64 бита.
Даже если не имеет смысла делать 64-разрядную сборку для Вашего приложения (это, вероятно, не делает), это стоит времени для изучения то, что это взяло бы для создания сборки так, чтобы по крайней мере весь новый код и будущие рефакторинги составили совместимые 64 бита.
Прежде, чем упорно работать также при выяснении, существует ли технический случай для 64-разрядной сборки, необходимо проверить, что существует экономическая модель. Ваши клиенты просят такую сборку? Это даст Вам категорический участок на конкуренции с другими поставщиками? Какова стоимость для создания такой сборки и какие затраты на ведение бизнеса будут понесены путем добавления другого объекта к учету, торговым и маркетинговым процессам?
В то время как я распознаю, что необходимо понять потенциал для повышений производительности, прежде чем можно будет разобраться с конкурентными преимуществами, я настоятельно рекомендовал бы, чтобы Вы приблизились к проблеме с большой точки зрения изображения. Если Вы - маленький бизнес или сольный бизнес, Вы должны его себе, чтобы сделать соответствующую должную осмотрительность. Если Вы будете работать на более крупную организацию, то Ваши начальники будут значительно ценить усилия, которые Вы прикладываете к размышлению об этих вопросах (или будет считать целую проблему просто гиковским избытком, если Вы будете казаться неподготовленными для ответа на них).
Со всем этим сказал, мой полный технический ответ будет состоять в том, что подавляющее большинство стоящих с пользователем приложений не будет видеть преимущества от 64-разрядной сборки.Подумайте об этом: сколько из проблем производительности в Вашем текущем приложении прибывает из того, чтобы быть ограниченным процессором (или связанный доступ RAM)? В Вашем текущем приложении существует ли проблема производительности? (В противном случае Вы, вероятно, не должны задавать этот вопрос.)
Если это - Клиент-серверное приложение, моя ставка - то, что сетевая задержка способствует намного больше производительности на стороне клиента (особенно, если Ваши запросы обычно возвращают много данных). Предположение, что это - приложение базы данных, сколько из Вашего профиля производительности происходит из-за времен задержки диска на сервере? Если Вы будете думать обо всей совокупности факторов, что влияют на производительность, то Вы наденете лучший дескриптор, извлекло ли Ваше определенное приложение выгоду из 64-разрядного обновления и, если так, необходимо ли обновить обе стороны или произошло ли все преимущество только из обновления серверной стороны.
Не очень еще, действительно. Хотя запись 64-разрядного приложения может иметь некоторые преимущества для Вас, как программист, в некоторых случаях. Упрощенным примером является приложение, основное внимание которого взаимодействует с реестром. Как 32-разрядный процесс, Ваше приложение не имело бы доступа к большим рядам реестра в 64-разрядных системах.
Продолжение комментария @mdbritt, создание для 64-разрядного имеют намного больше смысла [в настоящее время], если это - сборка сервера, или если Вы являетесь распределительными пользователям Linux.
Кажется, что намного больше рабочих станций Windows является все еще 32-разрядным, и не может быть большой клиентской базы для новой сборки.
С другой стороны, много установок сервера являются 64-разрядными теперь: RHEL, Windows, SLES, и т.д. НЕ здание для них сократило бы - от большого потенциального использования, по-моему.
Настольные пользователи Linux, вероятно, будут, также выполнять 64-разрядные версии своего любимого дистрибутива (наиболее вероятная Ubuntu, SuSE или Fedora).
Основное очевидное преимущество создания для 64-разрядного, однако, то, что Вы обходите барьер на 3 ГБ для использования памяти.
Согласно этой веб-странице Вы извлекаете выгоду больше всего из дополнительных регистров общего назначения с ЦП на 64 бита при использовании большого количества из и/или глубоких циклов.
Можно ожидать усиление благодаря дополнительным регистрам и новой передающей конвенции параметров (которые действительно связаны с дополнительными регистрами).