Rozważania na temat ilości bitów w programach.

[perlon]

W dzisiejszych czasach odpalanie ( nawet niejawne )  podsystemu do obsługi aplikacji x86 na maszynach x64 to czyste marnotrawstwo zasobów. Nie bardzo wiem, dlaczego ZwSOFT ignoruje istnienie 64bitowych systemów operacyjnych.

[pawmal]

Witam

Myślę, że wcześniej czy później będzie konieczność wprowadzenia wersji 64 bitowych.

Pozdrawiam

[dmatusz3]

Witam,

 

ten temat dotyczy, a w zasadzie dotyczył skrótów klawiaturowych.

 

1. Proszę więc nie dodawać zupełnie innych wątków, tym bardziej że to samo jest wpisane już w kilku miejscach.

2. Wersji 64bit wymaga, aby cały program był w UNICODE. To właśnie nastąpiło wraz z wersję 2015, więc mam nadzieję, że wkrótce się ukaże się wersja 64-bit.

 

[...] obsługi aplikacji x86 na maszynach x64 to czyste marnotrawstwo zasobów. [...]

 

Dosyć ciekawa informacja, nie spotkałem się wcześniej z taką tezą.

Co się marnuje?

:)

 

Pozdrawiam

[perlon]

Odpala się maszyna wirtualna 32bit podobnie jak to ma miejsce w windows 32bit gdzie uruchamia się maszyna wirtualna 16bit dla takich aplikacji. Ponieważ  x64 są pozbawione maszyny wirtualnej 16bit nie można na nich uruchamiać aplikacji 16bitowych. Więc marnotrawstwem zasobów jest odpalanie programów do odpalania innych programów.

[dmatusz3]

Odpala się maszyna wirtualna 32bit podobnie jak to ma miejsce w windows 32bit gdzie uruchamia się maszyna wirtualna 16bit dla takich aplikacji. Ponieważ  x64 są pozbawione maszyny wirtualnej 16bit nie można na nich uruchamiać aplikacji 16bitowych. Więc marnotrawstwem zasobów jest odpalanie programów do odpalania innych programów.

 

Hmm. Czasy się zmieniają.

 

Obecnie pojemności cache procesora są większe niż pojemność starych dysków twardych, które z sentymentu trzymam w szafie. 

Teraz w modzie są systemy 64 bit. Z jednej strony jest to moda, ale z drugiej konieczność.

 

Bardziej wymagające programy CAD, do obliczeń MES, renderingu wymagają gigabajtów pamięci, a jak pamiętamy limit pamięci dla systemów 32 bitowych to trochę ponad 3 GB ram.    

 

Jeśli ktoś decyduje się na system 64 bit, to wybiera minimum 8GB ram, a 16GB jest standardem. 

I to jest zasadniczo największa korzyść z 64 bitów, pomijając w pewnych warunkach kilkuprocentowy wzrost prędkości.    

 

Standardem także są dzisiaj procesory wielordzeniowe.    

 

Jak by więc nie popatrzeć mamy więc spory zapas zasobów systemowych.

Czy wobec tego (załóżmy czasowo, że jest to marnotrawstwo) trzeba się martwić maszyną wirtualną?

 

Według mnie największym zmartwieniem może być tylko wielkość obsługiwanej pamięci przez programy 32 bitowe. 

 

Ale z tego co wiem Martin_S jest pierwszym, któremu "brakło bitów". Ale tylko z tego powodu, że zamienia jedną powierzchnie na kilka tysięcy mniejszych (proszę o wyprostowanie jeśli się mylę, lub bluźnierczo spłyciłem problem  :D ).

 

Wróćmy teraz do problemu maszyn wirtualnych.    

 

Obecnie programy piszę się w innych programach.    

 

JAVA (która jest uznawana za nowoczesny język programowania) pracuje na ponad 3 miliardach urządzeń.

 

Programiści piszą program, który jest następnie kompilowany do kodu pośredniego, który może być uruchomiony na dowolnej platformie obsługującej JAVE.

Bo tak naprawdę wtyczka JAVY odpala maszynę wirtualną, która odpala pośredni kod.    

Tracimy na obsłudze maszyny wirtualnej, ale zyskujemy przenośność programu. 

 

No tak, ale zostawmy JAVE (niektórzy nie lubią jej za codzienne aktualizację  :D ) 

 

Natomiast sam producent Windows od prawie 10 lat rozwija, przechodzi, promuje platformę  .NET. 

 

Znowu pójdę na łatwiznę, ale filozofia jest podobna do JAVY.  Piszemy program (nawet w notatniku) i kompilujemy go.

Aby go jednak uruchomić potrzebne jest środowisko do uruchomienia - NET FRAMEWORK.    

I jest to pewien rodzaj maszyny wirtualnej.  W systemie LINUX odpowiednikiem jest MONO, które mimo, że nie jest wspierane oficjalne przez MicroSoft, ale znaczna ilość programów napisana pod Windows będzie działać na Linuksie. 

 

Tak więc, jeśli program korzysta z tego środowiska to niezależnie czy będzie to program 32 bit, czy 64 bit, i tak odpali się maszyna wirtualna - środowisko uruchomieniowe.    

 

Zakładamy jednak, że piszemy program bez .NET. Poprawnie napisany program będzie działał natywnie zarówno na systemie 32bit i 64 bit. 

Bo najważniejszy problemem jest nie plik exe, ale obsługa bibliotek  .dll.

Programy 32bit nie widzą bibliotek 64bit i vice versa.    

Między innymi dlatego sterowniki 32bit nie działają na 64bit. Problemem są także programy antywirusowe.    

Windows 64 bit używa dwóch katalogów do przechowywania bibliotek - jeden do wersji 32 bit, a drugi do 64 bit.    

Jeśli tylko program 32 bit potrafi znaleźć własne biblioteki to wszystko jest OK. 

Problemem są jednak stare aplikacje, które nie mogą znaleźć tych bibliotek ale wtedy przeważnie na bardziej wypasionych Windows (Pro, Ultimate) można odpalić maszynę wirtualną, przydzielić własną pamięć, a maszyna odpowiednio oszuka program tak, aby jednak znalazł te biblioteki.    

 

ZWCAD+ używa NET FRAMEWORK, więc niezależnie czy 32 bit, czy 64 bit, coś więcej się uruchomi.    

 

Środowisko .NET staje się coraz bardziej popularne.

Dużym jego atutem jest to, że możemy pisać różnych jeżykach programowania - Visual Basic, Delphi, C#. Nie trzeba się uczyć nowego języka.    

 

ZWCAD+ od wersji 2014 potrafi także uruchomić nakładki opracowane w środowisku .NET poleceniem  netload.    

 

Opracowaliśmy jakiś czas temu kurs LISP, obecnie przygotowujemy się do rozpoczęcia kursu C# ze szczególnym uwzględnieniem CAD.

 

Tak więc niezależnie, czy 32 bit czy 64 bit, to każdy bardziej rozbudowany program wymaga platformy NET FRAMEWORK.

 

Pozdrawiam

[perlon]

Dziękuję za krótki acz pouczający wywód. Można by z niego wywnioskować że zwcadowi  używającemu .NET w zasadzie ganc pomada na czym się odpala bo patrzy tylko czy ma .NET'a i jak ma to ok. Dogadywanie się z systemem operacyjnym, obsługę zasobów, pamięć etc pozostawia pośrednikowi ( bibliotece .NET ). Kod pisany w dowolnym języku zgodnym z .NET jest tłumaczony do CIL (Common Intermediate Language) a dalej uruchamiany w środowisku uruchomieniowym. OK koszt standaryzacji i przenoszalności kodu. Ale jednak koszt. Tym bardziej "uzyskanie" wersji 64bit nie powinno nastręczać problemów, a jak na razie nie widać. Co do kursu C# z uwzględnieniem CAD'ów no to byłoby COŚ !!! Jestem bardzo zainteresowany. Kiedy planowany początek? No i sory za off-top. Może by ten fragment dyskusji przenieść do jakiegoś hyde-parku?

[dmatusz3]

Myślę, że z kursem zaczniemy po opublikowaniu kilka artykułów o budowie sieci prywatnych (bezpiecznym udostępnianiu danych i licencji przez internet) oraz o budowie własnej chmury.

Znaczną część materiałów do powyższego mam już przygotowaną.

 

Myślę, że z kursem programowania zaczniemy za około 2 miesiące.

 

Jeszcze małe sprostowanie, cały ZWCAD+ nie jest napisany w .NET, ale wykorzystuje tylko pewne elementy. Znacznie więcej tego środowiska wykorzystanego jest jednak w Mechanicalu.

[Martin_S]

 

Ale z tego co wiem Martin_S jest pierwszym, któremu "brakło bitów". Ale tylko z tego powodu, że zamienia jedną powierzchnie na kilka tysięcy mniejszych (proszę o wyprostowanie jeśli się mylę, lub bluźnierczo spłyciłem problem  :D ).

 

 

 

 

Ten problem wyszedł podczas szukania rozwiązania i obejścia tego nad czym Dział Rozwoju obecnie pracuje, mniemam że tak jest (AcDbSubDMesh Class). Obecnie

żadna wersja ZWCAD lub ZW3D  tego nie obsługuje jak powinno. Jaki zysk jest, a no taki że modele 3D o zakrzywionych powierzchniach są bardzo ekonomiczne

i nie obciążają pliku DWG bo są ok. ~10x mniej pojemne, jakość łączeń elementów skończonych jest płynna (w locie matematycznie obliczana, nie znam sie na tym).

Natomiast po konwersji z wykorzystaniem rozszerzenia COLLADA *.dae idzie ten system obrazowania powierzchni "obejść" uzyskując modele powierzchniowe

z różnym, ale narzuconym stopniem zagęszczenia siatek w postaci poligonowej. Taki zespół trójkatów. prostokatów nigdy nie odda płynnych "nurbiastych" przejść. Traci sie kolosalnie

na jakości modelu 3D i na objętości pliku DWG, czego efektem było wielokrotne "crash"-owanie ZWCADa bo nie wyrabiał. Stąd wczorajsze zagadnienie i pytanie

o 64bit, bo 16GBRAM mam. Badając takie rzeczy podczas tworzenia i budowania bibliotek 3D DWG z przeznaczeniem późniejszym do renderingu często|

idzie się "sparzyć", takim doświadczeniem się tu na forum dzielę, jak ktoś skorzysta to fajnie, a jak nie, to mi sie to przydaje i tak. Wiele funkcjonalności najbardziej pilnych staram sie poruszyć,

ale po ponad 1,5roku nie ma większego zaangażowania ogólnie na całym świecie by na forach (ang, fra, pol) wywrzeć presje na ZWSOFT.

 

Cierpliwie czekamy na szybszą innowacyjność :)

Edytowane 17 Października 2014 przez Martin_S

[perlon]

No to wracając w pobliże tematu wątku uważam, że byłoby lepiej skupiać się na potrzebach strzelę 90% użytkowników którzy nie renderują tylko używają ZwCAD'a jako zwykłego draftera - bazy nakładek branżowych. Wygodnego w pracy 2D i 3D w stricte technicznym znaczeniu. Forsowanie na siłę BIM'a czy zaawansowane renderingi zostawiłbym innym produktom albo gdy ZwCAD będzie wszystkomający.

I jeszcze pytanie w temacie kursu C#. Czy żeby programować coś na platformę ZwCAD'a będzie potrzebna jakaś specjalna wersja ZwCAD'a, czy może jakiś pakiet SDK czy coś w tym stylu. W przypadku wersji 2012 trzeba było mieć jakąś specjalną wersję tylko dla rejestrowanych gdzieś tam użytkowników etc i VS2008 . Jakie są obecne wymagania  Czy wersja Express wystarczy? Która wersja rocznikowo?

Edytowane 17 Października 2014 przez perlon

[dmatusz3]

Do kursu kompletujemy jeszcze dokumentację.

Normalnie aby napisać cokolwiek do środowiska .net wystarczy notatnik, oraz .net framework, który normalnie służy do uruchamiania programów.

Po odpowiedniej konfiguracji ścieżek można skompilować program z samej linii poleceń np.:

1. Tworzymy w notatniku kod w języku C#.
2. Zapisujemy w formacie cs, np. witaj.cs
3. Kompilujemy program np. csc witaj.cs
4. Zostanie wyprodukowany plik o nazwie witaj.exe

Oczywiście to prehistoryczna metoda, wersja Express wydaje się być zupełnie wystarczająca, np.

http://www.visualstudio.com/downloads/download-visual-studio-vs#DownloadFamilies_4

 

Lepiej wersję 2010 ponieważ 2013 jest przeznaczona na Win 8.

 

Wydaje się, że SDK nie będzie potrzebne, ale potrzebna będzie znajomość funkcji - jak je wywołać, oraz użyć.

Ale to będziemy starali się opisywać.