Skip to content
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

Closed
lf94 opened this issue Jan 14, 2022 · 4 comments
Closed

Performance vs other Prolog implementations? #1213

lf94 opened this issue Jan 14, 2022 · 4 comments

Comments

@lf94
Copy link

lf94 commented Jan 14, 2022

Currently I'm trying to find the fastest Prolog implementation to see how it competes for certain problems. How is Scryer?

@infogulch
Copy link
Contributor

infogulch commented Jan 14, 2022

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.)

@lf94
Copy link
Author

lf94 commented Jan 14, 2022

Do you already have prolog code to solve those problems and a harness to benchmark it?

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.

@triska
Copy link
Contributor

triska commented Jan 14, 2022

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.

@UWN
Copy link

UWN commented Jan 15, 2022

Could this move to discussions, please?

@lf94 lf94 closed this as completed Jan 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants