Java a boty

[Golumiusz]

Siema,

 

Mam takie proste pytanko: jak java sprawuje się jeśli chodzi o boty? Da się coś sensownego w niej naskrobać? Tu też jest coś w stylu HttpWebRequest  ? Zainteresowało mnie to, bo gdzieś zobaczyłem że jest chyba nawet specjalna klasa "robot" tak?

[GotoFinal]

­Sprawuje się jak każdy inny język, API od połączeń HTTP też jest

http://docs.oracle.com/javase/7/docs/api/java/awt/Robot.html

 

A wracając do połączeń, masz nawet przykład:

http://www.mkyong.com/java/how-to-send-http-request-getpost-in-java/

[Polish Civil]

­Robot robotem, o jakie boty ci chodzi dokladnie.

Botem mozna tez nazwac to http://www.mpcforum.pl/topic/1356863-osrs-instrumentation-bot-bogdan-bot/

 

Jesli ci chodzi o np gry przegladarkowe eg. Plemiona to masz pierdylion bibliotek np: https://hc.apache.org/

[Golumiusz]

To teraz tylko liczyć że Java wygra .

[anakonda119]

Zależy od bota

Jak znasz tylko Jave to nie zabraniam pisać w niej.

Ale języki bardziej zbliżone do sprzętu sprawują się jeszcze lepiej, C++ lepszy C lepszy Assembly, ale Java wystarczy.

[Jaca777]

Ale języki bardziej zbliżone do sprzętu sprawują się jeszcze lepiej, C++ lepszy C lepszy Assembly, ale Java wystarczy.

Nie. W ASM na pewno nie będzie Ci łatwiej napisać bota niż w C++. Nie będzie się też lepiej sprawował.

 

@anakonda119 - Zależy co się rozumie przez "sprawować się lepiej", bo moim zdaniem, w przypadku języka, to jest dużo rozleglejszy termin niż ilość zbędnych instrukcji po kompilacji. A Twoja wypowiedź dla mnie brzmiała jak zachęcenie do pisania botów w asm. Jeśli źle zrozumiałem - przepraszam.

 

 

Ale takich błędów kompilacyjnych jest więcej więc nawet jeżeli chodzi o niewielką różnice to Assembly wygrywa.

Zakładając że będziesz zawsze pisał wydajny kod - musisz pamiętać o tym, że kompilator go w pewnym stopniu optymalizuje.

[anakonda119]

Oj będzie, operowanie na sprzęcie jest o wiele lepsze od operowania na zbiorach komend,

to prawda że pisze się w nim dłużej ale jeżeli znasz się na Assembly (Assembly a nie Assembler) to zapraszam do sprawdzenia kompilowanego kodu pod względem chociaż duplikatów.

 

W samym programie Hello World znalazłem odcinek kodu który był wykonywany podwójnie

Bo po utworzeniu zmiennej String jej adres został wrzucony na Stos a potem został wrzucony jeszcze raz ponieważ funkcja std:cout potrzebuje na stosie adresu do Formatu więc Assembly wygrał

Bo bez sensu jest wrzucać 2x ten sam adres na stos.

 

Może pojedynczy duplikat to nie wielka różnica bo nawet 100 zmiennych = 100 adresów po 1 bajt = 100 bajtów x2 = 100 bajtów nie potrzebne.

Ale takich błędów kompilacyjnych jest więcej więc nawet jeżeli chodzi o niewielką różnice to Assembly wygrywa.

 

A ja nic nie pisałem o łatwości pisanie tylko o językach które moim zdaniem są lepsze pod względem szybkości.

[mirraseq]

Oj będzie, operowanie na sprzęcie jest o wiele lepsze od operowania na zbiorach komend,

W DOSie piszesz, że operujesz bezpośrednio na sprzęcie? Czy do każdego bota piszesz sterownik?

 

W samym programie Hello World znalazłem odcinek kodu który był wykonywany podwójnie

Bo po utworzeniu zmiennej String jej adres został wrzucony na Stos a potem został wrzucony jeszcze raz ponieważ funkcja std:cout potrzebuje na stosie adresu do Formatu więc Assembly wygrał

Bo bez sensu jest wrzucać 2x ten sam adres na stos.

Skoro funkcja tego wymaga, to nie ma tu niczego bez sensu. Poza tym kompilator jest wyposażony w możliwość optymalizacji kodu wynikowego i potrafi zrobić to lepiej niż człowiek.

 

Może pojedynczy duplikat to nie wielka różnica bo nawet 100 zmiennych = 100 adresów po 1 bajt = 100 bajtów x2 = 100 bajtów nie potrzebne.

Ale takich błędów kompilacyjnych jest więcej więc nawet jeżeli chodzi o niewielką różnice to Assembly wygrywa.

Adresy po 1 bajt o_O Jakiego Ty procesora używasz? Albo po prostu nie znasz się na architekturach i samym assembly więc piszesz bullshit. Owe duplikaty (niekoniecznie wrzucające na stos, które Ci się tak dziwnym trafem nie podobają) mogą wynikać z tego, że kod jest inline, by przyspieszyć działanie programu. Oczywiście kompilator wykorzystuje tylko niewielką część instrukcji procesora ale i ze swoim zasobem potrafi wyprodukować kod szybki i stosunkowo niewielki. Poza tym dzisiejsze komputery są raczej wystarczająco pojemne więc utrata kilkuset bajtów na rzecz szybkości działania nie jest czymś strasznym.

 

A ja nic nie pisałem o łatwości pisanie tylko o językach które moim zdaniem są lepsze pod względem szybkości.

Zgodzę się z Tobą, że można w ten sposób wyprodukować kod bardzo szybki jednakże kosztem czasu poświęconym na jego napisanie. Aczkolwiek dzisiaj języki HLL są na tyle dobre a procesory na tyle szybkie, że różnica pomiędzy wykonaniem kodu wystukanym w asm i w np. w C jest praktycznie niezauważalna. To przekłada się na przewagę języków wysokopoziomowych, gdyż są bardziej naturalne dla człowieka od niskopoziomowych instrukcji.

 

Podsumowując: asm jest OK ale czy ktoś dzisiaj miałby ochotę katować się dla kawałka superhiperekstraszybkiego kodu (w tym przypadku bota), którego szybkość wykonania jest niezauważalna w porównaniu do krótkiego kodu napisanego w jakimś HLL? Oczywiście, że nie ma sensu. W przypadku botów szczególnie chodzi o symulację kliknięcia konkretnego klawisza czy ustawienia pozycji myszki ale i nie zrobienie tego megaszybko a raczej z jakimś opóźnieniem, co dodatkowo wpływa na zacieranie różnic pomiędzy kodem w LLL i HLL.

 

@anakonda119 najwyraźniej dopiero zacząłeś zabawę z asm'em i prawdopodobnie od 8086 (wnioskując po tym, co piszesz) więc jeszcze długa droga przed Tobą. Szczególnie jeśli chodzi o architektury, na których pracują dzisiejsze systemy dla PC.

[anakonda119]

A kolega jest mistrzem i wie wszystko

Jeżeli chodzi o komputery z których korzystamy to rzeczywiście Języki takie jak Java,C# wystarczą o czym właśnie napisałem w 1 poście jednakże (Może tylko ja tak mam)

Moim zdaniem nawet te kilka bajtów które oda się uratować to jest ok, a 1 bajt dla proc 8 bit wiadomo, pisałem 1 bajt dla przykładu każdy morze sobie to przemnożyć i sprawdzić ile zaoszczędzi na swoim procku 32Bity = 4 X 1 Bajt 64 = 8X     Mówimy teraz że zaoszczędzę tylko 400Bajt albo jak wyjdą procesory architektury 128 = 16X to będzie 1600Bajt

 

PS mirraseq nie asm'em tylko asm'y <= to dwa rożne języki na Vol-ach intela jest opisany asm'y

[Vesim]

#pragm pack(1) też używasz żeby zaoszczędzić 7/4/3/2B(AJTY, widzę, że masz z tym problem) na maszynach które mają ponad 2GB RAMu?

[mirraseq]

A kolega jest mistrzem i wie wszystko

Jeżeli chodzi o komputery z których korzystamy to rzeczywiście Języki takie jak Java,C# wystarczą o czym właśnie napisałem w 1 poście jednakże (Może tylko ja tak mam)

Moim zdaniem nawet te kilka bajtów które oda się uratować to jest ok, a 1 bajt dla proc 8 bit wiadomo, pisałem 1 bajt dla przykładu każdy morze sobie to przemnożyć i sprawdzić ile zaoszczędzi na swoim procku 32Bity = 4 X 1 Bajt 64 = 8X     Mówimy teraz że zaoszczędzę tylko 400Bajt albo jak wyjdą procesory architektury 128 = 16X to będzie 1600Bajt

Daleko mi do miana mistrza a co dopiero do wszechwiedzącego. Nie wiem co Tobą kieruje, by tak skąpić na kilku bajtach kosztem - o ironio! - szybkości wykonania kodu. Skoro jesteś takim znawcą procesorów intelowskich, to zapewne wiesz co to jest cache procesora, jak on działa i jak wpływa na wykonywany program. Oprócz tego zapewne już znasz na pamięć która instrukcja wykonuje się jaką liczbę cykli więc doskonale wiesz jakich instrukcji używać, by przyspieszyć program jeszcze bardziej. Może dalej siedzisz na 8 bitowcach i każdy bajt jest na wagę złota ale na tym forum omawia się zagadnienia głównie związane z procesorami przeznaczonymi dla PC, dla których praktyki rodem ze starszych architektur niekoniecznie są najlepsze. Poza tym skąpienie 1KB na dyskach mogących pomieścić terabajty, to jak marudzenie, że w pokoju masz kilka bakterii...

 

PS mirraseq nie asm'em tylko asm'y <= to dwa rożne języki na Vol-ach intela jest opisany asm'y

Da fuq? Czy mógłbyś rozwinąć myśl?

 

PS. Może byłbyś w stanie opisać jakie praktyki wg Ciebie dają jakie korzyści? Ale bardziej konkretnie oprócz tego, że, wg Ciebie, "po prostu są"?

[anakonda119]

Nie uważam się za jakiegoś mistrza ale będę zawsze zachęcał do korzystania z języków niskiego poziomy niż wysokiego, nawet jeżeli różnica jest nie wielka.

[Jaca777]

będę zawsze zachęcał do korzystania z języków niskiego poziomu

Czyli uważasz, że najlepszym językiem do tworzenia programów jest asm?

Na tym forum bywały różne rzeczy, ale czegoś takiego jeszcze nie widziałem.

 

 

PS mirraseq nie asm'em tylko asm'y <= to dwa rożne języki na Vol-ach intela jest opisany asm'y

? Czyli istnieją dwa różne assemblery, które różnią się tym, że ich skróty inaczej się odmieniają?

[GotoFinal]

Nie uważam się za jakiegoś mistrza ale będę zawsze zachęcał do korzystania z języków niskiego poziomy niż wysokiego, nawet jeżeli różnica jest nie wielka.

Chce to zobaczyć, jak nagle wszyscy olewają wszystkie języki i piszą tylko w asm lub maszynowym, tak, to będą pięknę czasy, każdy program będzie powstawał 10 lat dłużej, ale za to będzie zjadał 100 MB pamięci mniej, zamiast 20 dokumentów w notatniku, otworzysz 22, a twoja ulubiona gra, zamiast 100 fps, będzie miała 120.

Warto zmarnować czekać te 10 lat na każdy program!

ASM zamiast C, zamiast C++, zamiast Javy, zamiast JavaScript, HTML-a i CSS też wywalmy, na co to komu?! Będziemy wysyłać binarnie programy renderujące strony (oczywiście w asm).

 

Najlepiej pisać też wszystko jako własny system, bo dlaczego taki Windows/Linux ma spowalniać nasz program, jak możemy napisać nasz program tak, by był odpalany zamiast systemu!

Wkładasz pendriva, resetujesz komputer i masz notatnik!

Osobiście myślę że całe te procesory, wykonujące setki różnych operacji to jakieś pie... nieporozumienie, każdy program powinien być osobnym czipem, wkładanym do komputera, gdzie cały program opiera się na idealnie dobranych bramkach, dzięki temu nie musimy marnować czasu na przetwarzanie operacji przez procesor, ani pisać żadnego kodu, asm do kosza! Tylko bramki i elektronika!

 

 

Programy powinny być wydajne itd... ale nie można z tym przesadzać, po prostu ma się z tego dać sensownie korzystać na aktualnym sprzęcie.