-
Notifications
You must be signed in to change notification settings - Fork 123
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Performance vs other Prolog implementations? #1213
Comments
As a general rule, different prolog systems have different strengths and may perform better or worse depending on the problem. Luckily most prolog systems are roughly compatible with the ISO standard, so if you write a program to test one prolog it is likely compatible or else easily ported to another. Ideally you'd compare prologs you're interested in with an implementation of your chosen problems in each. (As with any good benchmarking comparison.) What are the set of problems that you want to benchmark? Do you already have prolog code to solve those problems and a harness to benchmark it? (In my opinion, this post may also be suitable as a discussion instead of an issue.) |
I don't, I was just overall curious 🙂 I think ultimately as a hobbyist I'll be going with the most used variant, as it'll have the most impact. |
One important point that may be relevant for your choice: What problems are you most interested in? Due to its built-in grammar mechanism (DCGs), Prolog is an excellent language for fast and convenient text processing, such as reasoning about natural languages, parsing, text generation, scripting etc. Scryer Prolog excels especially in this area, due to its very compact internal string representation (#24, #95). All other Prolog systems currently store strings with a 24-fold overhead compared to Scryer Prolog! For example, if you need to process a 2 GB text file and read it fully into memory as a list of characters for convenient string processing with DCGs, then Scryer Prolog will need 2 GB for it, and other systems will need 48 GB (this is not a typo!), with proportional costs for accessing so much memory. The planned improvements on top of this compact representation (see for example #1192 (comment)) have the potential to make Scryer Prolog the most suitable Prolog system to use if you want to achieve greatest performance and convenience when reasoning about large amounts of text. If this use case is important for you, this could also be an important factor in your choice. |
Could this move to discussions, please? |
Currently I'm trying to find the fastest Prolog implementation to see how it competes for certain problems. How is Scryer?
The text was updated successfully, but these errors were encountered: