Cześć. Zainteresowało mnie pewne rozwiązanie wydajnościowe w .Net otóż napisanie biblioteki w języku niższego poziomu np w C++, a następnie dołączenie jej do projektu w .Net. Testował ktoś kiedyś takie rozwiązanie pod względem wydajności? Przyrost wydajności jest znaczny? Gra warta świeczki?
0
4
ciezko sobie wyobrazic aplikacje biznesowa dla ktorej platforma .net bylaby niedostatecznie wydajna, mysle ze takie dylematy wynikaja w 99% z braku zrozumienia jak dziala ta technologia i/lub nieznajomosci rzeczywistych problemow aplikacji.
pracuje przy projekcie ktory ma duze wymagania jesli chodzi o latency/throughput, miewalam roznych dziwnych 'tech leadow' ktorzy zaczynali przepisywac pewne fragmenty aplikacji na c ze sobie znanych powodow, nigdy sie to nie sprawdzilo, albo zysk byl mizerny, albo koszt kombinowania zeby odwolywac sie do natywnego kodu byl niepraktyczny. jedynym przypadkiem gdzie uzywamy natywnego kodu jest generowanie wykresow (i decyduja tu glownie wzgledy historyczne).
jak ci dziala za wolno to pierwsza rzecza ktora robisz powinno byc odpalenie profilera a nie kombinowanie nad zmiana technologii.
napisz jaki masz problem to moze znajdziemy jakies rozwiazanie, pisanie w c/asmie to naprawde ostatecznosc.
0
Hej. Dzięki za podzielenie się doświadczeniem. Nie mam problemu z wydajnością po prostu ciekawi mnie wynik takiego działania czy faktycznie się takie coś stosuje (w jakimś szczególnym przypadku bo przecież takie zawsze występują). Czy wydajność wzrasta znacznie?
1
pewnie gdzies sie stosuje, jednak sie nie spotkalam z uzasadnionym przypadkiem.
wiele lat temu jak c# 2.0 byl nowoscia polecono mi przepisac aplikacje do wsadowego przetwarzania faktur (kilkaset tysiecy w paczce) na c bo za wolno dzialala, efekt byl taki ze kod dzialal te 4-5 razy szybciej. calosciowo ten przyrost nie byl jednak zauwazalny bo 99.99% czasu aplikacja spedzala na czekaniu na wykonanie procedur w bazie danych :)
inny przypadek - mielismy przez chwile natywna biblioteke do obslugi arytmetyki na 128 bitowych intach, po przepisaniu na c# szybkosc obliczen wzrosla o kilka procent (raczej pomijalne roznice).
co te dwa przyklady udawadniaja? ze przede wszystkim trzeba rozumiec w czym lezy problem :) a nie pakowac sie w kosztowne zmiany bez gruntownej analizy
2
Nie do końca się zgodzę z nazywaniem C++ językiem niższego poziomu od C#. C++ jest „wszystkopoziomowy”, taki język do wszystkiego.
Tak, testował - i tak, był znaczny przyrost prędkości po przepisaniu części obliczeniowej z C# na C++ - ale to było rysowanie fraktali, czyli bardziej ciekawostka niż cokolwiek pożytecznego.
Przyrost prędkości wynikał też nie z samego języka, a z faktu użycia instrukcji wektorowych SSE2 pod C++, coś czego w C# nie ma, a przynajmniej wtedy nie było.
Innym uzasadnionym przypadkiem może być istnienie jakiejś gotowej biblioteki natywnej, której z przyczyn technicznych nie da się bezpośrednio użyć w C# lub byłoby to uciążliwe (choć wtedy raczej używa się zarządzanego C++/CLI a nie natywnego C++).
0
Jak najbardziej stosuje się takie podejście w oprogramowaniu gdzie naprawdę są prowadzone "ciężkie" obliczenia wymagające mnóstwa pamięci. Interfejs robi się w C#, a obliczenia w C++/CLI lub tylko wrapper w tym i wtedy część obliczeniowa w czystym C++.
Zresztą nie tylko ze względu na wydajność się wybiera takie rozwiązanie, do C++ są dostępne znacznie lepsze biblioteki numeryczne niż do C#.
0
neves napisał(a):
Jak najbardziej stosuje się takie podejście w oprogramowaniu gdzie naprawdę są prowadzone "ciężkie" obliczenia wymagające mnóstwa pamięci
o czym mowisz konkretnie, ze niby 1GB intow jest wiekszy w c# niz c++ ;)
neves napisał(a):
Interfejs robi się w C#, a obliczenia w C++/CLI lub tylko wrapper w tym i wtedy część obliczeniowa w czystym C++ (...) Zresztą nie tylko ze względu na wydajność się wybiera takie rozwiązanie
piszesz jak by to byla powszechna praktyka, szczerze ciekawi mnie do jakich konkretnie zastosowan i gdzie 'robi sie' i 'wybiera sie' takie rozwiazania (poza miejscami finansowanymi z podatkow i pet projektami)?
0
katelx napisał(a):
neves napisał(a):
Jak najbardziej stosuje się takie podejście w oprogramowaniu gdzie naprawdę są prowadzone "ciężkie" obliczenia wymagające mnóstwa pamięci
o czym mowisz konkretnie, ze niby 1GB intow jest wiekszy w c# niz c++ ;)
Pewnie że tak C# to w końcu zło wcielone, a zło waży więcej, taki tam żarcik :P. Konkretnie miałem na myśli gdy w trakcie algorytmu jest potrzeba operowania na tablicach/macierzach tego rzędu wielkości tyle że setki razy w trakcie trwania algorytmu wtedy GC potrafi dać nieźle w kość.
katelx napisał(a):
neves napisał(a):
Interfejs robi się w C#, a obliczenia w C++/CLI lub tylko wrapper w tym i wtedy część obliczeniowa w czystym C++ (...) Zresztą nie tylko ze względu na wydajność się wybiera takie rozwiązanie
piszesz jak by to byla powszechna praktyka, szczerze ciekawi mnie do jakich konkretnie zastosowan i gdzie 'robi sie' i 'wybiera sie' takie rozwiazania (poza miejscami finansowanymi z podatkow i pet projektami)?
W oprogramowaniu służącym do analizy i symulacji konstrukcji budowlanych, co i tak jest postępem bo większość tego typu oprogramowania powstała zanim pojawił się C# i jest napisana w C/C++.