W dniu 2012-06-12 13:49, Adam Wysocki pisze:
> AK<n...@n...com> wrote:
>
>> Nikt przy zdrowych zmyslach nie tworzy/nie projektuje dzis (a raczej
>> nie powinien) nowego softu w C++.
>
> Masz bardzo ograniczone pojęcie na temat systemów osadzonych.

Mi się to pojęcie z upływem czasu zmienia. Kiedyś pukałem się w czoło,
jak ktoś mi mówił, że w C można na tym pisać. Dzisiaj masz Linuxa w
aparacie fotograficznym i pojawiają się takie wynalazki, jak .net micro
framework. To kwestia czasu.

artur

do góry

Dnia Tue, 12 Jun 2012 19:39:29 +0200, Artur Muszyński napisal:

> W dniu 2012-06-12 14:36, Roman W pisze:
>> On Tuesday, June 12, 2012 1:15:48 PM UTC+1, AK wrote:
>>
>>> Wcale niekoniecznie.
>>> "Szybka reakcja gieldowa" wcale nie zalezy tak bardzo wylacznie od
>>> jezyka.
>>
>> Krotkie pytanie: mozesz zaprogramowac GPU uzywajac Javy/C#?
>
> Jestem w stanie to sobie wyobrazić:
>
> http://ananthonline.net/brahma/

Wystarczy język, który ma generator nie tylko assemblera ale i PTX
oraz obsługę drivera - w przypadku CUDA. Dzisiaj działających nie ma
za wiele, w przypadku CUDA wybór praktycznie ogranicza się do CUDA,
czyli okrojonego C++ z kilkoma dodatkami.

Edek

do góry

Użytkownik "Artur Muszyński" <a...@u...wytnijto.com.pl> napisał:

> Dzisiaj masz Linuxa w aparacie fotograficznym i pojawiają się takie wynalazki,
> jak .net micro framework. To kwestia czasu.

Swieta prawde mowisz. Kwestia dosc krotkiego czasu.

PS: Calkiem na boku. Taki z pozoru calkiem nieznaczacy szczegol.
Java me jre i osobno jsdk. O C++ juz nie wspomne.
A .NET ma jednak od razu cs.exe.
No i refleksje IMHO lepsza niz JVM.
Wiem wiem. Niby nic, ale...

AK

do góry

g...@s...invalid (Adam Wysocki) napisał(a):

> AK <n...@n...com> wrote:
>
> > Jasne ze nie. Ludzie ktorzy uzywaja C++, swiadomie uzywaja tego jezyka
> > dlatego ze _niezle za ujarzmienie tego syfu placa_!.
>
> Kiepski argument, lepiej płacą za ujarzmienie Javy.
>
> Wybierając język do stworzenia od zera dużej aplikacji na popularną
platformę
> osadzoną miałem do wyboru C albo C++. Wybrałbyś C?
>
> > Nie kazdy sie do tej stajni Augiasza nadaje. Trzeba miec owszem pewne
> > umiejetnosci merytoryczne - ale _glownie_ pewne cechy charakteru aby
> > tej "nowoczesnosci" z krzyzykami podolac bez uszczerbku dla "jestestwa".
>
> Bez przesady, to język jak język. Wszystkiego da się nauczyć, a C++ nie
> jest jakoś wyjątkowo trudny.
>
> > Przyklad negatywny: fir - dalbys sobie spokoj z C/C++ bo wpierw
> > zejdziesz z tego swiata zanim "dopasujesz" C/C++ do swej osobowosci.
>
> Fir to w ogóle negatywny przykład programisty. Ja go widzę dziergającego
> coś w assemblerze, żeby uciec od problemów w życiu, z którymi sobie nie
> radzi, ale zarabiał na programowaniu, ani pracował zespołowo, raczej
> nigdy nie będzie.
>
> > umie nie zwalac swych problemow na wlasne nniedoskonalosci bo w przypadku
> > C++ _to jezyk jest winny_ !
>
> A konkretnie, co w C++ jest winne czemukolwiek? Trzeba po prostu znać mocne
> i słabe strony języka i umieć rozwiązać w nim problem.
>

coś mi sie zdaje że mój mz bardzo glupi i maksymalnie mnie
zbrzydzający przedpiśca zamiaruje zarzucać mnie swoją głupota
gdzies tak do nieskończoności, jest to ciekawy przyklad
czlowieka ktory wg mnie nigdy nie poweidzial nic co nie bylo
w obrzydzajacy sposob glupie (przynajmniej nie pamietam takiej
wypowiedzi a bardzo zaluje ze przez pomylke przeczytaem
kilka ;-)





--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

On 12 Cze, 16:07, "AK" <n...@n...com> wrote:
> A dlaczego by nie ? Ze niby "klasyczny" C++ szybszy/mniejszy znacznie ?
> PS: W dzisiejszych czasach wiara, że "klasycznie kompilowany" C++
> bedzie wyraznie szybszy od podejscia CLI/jbytecode/innego "kodu posredniego"
> jest przejawem nie tylko "wiedzy niedzielnej", ale wrecz wstecznictwa i braku
> nawet "krotkotrwalej" wyobrazni.

Java/C# mogą być tak samo szybkie jak C++ jeżeli program w C++
napisany jest w stylu Javy/C# ( co zresztą udowadniają liczne
benchmarki będące bezmyślną translacją jednego języka na drugi). Ja
już parę razy pisałem: szybkość działania JVM/.Net jest dla mnie
akceptowalna. Problemem jest dla mnie zużycie pamięci w tych
środowiskach ( w .Net może być mniejsze dzięki dobrej implementacji
generyków i dostępnych typów wartości ). I można sobie różne bajki
opowiadać, ale w C/C++ zawsze mam jakąś możliwość optymalizacji, np.
zmniejszenie rozmiaru obiektów przez pakowanie ich pól na bitach +
użycie indeksów do innych obiektów , bo przechowywanie wskaźnika na
64bitach jest kosztowne. A że tych obiektów było bardzo dużo ilość
zajmowanej pamięci spadła o 40%.
Zresztą zobacz co powiedział nie byle kto, bo autor F# na temat C++:
http://blog.achrissmith.com/2012/03/if-your-software
-matters-you-will-write.html

I i jeszcze, ponieważ zaraz usłyszę, że jestem wstecznych ayatollahem C
++. Chętnie powitałbym coś innego. Bez chorego systemu templejtów, z
lepszym postawieniem na bezpieczeństwo, z algebraicznymi typami
danych. Ale nie ma i prędko nie będzie.
Kibicuję językowi Rust ( http://www.rust-lang.org/ ) i Clay (http://
claylabs.com/clay/) ale obawiam się że skończy się to jak zawsze.

Pozdrawiam
KK

do góry

Użytkownik "Krzysiek Kowaliczek" <k...@g...com> napisał:

> I i jeszcze, ponieważ zaraz usłyszę, że jestem wstecznych ayatollahem C++.

Alez ja lubie bardzo niektorych "Ayatollahow C++" ;)
Niektorym (szczerze!) dużo zawodowo zawdzieczam.
Np. obecny długie lata na pl.comp.lang.c Wojtek Surówka
którego "tępiłem" i "wk..łem" (ale do którego zawsze czułem zawodowy
szacunek jak do każdego prawdziwego profesjonalisty), a który mnie mimo to
przyjął do pracy :) i o dobre siedem lat skrócił mi czas do utęsknionej emerytury
(a będzie to hojność Państwa w kwocie ok 1700 "na rekę" :)
i umożliwił pracę w bardzo porządnej firmie (z której to pracy dużo wyniosłem).

Twoja odpowiedz swiadczy, (tak mi nos mowi) ze nalezysz wlasnie do tego
typu Ayatollahow ;)
PS: Wroce do niej, ale dopiero jutro. Sorry. Brak teraz czasu na glebsza odpowoiedz.

Pozdrawiam

AK

do góry

AK <n...@n...com> napisał(a):

> Użytkownik "Andrzej Jarzabek" <a...@g...com> napisał:
>
> > a w dotnecie przecież tego nie robi.
>
> A dlaczego by nie ? Ze niby "klasyczny" C++ szybszy/mniejszy znacznie ?
> PS: W dzisiejszych czasach wiara, że "klasycznie kompilowany" C++
> bedzie wyraznie szybszy od podejscia CLI/jbytecode/innego "kodu posredniego"
> jest przejawem nie tylko "wiedzy niedzielnej", ale wrecz wstecznictwa i
braku
> nawet "krotkotrwalej" wyobrazni.
>
> PS: Zapomniane rozwiazania rodzaju Transmeta czy PicoJava wroca (oczywiscie
> niekoniecznie w dotychczasowej postaci).
> Jest juz na nie czas i miejsca mnostwo. Nawet Ayatollahy C++ nie
przeszko
> dza :).
>
> AK
>

mozna by zrobic jakis test, tyle ze ktos musialby to wymyslec,
tylko zeby nie mierzylo wydajnosci bibliotek tylko przetwarzania
w jezyku, ten sam defakto kod odpalony w c# i w c (troche mi sie
ostatnio nie chce programowac ale ew moglbym przetestowac cos prostego)



--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

On Tuesday, June 12, 2012 2:26:01 PM UTC+1, Andrzej Jarzabek wrote:
> On Jun 12, 1:47 pm, Roman W <b...@g...pl> wrote:
> >
> > JP Morgan w Londynie zbudowal sobie wlasny superkomputer do obliczen CVA.
> [...]
>
> Nie no, wiem, że czasem się rzeźbi własny hardware - nawet w mniej
> ekstremalnych sytuacjach.
> Ale chyba nie muszę ci mówić, że poza oczywistym problemem kosztów
> jest jeszcze tak, że wiele z tych wysoko-wydajnych programów trzeba do
> tego regularnie apgrejdować lub wymieniać, co jest nieco trudnijesze,
> jeśli odpowiednią funkcjonalność zhardkodujesz w krzemie.

Slyszalem, ze UBS tak robi -- jak juz doklepia model, to koduja go w FPGA.

RW

do góry

On Tuesday, June 12, 2012 3:07:49 PM UTC+1, AK wrote:
> Użytkownik "Andrzej Jarzabek" <a...@g...com> napisał:
>
> > a w dotnecie przecież tego nie robi.
>
> A dlaczego by nie ? Ze niby "klasyczny" C++ szybszy/mniejszy znacznie ?
> PS: W dzisiejszych czasach wiara, że "klasycznie kompilowany" C++
> bedzie wyraznie szybszy od podejscia CLI/jbytecode/innego "kodu posredniego"
> jest przejawem nie tylko "wiedzy niedzielnej", ale wrecz wstecznictwa i braku
> nawet "krotkotrwalej" wyobrazni.

W moim przypadku to jest po prostu stwierdzenie faktu. Ten sam algorytm (model do
wyceny CDO) napisany w Javie i w C++. Kod C++ jest oczywiscie kilkakrotnie szybszy.


RW

do góry

On Tuesday, June 12, 2012 6:39:29 PM UTC+1, Artur Muszyński wrote:
> W dniu 2012-06-12 14:36, Roman W pisze:
> > On Tuesday, June 12, 2012 1:15:48 PM UTC+1, AK wrote:
> >
> >> Wcale niekoniecznie.
> >> "Szybka reakcja gieldowa" wcale nie zalezy tak bardzo wylacznie od jezyka.
> >
> > Krotkie pytanie: mozesz zaprogramowac GPU uzywajac Javy/C#?
>
> Jestem w stanie to sobie wyobrazić:
>
> http://ananthonline.net/brahma/

Rozmawialem niedawno z ludzmi ktorzy przeniesli zaawansowany model do wyceny opcji na
GPU, uzyskujac przyspieszenie rzedu 300x. Stwierdzili ze najtrudniejsza czescia
projektu bylo

a) przekonanie dzialu IT do zainstalowania GPU
b) zarzadzanie przeplywem danych do pamieci GPU.

Uzyskanie znaczacego przyrostuy wydajnosci wymaga starannego tuningowania kodu.
Dlatego jestem sceptyczny, czy kiedykolwiek ludzie ktorym zalezy na wydajnosci na
tyle, zeby bawic sie w deployment GPU, ograniczyli sie do bibliotek typu Brahma, i
nie brali spraw "we wlasne rece". Ale moze sie myle.

RW

do góry