W czym napisać interpreter i kompilator

Witam

Zacząłem sobie już trochę pisać kompilator języka skryptowego i niestety (a może się okaże, że stety) zacząłem myśleć o szybkości. Chce zrobić coś takiego, że interpreter będzie miał wbudowany kompilator (lub kompilowanie do bytekodu przed uruchomieniem, a po napisaniu skryptu) więc musi to być szybkie. I moje pytanie co będzie szybsze w C++ (obiektowo) w C czy lepiej w assemblerze? Co do C++ mam wątpliwości bo przecież to dodatkowo różne konstruktory i destruktory prze tworzeniu nowych obiektów dynamicznie. Ale ja się nie znam na optymalizowaniu/szybkosci więc pytam się Was. :)

Napisz w czym chcesz, jakie ma znaczenie czy cos bedziesz kompilowac 300ms czy 1s?

No ale w 1s można by skompilować 3 skrypty po 300ms. Dla mnie ma znaczenie, ale czy warto aż po assemblera sięgać czy może C było by równie dobre. Btw. Dla programistów JVM widocznie nie miało :D.

Ok. Pisz w assemblerze pod konkretny procesor i konkretny system. Tak bedzie najszybciej. Powodzenia.

niestety (a może się okaże, że stety) zacząłem myśleć o szybkości

Jeśli to co napisałeś jest za wolne, to znaczy że coś kiepsko napisałeś.
A nie że trzeba to przepisać w asemblerze.

A jeśli nie jest za wolne, tylko "zacząłeś myśleć o prędkości" to przestań i skup się na tym co robisz.

Ze studiów pamiętam że generalnie kompilatorów nie pisze się od nowa, tylko używa się raczej gotowych analizatorów składniowych/leksykalnych etc. Offc taki wynikowy kompilator nie jest najwydajniejszym rozwiązaniem bo pewnie w czystym asmie dałoby się szybciej. Wyczytałem też gdzieś + kiedyś że język C++ był na samym początku sporym wyzwaniem dla twórców kompilatorów i pierwsze jego wersje to były translatory na C + użycie na wyniku kompilatora C. I już zupełnie na końcu dodam że Groovy, czyli język dość szeroko stosowany i niekojarzony jako specjalnie wolny używa biblioteki ANTLR, czyli właśnie analizatorów pisanych w Javie.

Podsumowując to co wyżej napisałem. Nie sądzę że ktoś pisze kompilator from scrach, a tym bardziej wątpię by ktoś kto zadaje tutaj takie pytanie był w stanie napisać kompilator from scrach który działałby lepiej niż ten z gotowych narzędzi.

Moja rada. Chcesz szybkości? Użyj C + bison/yacc/lex/flex etc.

Kompilatory zwykle:

1. zawierają mnóstwo rozgałęzień w kodzie, rzadko posiadają ciasne pętle - dużo kodu wykonuje się co najwyżej raz,
2. wykorzystują drzewiaste struktury danych i masowo robią na nich "pattern-matching",
3. często buforują i współdzielą dane, co powoduje, że dealokacja pamięci jest nietrywialna; również często alokują pamięć jak szalone

Punkt 1. powoduje, że języki odpalane na VM takie jak C# czy Java i kompilowane w locie słabo się sprawdzą (zbyt duży narzut na start, JIT nie zdąży zadziałać dla większości kodu). Punkt 2. powoduje, że przyda Ci się język z porządną biblioteką standardową, gdzie łatwo budować złożone struktury danych (C raczej odpada; C++ też słabo) i język, który wspiera pattern-matching natywnie. Punkt 3. powoduje, że języki z ręcznym zarządzaniem pamięcią np. C lub C++ będą bardzo upierdliwe.

Haskell?
OCaml?

Punkt 1. powoduje, że języki odpalane na VM takie jak C# czy Java i kompilowane w locie słabo się sprawdzą
To ciekawe dlaczego Microsoft ostatnio przepisał cały kompilator C# z C++ na C#? ;-)

Ten język skryptowy będzie kompilowany do bytekodu tak jak Java. Nie będzie nie wiadomo jak skomplikowany język bo będzie składnia assemblera. To może jednak ja użyję już tego C. Asm mi nie podchodzi ze względu na brak przenośności dlatego się pytam czy jest jakiś sens pisać w nim. @n0name_l

Problem jest taki, ze OP zalozyl, ze jego kod jest swietny a brak wydajnosci to wina srodowiska, w ktorym ten kod powstal.
Właśnie chodzi o to, że założyłem winę mojego kodu i pomyślałem, że w asm ten mój zły kod będzie szybszy.

Poczytaj o LLVM.

A teraz może, czy lepiej używać char* do przechowywania pojedynczych linijek tego skryptu asm więc krótkie czy lepiej użyć std::string? Czy jest sens.

Skup się na skończeniu projektu (aka. zrób najprościej - użyj gotowców i jak najmniej kodu w którym łatwo popełnić błąd). Potem jak za wolno będzie działać to odpal profilera, sprawdź co działa najwolniej, popraw algorytm. Jak algorytm doprowadzisz do stanu, w którym już się nie będzie dało go poprawić i nadal będzie za wolno to wtedy dopiero baw się w takie pierdoły jak własne struktury danych.