Изпечатай

[gat3way]

Като му оправят софтуера, мене ми писна да ми крашват някакви неща и със зор да си подкарвам флаш плъгини и т.н. Освен това рам-та ми е по-важна отколкото някаква си там имагинерна подобрена производителност, която субективно така и не мога да оценя за момента '>

[trip]

Да ама ако няма потребление няма и производство '>

[triplek]

Плугина работи чудесно. '> 10х to trip.

/офф
Недейте да се карате. Разлика има голяма между 64 и 32 вата. Софта си работи перфектно, като изключим тоя плугин. Ако някой някъде има проблем с някой сорс да си провери/смени компилатора. Гейтуей като го кефи да си ползва ако иска и 8 битова ОС.

[gat3way]

Мммм между 8 битовите архитектури и 16-битовите има фундаментални разлики - като изключим 64-те килобайта адресно пространство, което още тогава е било недостатъчно (BTW досовските .COM файлове са реликва от това време, те имат същия 64 килобайтов лимит '> ). 8-битовите I/O операции водят до много огромни ограничения и всякаквото съществуване на примитивна мултимедия и мрежови насочености е живо чудо и благодарение на големи фокуси.

Разликата между 16-битовите и 32-битовите архитектури също е огромна - тогава се въвежда понятието "защитен режим" и дефакто истинска многозадачност с отделни виртуални адресни пространства за всеки процес, така че един процес по грешка да не може да съсипе цялата операционна система. 4-те гигабайта витуална памет, която може да се адресира е прекалено много, дори в днешно време. Главно защото вече имаш многозадачност, могат да се форк-ват други процеси и си има механизми за IPC. Дори сега обаче малко са приложенията, където един процес да ИМА нужда от повече от 4 гб памет. Това което аз се сещам са java приложения, например някакъв application server, където ти трябва повече heap memory и в рамките на java процеса си имаш собствен трединг и собствен мениджър на паметта, garbage collection механизми и т.н.

Обаче разликата между 32-битови и 64-битови архитектури в днешно време където средната десктоп система има не повече от 2-4 гигабайта рам просто е нищо на фона на това което е било допреди.

Когато приложенията почнат лакомо да тъпчат по няколкостотин гигабайта памет ще се замисля.

Но иначе най-доброто преимущество на 64-битовите архитектури е голямото адресно пространство (при съществуването на ALSR) и хардуерния NX бит, което прави старите buffer overflows ужасно сложни за експлойтване и ерго приложенията са по-сигурни от гледна точка на програмистки грешки.

Но аз примерно имам 2 гигабайта РАМ тук вкъщи. Айде сега си направете една елементарна сметка - една програма резервира памет за масив от pointer-и от 100.000 елемента. На 32-битова ОС това ще заеме 400 килобайта, на 64-битова - 800 килобайта. Това е прост пример. При всички положения, 64-битовата ОС ти използва повече памет, отколкото 32-битовата. Еее, аз някак си ще пожертвам сигурността за сметка на това, имам само 2 гигабайта памет, както казах '>

[triplek]

Доколкото знам проблема с паметта е само при пойнтърите. Aко масива е динамичен едва ли ще има особена разлика в ползваната памет.

[gat3way]

Става примерно и с long типовете. Като оставим това, .text секцията винаги е по-голяма, нали искате кодът да ви е оптимизиран да ползва 64-битовия instruction set '>

А това дали е динамично-заделен (демек е в heap-а) или не, няма никакво значение, пак си взема еднакво много памет.

И отделно имаш стек, в който се държат адресите на които програмата продължава след RET инструкция, той също ще е до 2 пъти по-голям.

*кхъм* хубавата страна е че математически погледнато няма как същите неща да отнемат повече от 2 пъти повече памет '>

[Nikolavp]

Цитат (triplek @ Сеп. 12 2008,15:12)

Доколкото знам проблема с паметта е само при пойнтърите. Aко масива е динамичен едва ли ще има особена разлика в ползваната памет.

Добави към pointer-ите long, int, char и сега се замисли колко код ползва тези типове(всички?). Това е при положение, че не ползват там stdint(C++ не гарантира, че този header ще го има - само C99) глупостите и прочие '> и не в момента почти не се ползат  '>

[gat3way]

char принципно не е ли 8 битова стойност?

Нямам идея в c++ как стоят нещата де, много съм скаран с ООП езиците '>  В C принципно sizeof(char) е 1, бях много учуден когато sizeof(int) ми излезе 4 на 64-битова платформа, нещо което не мога да си обясня много добре, има очевидно някаква конвенция по въпроса, но тъй като не съм програмист не задълбавам особено в тия неща. Но за long типа и за указателите със сигурност има разлика.

За C++ пак казвам, не знам. Ако е така както казваш, още по-зле за 64-битовите qt приложения например '>


Неее, докато не измислят нещо революционно, което да осмисля 64-битовата архитектура и докато паметта не поевтинее доволно много, никаква x86_64 дистрибуция за десктопа, прогресът да си гледа работата '>

[Nikolavp]

Гарантира се от двата стандарта ако не се лъжа, че char е поне 8 бита, но това не значи, че не може да е по - голям на някои платформи(не на всички платформи един байт е 8бита). За int-a знам, че го има проблема даже четох тази статия по въпроса. Затова и sizeof(char) == 1, но ми е странно колко ти показва CHAR_BIT от <limit.h> - header-a май е от C99

Примерен код

#include <limits.h> #include <stdio.h> int main (int argc, char const* argv[]) {     printf("%d", CHAR_BIT);     return 0; }

P.S. Честит ден на програмиста на всички. Аз не се приемам много, но все пак бира да се лее  '>  '>

[gat3way]

Аз реших че в C++ са решили да правят char по някакъв начин обвързан с unicode и таман щях да излея малко помия по тоя въпрос '> Може да звучи идиотски, но тъй като не му разбирам и наистина не бих се учудил,  не че не звучи глупаво де '>

Иначе вади 8, както се очакваше '>

[Nikolavp]

Цитат (gat3way @ Сеп. 13 2008,00:08)

Аз реших че в C++ са решили да правят char по някакъв начин обвързан с unicode и таман щях да излея малко помия по тоя въпрос '> Може да звучи идиотски, но тъй като не му разбирам и наистина не бих се учудил,  не че не звучи глупаво де '> Иначе вади 8, както се очакваше '>

Ми то комитета не се слави с добрите си решения, но все пак няма как да променим историята и ще трябва да живеем с огромния код написан на езика '>. Аз леко се обърках, понеже съм виждал char32_t и char64_t по код насам натам, а то това са били typedef-и на unsigned и signed char

[triplek]

Примерен код

#include <iostream> using namespace std; int main() {     int i;     long long j;     long long x [100000];     cout << sizeof(i) << ' ' << sizeof(j) << ' ' << sizeof(x) << endl;     return 0; }

При "нормалния" масив грижи няма. Ето при мен изхода под 64 бита убунту:

4 8 800000

/Edit

Примерен код

#include <iostream> #include <stdio.h> using namespace std; int main() {     long long i;     long long* j = &i;     printf("%d",sizeof(j));     return 0; }

Аз не виждам проблем.  '>

[Nikolavp]

Просто си попаднал на такава архитектура и много зависи от компилатора'>  '> До колкото знам gcc ползва LP64 модела

http://en.wikipedia.org/wiki/64-bit#32_vs_64_bit

Цитат

However, in many programming environments on 64-bit machines, "int" variables are still 32 bits wide, but "long"s and pointers are 64 bits wide. These are described as having an LP64 data model. Another alternative is the ILP64 data model in which all three data types are 64 bits wide, and even SILP64 where "short" variables are also 64 bits wide[citation needed]. However, in most cases the modifications required are relatively minor and straightforward, and many well-written programs can simply be recompiled for the new environment without changes. Another alternative is the LLP64 model, which maintains compatibility with 32-bit code by leaving both int and long as 32-bit. "LL" refers to the "long long" type, which is at least 64 bits on all platforms, including 32-bit environments.

Цитат

Many 64-bit compilers today use the LP64 model (including Solaris, AIX, HP, Linux, Mac OS X, FreeBSD, and IBM z/OS native compilers). Microsoft's VC++ compiler uses the LLP64 model. The disadvantage of the LP64 model is that storing a long into an int may overflow. On the other hand, casting a pointer to a long will work. In the LLP model, the reverse is true. These are not problems which affect fully standard-compliant code but code is often written with implicit assumptions about the widths of integer types. Note that a programming model is a choice made on a per-compiler basis, and several can coexist on the same OS. However typically the programming model chosen by the OS API as primary model dominates.

[Gaara]

Много повърхностни сравнения с тези c++ bulshits. Изкривяването на темата с тези LLP64, LP64 и всякакви други гадости е безсмилсено. Факт е, че:
- 64 битова архитектура е препоръчително да ползваш, ако имаш над 4Г рам и искаш наистина да я имаш. В Windows на 32 битова архитектура, ако не се лъжа се засичаше около 3.2Г от 4г.
- 64 архитектура има два пъти повече CPU регистри => два пъти повече информация се обработва, преди да достигне кеша на рамта
- в 64 б.а. SSE и SSE2 са включение в core instruction сета
- затворени приложения е трудно да подкараш на 64 битова машина, но не е невъзможно... все още няма 64 битова версия на така респектиращият Flash плъгин... говори се, че 10-та щяла вече да поддържа 64, но знае ли човек'>... дугият основен проблем е джавата, която има версия за Windows и Соларис, но няма за Linux '>

В общи линии е това... човек трябва сам да избира '>

[Nikolavp]

java-та си работи. Просто аплетите не работят '>. Има разлика между двете, иначе за другото си прав, но тия точки поне на мен не ми докараха особена производителност, а проблемите са на лице.