-
51. Data: 2017-07-10 07:46:07
Temat: Re: Algorytm hex,dec<->liczba
Od: "AK" <n...@n...net>
Użytkownik "M.M." <m...@g...com> napisał:
> > Tyle może pojedynczy programista, wyobraź sobie, co może zrobić
> > zespół 30 osób przez kilka lat.
>
> Heh. Zwykle moze mniej (mowie o polskiej rzeczywistosci.. i..
> mowie to smiertelniue powaznie:(
> Nie wiem co chcesz powiedzieć, ale brzmi to tak, jakby 30 osób mogło
> mniej niż jedna. ;-)
Dokladnie to chcialem rzec. Czesto tak wlasnie bywa.
AK
-
52. Data: 2017-07-10 07:53:06
Temat: Re: Algorytm hex,dec<->liczba
Od: "AK" <n...@n...net>
Użytkownik <s...@g...com> napisał:
> Poza tym ma największe możliwości z pośród dostępnych języków programowania:
Heh. Pisze (głównie!) w C++ produkcyjnie juz ponad 30 lat i stwierdzam
autorytatywnie.
To najgorszy jezyk "wysokiego poziomu" jaki uzywam/uzywalem.
PS: Stara Simula (1967) (pisalem w latach siedemdziesiatych) jest IMHO o wiele lepsza
AK
-
53. Data: 2017-07-10 10:01:20
Temat: Re: Algorytm hex,dec<->liczba
Od: slawek <f...@f...com>
On Sun, 2 Jul 2017 20:12:35 +0200, Borneq <b...@a...hidden.pl>
wrote:
> W jaki sposób z postaci heksadecymalnej otrzymać 128 bitową wartość
(z
> biblioteki boost) a następnie przekonwertować na postać dziesiętną?
> Nie chodzi mi o sztuczki maksymalizujące prędkość a o pewność
> dokładności konwersji.
> Czy z postaci tekstowej na liczbę - mnożymy przez 10 lub 16, a
odwrotnie
> dzielimy?
Czego dziś uczą w szkołach? Ja takie konwersje robiłem w pamięci w
trzeciej klasie podstawówki...
Ale do rzeczy. Cyfrę hex jako znak minus '0' do półbajtu (znaczy się
kwartetu). Bajty w tablicę rzutowaną na int. Można użyć uni. Fajny
patent to lookup dla dwóch znaków na raz.
Porządnie to robiąc trzeba sprawdzić czy cyfra nie była np. @, ile
jest cyfr hex i czy mieści się to w int.
Ale.. takie konwersje są zwykle już. Na przykład iostream ma w C++ i
nie tylko.
-
54. Data: 2017-07-10 10:12:19
Temat: Re: Algorytm hex,dec<->liczba
Od: slawek <f...@f...com>
On Thu, 6 Jul 2017 11:06:16 -0700 (PDT), s...@g...com wrote:
> w murzyna (jak by np. wyszło, że głównie
Jak to było w dowcipie o białym rasiście-mizogonie?
Więc z tą karmą (dla kotów?) to nie strasz.
Zwłaszcza że seks i taniec są w porzo. No chyba nie chcesz awansować
na bakterię w kolejnym wcieleniu i zginąć od Domestosa?
-
55. Data: 2017-07-10 10:23:10
Temat: Re: Algorytm hex,dec<->liczba
Od: slawek <f...@f...com>
On Fri, 7 Jul 2017 01:32:41 +0200, "AK" <n...@n...net> wrote:
> Trzeba miec umysl i morale (idee), a nie kibel zamiast glowy.
Może kiedyś będziesz miał...
-
56. Data: 2017-07-10 10:38:08
Temat: Re: Algorytm hex,dec<->liczba
Od: slawek <f...@f...com>
On Sun, 9 Jul 2017 04:16:22 -0700 (PDT), s...@g...com wrote:
> W porównaniu do Java i C# jest kompilowany do kodu maszynowego a
nie d=
> o wirtualnej maszyny. Przez co działa z pełną prędko?=
> ?cią sprzętu na którym jest uruchamiany.
No to mędrku wpisz w Google JIT compilation.
-
57. Data: 2017-07-10 13:55:13
Temat: Re: Algorytm hex,dec<->liczba
Od: "M.M." <m...@g...com>
On Monday, July 10, 2017 at 7:46:23 AM UTC+2, AK wrote:
> Użytkownik "M.M." <m...@g...com> napisał:
>
> > > Tyle może pojedynczy programista, wyobraź sobie, co może zrobić
> > > zespół 30 osób przez kilka lat.
> >
> > Heh. Zwykle moze mniej (mowie o polskiej rzeczywistosci.. i..
> > mowie to smiertelniue powaznie:(
>
> > Nie wiem co chcesz powiedzieć, ale brzmi to tak, jakby 30 osób mogło
> > mniej niż jedna. ;-)
>
> Dokladnie to chcialem rzec. Czesto tak wlasnie bywa.
>
> AK
Rozwiń proszę.
Pozdrawiam
-
58. Data: 2017-07-10 16:22:50
Temat: Re: Algorytm hex,dec<->liczba
Od: s...@g...com
> > W porównaniu do Java i C# jest kompilowany do kodu maszynowego a
> nie d=
> > o wirtualnej maszyny. Przez co działa z pełną prędko?=
> > ?cią sprzętu na którym jest uruchamiany.
>
> No to mędrku wpisz w Google JIT compilation.
Wiem co to jest, tyle, że to nie są normalne programy bo wymagają maszyn wirtualnych.
JIT to i tak nie są tak szybkie jak kod generowany przez kompilator C++. A C, C++ i D
to normalne języki produkujące samodzielne exe i dll. Styl też się liczy! Bo jeśli
miałbym do czegoś porównać Java czy C# to chyba jedynie do sztucznej ręki albo
sztucznej nogi...
-
59. Data: 2017-07-10 16:51:10
Temat: Re: Algorytm hex,dec<->liczba
Od: "M.M." <m...@g...com>
On Monday, July 10, 2017 at 4:22:52 PM UTC+2, s...@g...com wrote:
> > > W porównaniu do Java i C# jest kompilowany do kodu maszynowego a
> > nie d=
> > > o wirtualnej maszyny. Przez co działa z pełną prędko?=
> > > ?cią sprzętu na którym jest uruchamiany.
> >
> > No to mędrku wpisz w Google JIT compilation.
>
> Wiem co to jest, tyle, że to nie są normalne programy bo wymagają maszyn
wirtualnych. JIT to i tak nie są tak szybkie jak kod generowany przez kompilator C++.
A C, C++ i D to normalne języki produkujące samodzielne exe i dll. Styl też się
liczy! Bo jeśli miałbym do czegoś porównać Java czy C# to chyba jedynie do sztucznej
ręki albo sztucznej nogi...
Efektywność kodu generowanego przez JIT zależy generalnie od jakości
JITa. Tak samo jak efektywność kodu maszynowego zależy od
optymalizatora. Generalnie też zgadzam się, że kiedyś (i pewnie
nadal) kod generowany przez JITy dla kodu bajtowego Javy był
mniej efektywny pod kątem czasu wykonania od kodu generowanego przez
optymalizatory zamieszczane w kompilatorach języków C++. To tak
generalnie, szczegółowo sprawa jest głębsza i z użycia kodu
pośredniego dla JITa wiąże się szereg zalet i wad, nie tylko
związanych z efektywnością generowanego kodu.
Po pierwsze, JIT dla kodu pośredniego może zrobić to co robi PGO,
czyli może zebrać statystyki i wygenerować kod maszynowy z uwzględnieniem
tychże statystyk. Jeśli użytkownik używa w bardzo niestandardowy
sposób danego oprogramowania, to JIT przynajmniej teoretycznie,
powinien generować bardziej efektywny kod.
Po drugie, JIT może optymalizować pod daną platformę sprzętową, więc
znowu teoretycznie JIT może wygenerować lepszy kod.
Po trzecie, optymalizowanie kodu jest problemem bardzo trudnym. Wniosek
z tego taki, że wszelkie próby bardziej zaawansowanej optymalizacji
najpierw zmuszą użytkownika do oczekiwania na wynik tejże optymalizacji,
żeby potem przy każdym użyciu zyskiwał trochę czasu. W przypadku gdy
od razu kompilujemy do kodu maszynowego, możemy (teoretycznie) włączyć
jakiś optymalizujący program na tydzień i rozdać gotowy-zoptymalizowany
kod ostatecznym użytkownikom.
Po czwarte, JIT (teoretycznie) może zapisywać gdzieś na jakimś serwerze
częściowe wyniki optymalizacji, a inni mogą korzystać z gotowców.
Po piątek, programy napisane w językach kompilowanych bez kodu
pośredniego można rozprowadzać z otwartym źródłem, więc każdy użytkownik
teoretycznie może sobie skompilować i zoptymalizować u siebie na
swój sprzęt i każdy może włączyć PGO na swój przypadek użycia.
W Javie kijowe jest to, że TRZEBA użytkownikowi dać kod bajtowy, który
(podobno nawet obfuskany) łatwo zamienia się do kodu źródłowego
Javy. W przypadku C++ to my decydujemy, czy dać że źródłem, czy tylko
kod wynikowy. Gdy dajemy ze źródłem, to (teoretycznie) wychodzi na to
samo co w przypadku JITa.
Pozdrawiam
-
60. Data: 2017-07-10 17:44:27
Temat: Re: Algorytm hex,dec<->liczba
Od: "AK" <n...@n...net>
Użytkownik "slawek" <f...@f...com> napisał:
> On Fri, 7 Jul 2017 01:32:41 +0200, "AK" <n...@n...net> wrote:
>> Trzeba miec umysl i morale (idee), a nie kibel zamiast glowy.
>
> Może kiedyś będziesz miał...
Ok. Rozumiem. Wiesz to z autopsji.
AK