[m-users.] users Digest, Vol 107, Issue 16

[Michel Vanden Bossche]

> Am Montag, dem 16.10.2023 um 16:20 +0200 schrieb Michel Vanden Bossche:
>> 
>>> On 16 Oct 2023, at 16:07, Volker Wysk <post at volker-wysk.de> wrote:
>>> 
>>> Am Montag, dem 16.10.2023 um 15:39 +0200 schrieb Michel Vanden Bossche:
>>>>> On Sat, 14 Oct 2023, Matthew Delaney wrote:
>>>>> 
>>>>>> Hi, I'm new to Mercury but am interested in using it to replace
>>>>>> Prolog
>>>>>> in a project I'm just starting. This project will need a web-
>>>>>> interface
>>>>>> and backend DB connectivity. Reading through Mercury's
>>>>>> documentation,
>>>>>> it looks like the most straightforward approach would be to use
>>>>>> CGI
>>>>>> for the Web App part and the Foreign Language Interface for DB
>>>>>> connectivity. Is that correct or are there other options
>>>>>> available?
>>>>> 
>>>>> If you're using one of the Java or .NET web frameworks, you can
>>>>> compile
>>>>> your Mercury to a Java or C# library respectively and call it from
>>>>> the
>>>>> framework.
>>>>> 
>>>>> Julien.
>>>> 
>>>> Our experience with the Java backend is that it offers great
>>>> performance.
>>>> A Mercury application complied to Java is viewed from the outside as a
>>>> standard Java application (Spring Boot…) and can be easily deployed in
>>>> the
>>>> cloud, using Kubernetes for scalability. Just in case…
>>> 
>>> I've programmed in Java many years ago. And I think that the asm_fast
>>> grade
>>> must be WAY faster than Java. I have two time critical Mercury projects
>>> and
>>> the performance is astonishing.
>> 
>> 
>> Yes, of course, outstanding, but you would be surprised by the performance
>> with Java, with the additional benefit of having the possibility to use
>> all the Java ecosystem. In the paper attached (section 7 Benchmark), you
>> see that the performance “penalty” for using Java is a factor 2.5, quite
>> reasonable. This was done in 2010 and should be redone (NB - The link to
>> the demo cloud.missioncriticalit.com/rule-demo is unfortunately not active
>> anymore).
> 
> This really surprises me. But they don't state if they used the low-level-C
> (asm_fast) or the high-level-C backend. The former is faster.

High-level-C backend, vintage 2010.

Cheers,
Michel