unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
* Screaming-Fist: a JIT framework for Guile
@ 2023-12-03 17:26 Nala Ginrut
  2023-12-03 20:49 ` Dr. Arne Babenhauserheide
  2023-12-04 21:26 ` Maxime Devos
  0 siblings, 2 replies; 6+ messages in thread
From: Nala Ginrut @ 2023-12-03 17:26 UTC (permalink / raw)
  To: Guile User

Hi Folks!
I'd like to introduce our new project named screaming-fist which is a JIT
framework based on libgccjit.

The project is still preliminary, but the POC could run.

The basic idea is to hide the JIT details and let users write Scheme-like
code for JIT on the fly.

here's the simple code:
--------------------------------
(import (screaming-fist jit))

(jit-define (square x)
  (:anno: (int) -> int)
  (* x x))
(square 5)

;; ==> 25
----------------------------------

And you can dump IR, say, gimple:
----------------------------------------------

(import (screaming-fist utils) (screaming-fist jit))
(parameterize ((dump-mode "gimple"))
 (jit-define (square x)
  (:anno: (int) -> int)
  (* x x)))

-------------------------------


The possible output could be:

------------------------------

int square (int x){
  int D.79;

  <D.76>:
  D.79 = x * x;
  return D.79;}

--------------------------------------------

The branching and looping codegen is still under debugging.

Here's the project page:

https://gitlab.com/SymeCloud/screaming-fist

Happy hacking!


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Screaming-Fist: a JIT framework for Guile
  2023-12-03 17:26 Screaming-Fist: a JIT framework for Guile Nala Ginrut
@ 2023-12-03 20:49 ` Dr. Arne Babenhauserheide
  2023-12-05  9:36   ` Nala Ginrut
  2023-12-04 21:26 ` Maxime Devos
  1 sibling, 1 reply; 6+ messages in thread
From: Dr. Arne Babenhauserheide @ 2023-12-03 20:49 UTC (permalink / raw)
  To: Nala Ginrut; +Cc: guile-user

[-- Attachment #1: Type: text/plain, Size: 455 bytes --]


Nala Ginrut <nalaginrut@gmail.com> writes:
> Hi Folks!
> I'd like to introduce our new project named screaming-fist which is a JIT
> framework based on libgccjit.
> (import (screaming-fist jit))
>
> (jit-define (square x)
>   (:anno: (int) -> int)
>   (* x x))
> (square 5)

That looks interesting!

Do you already have performance data?

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Screaming-Fist: a JIT framework for Guile
  2023-12-03 17:26 Screaming-Fist: a JIT framework for Guile Nala Ginrut
  2023-12-03 20:49 ` Dr. Arne Babenhauserheide
@ 2023-12-04 21:26 ` Maxime Devos
  2023-12-05 10:14   ` Nala Ginrut
  1 sibling, 1 reply; 6+ messages in thread
From: Maxime Devos @ 2023-12-04 21:26 UTC (permalink / raw)
  To: Nala Ginrut, Guile User


[-- Attachment #1.1.1: Type: text/plain, Size: 1135 bytes --]



Op 03-12-2023 om 18:26 schreef Nala Ginrut:
> (jit-define (square x)
>    (:anno: (int) -> int)
>    (* x x))
> (square 5)


Potentially-overflowing arithmetic involving ints (not unsigned ints, 
but ints)? Best document somewhere to what the jit code '(* x x)' 
evaluates when (not (<= min-int (* x x) max-int))).

Personally, I'm in favor of explicit long names like

*/error-on-overflow     (<-- maybe on the C-level the function could 
return a tagged union representing (failure [no value]) / (success [some 
value], at a slight performance cost)
*/wrap-around
*/undefined-on-overflow (<-- like in C, for maximal performance and 
dragons).

(Likewise for +, - and unsigned int)

Sure, they are a bit verbose, but they are explicit and 
non-explicitness+undefined behaviour of'*' in C has caused serious 
issues in the past, so I'd think it's better that the programmer has to 
choose what, in their situation, are the appropriate semantics.

If/when someone desired shorter names, there could be a
(jit-define-alias * */wrap-around) or something like that for that?

Best regards,
Maxime Devos

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Screaming-Fist: a JIT framework for Guile
  2023-12-03 20:49 ` Dr. Arne Babenhauserheide
@ 2023-12-05  9:36   ` Nala Ginrut
  0 siblings, 0 replies; 6+ messages in thread
From: Nala Ginrut @ 2023-12-05  9:36 UTC (permalink / raw)
  To: Dr. Arne Babenhauserheide; +Cc: Guile User

hi Arne!
Not yet, I'm still working on it before any convincing complex code for
performance evaluation.

The idea is to provide a Scheme like functional IR to make JIT easier to
use. However, the libgccjit IR is imperative based on assignments and
statements. So there are more works to do other than a traditional binding.


Best regards.

On Mon, Dec 4, 2023 at 4:49 AM Dr. Arne Babenhauserheide <arne_bab@web.de>
wrote:

>
> Nala Ginrut <nalaginrut@gmail.com> writes:
> > Hi Folks!
> > I'd like to introduce our new project named screaming-fist which is a JIT
> > framework based on libgccjit.
> > (import (screaming-fist jit))
> >
> > (jit-define (square x)
> >   (:anno: (int) -> int)
> >   (* x x))
> > (square 5)
>
> That looks interesting!
>
> Do you already have performance data?
>
> Best wishes,
> Arne
> --
> Unpolitisch sein
> heißt politisch sein,
> ohne es zu merken.
> draketo.de
>


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Screaming-Fist: a JIT framework for Guile
  2023-12-04 21:26 ` Maxime Devos
@ 2023-12-05 10:14   ` Nala Ginrut
  2023-12-05 20:30     ` Nala Ginrut
  0 siblings, 1 reply; 6+ messages in thread
From: Nala Ginrut @ 2023-12-05 10:14 UTC (permalink / raw)
  To: Maxime Devos; +Cc: Guile User

Hi Maxime!



On Tue, Dec 5, 2023, 05:26 Maxime Devos <maximedevos@telenet.be> wrote:

>
>
> Op 03-12-2023 om 18:26 schreef Nala Ginrut:
> > (jit-define (square x)
> >    (:anno: (int) -> int)
> >    (* x x))
> > (square 5)
>
>
> Potentially-overflowing arithmetic involving ints (not unsigned ints,
> but ints)? Best document somewhere to what the jit code '(* x x)'
> evaluates when (not (<= min-int (* x x) max-int))).
>

There's no type inference in libgccjit, so the high level framework has to
handle accurate types.

I use "int" here because libgccjit only provides int rvalue constructor,
yet. It seems lack of rich number types as rvalue in the present
implementation. Even boolean has to be handled by high level framework and
cast it to int respectively.

May be we need GCC folks help.


> Personally, I'm in favor of explicit long names like
>
> */error-on-overflow     (<-- maybe on the C-level the function could
> return a tagged union representing (failure [no value]) / (success [some
> value], at a slight performance cost)
> */wrap-around
> */undefined-on-overflow (<-- like in C, for maximal performance and
> dragons).
>

There was such check, but I've removed it. Since even you detect the
int/short/long exactly, libgccjit only provides int rvalue for all cases of
numbers. I'm not sure if it's waiting for contribution or intended as an
unified int abstract.


> (Likewise for +, - and unsigned int)
>
> Sure, they are a bit verbose, but they are explicit and
> non-explicitness+undefined behaviour of'*' in C has caused serious
> issues in the past, so I'd think it's better that the programmer has to
> choose what, in their situation, are the appropriate semantics.
>

I see your point :-)
Yes, it's a bit hard to provide an abstract arithmetic with type inference
for all cases, providing each for different types will be easier and
flexible.

Thanks!
Best regards.


>


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Screaming-Fist: a JIT framework for Guile
  2023-12-05 10:14   ` Nala Ginrut
@ 2023-12-05 20:30     ` Nala Ginrut
  0 siblings, 0 replies; 6+ messages in thread
From: Nala Ginrut @ 2023-12-05 20:30 UTC (permalink / raw)
  To: Maxime Devos; +Cc: Guile User

Hi folks, I confirmed that gcc_jit_context_new_rvalue_from_int is an
abstract for various numbers.

So the number's validation would be added then.

Best regards.

On Tue, Dec 5, 2023, 18:14 Nala Ginrut <nalaginrut@gmail.com> wrote:

> Hi Maxime!
>
>
>
> On Tue, Dec 5, 2023, 05:26 Maxime Devos <maximedevos@telenet.be> wrote:
>
>>
>>
>> Op 03-12-2023 om 18:26 schreef Nala Ginrut:
>> > (jit-define (square x)
>> >    (:anno: (int) -> int)
>> >    (* x x))
>> > (square 5)
>>
>>
>> Potentially-overflowing arithmetic involving ints (not unsigned ints,
>> but ints)? Best document somewhere to what the jit code '(* x x)'
>> evaluates when (not (<= min-int (* x x) max-int))).
>>
>
> There's no type inference in libgccjit, so the high level framework has to
> handle accurate types.
>
> I use "int" here because libgccjit only provides int rvalue constructor,
> yet. It seems lack of rich number types as rvalue in the present
> implementation. Even boolean has to be handled by high level framework and
> cast it to int respectively.
>
> May be we need GCC folks help.
>
>
>> Personally, I'm in favor of explicit long names like
>>
>> */error-on-overflow     (<-- maybe on the C-level the function could
>> return a tagged union representing (failure [no value]) / (success [some
>> value], at a slight performance cost)
>> */wrap-around
>> */undefined-on-overflow (<-- like in C, for maximal performance and
>> dragons).
>>
>
> There was such check, but I've removed it. Since even you detect the
> int/short/long exactly, libgccjit only provides int rvalue for all cases of
> numbers. I'm not sure if it's waiting for contribution or intended as an
> unified int abstract.
>
>
>> (Likewise for +, - and unsigned int)
>>
>> Sure, they are a bit verbose, but they are explicit and
>> non-explicitness+undefined behaviour of'*' in C has caused serious
>> issues in the past, so I'd think it's better that the programmer has to
>> choose what, in their situation, are the appropriate semantics.
>>
>
> I see your point :-)
> Yes, it's a bit hard to provide an abstract arithmetic with type inference
> for all cases, providing each for different types will be easier and
> flexible.
>
> Thanks!
> Best regards.
>
>
>>


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2023-12-05 20:30 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-12-03 17:26 Screaming-Fist: a JIT framework for Guile Nala Ginrut
2023-12-03 20:49 ` Dr. Arne Babenhauserheide
2023-12-05  9:36   ` Nala Ginrut
2023-12-04 21:26 ` Maxime Devos
2023-12-05 10:14   ` Nala Ginrut
2023-12-05 20:30     ` Nala Ginrut

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).