The python brother of the Ring2C project

[Mansour Ayouni]

Hello Mahmoud,

Are you aware of this: https://nuitka.net?

It's used by Qt company for their PyQt project.

May this project of C Python compiler give you some lessons learned for your future development of Ring2C...

Best,

Mansour

[Mahmoud Fayed]

Hello Mansour

>> "May this project of C Python compiler give you some lessons learned for your future development of Ring2C"

Thanks for sharing, But We don't need to look at other projects to know how to develop (Ring2C)

(1) We already developed Ring Compiler/VM - While Ring2C will be Just a Translator or Compiler (The challenge is smaller not bigger)

(2) Each programming language comes with different implementation  that match it's design & unique features

According to their website : "Nuitka is already slightly faster than CPython, but there is work to be done to include as many C optimizations as possible. We currently get a 312% speedup in pystone, which is a good start."

Being 3 times faster than CPython is not enough to match the effort required for such a project, but it's a good start and I hope that they can improve this in the future.

Remember in Ring, we have (REAL THREADS) - Using it we can get this increase in performance

Also we can improve the Ring VM performance to reach our limits in the current implementation before starting another project like (Ring2C)

When we think about (Ring2C) we think about the complete performance of the C language that could be from 1 to 100 times faster (according to the problem)

Also I am not saying that (Ring2C will bring us the complete performance of C - OR half of this performance - I still don't know how the results will be) - I am just saying this must be the goal, and it's a challenge because writing in Ring means the code is already high-level and this comes with a cost related to the performance.

There is a reason CPython still uses Compiler/VM and doesn't go in this direction (See other languages like Nim : https://nim-lang.org/ )

If you want to get the BEST PERFORMANCE ---> You must sacrifice some of the other things like (Safety, Flexibility, Usability, Dynamic Features, etc.)

Greetings,

Mahmoud

[Ilir]

Hello Mahmoud and all,

Remember in Ring, we have (REAL THREADS) - Using it we can get this increase in performance

I'm not sure what do you mean by REAL THREADS? Official Ring is using eval mode to run thread, Ring2A is running thread eval-free. That's why I'm getting double-increased performance in ex5_wavingcubes_threads for example.

I'm planning to start Ring2C development next year. But before that, Ring2A and Ring2B are coming where Ring2B is a game-changer because of the VM redesign.

[Mahmoud Fayed]

Hello Ilir

>> "I'm not sure what do you mean by REAL THREADS?"

I mean no Global-Interpreter-Lock (GIL) as in Python

>> "Official Ring is using eval mode to run thread, Ring2A is running thread eval-free"

This is little optimization (related to Thread Startup Time)

We already have a function that can do this optimization  :  https://github.com/ring-lang/ring/blob/master/language/src/ring_vm.c#L1483

I have used it with RingFreeGLUT

But what really matters (Each thread can work at the same time) - and We already have this

Greetings,

Mahmoud

[Mansour Ayouni]

Hello Mahmoud,

This is instructive analysis.

Thank you.

Mansour

--

---
You received this message because you are subscribed to the Google Groups "The Ring Programming Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ring-lang+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ring-lang/1500ab42-410d-40d2-a30e-86492ca8352fn%40googlegroups.com.

[Ilir]

Hello Mahmoud,

ring_vm_callfunction is calling  ring_vm_mainloopforeval, so it is still running in eval mode having optimizations disabled.

Ring2A uses different approach: thread starts in eval mode, for example using ""thread("+t+")" as input to eval, and then it switches to eval-free mode while executing above function where all optimizations are enabled (instructions replacement, functions cache, etc). That makes animation of the cubes double faster for example.

Yes, there is no GIL, but we have problem where global lists are in race condition which is solved in Ring2A by using internal array after the newlist (or list) function is called or [] syntax is used with up to 16 elements (same rule for sub-elements)

[Mahmoud Fayed]

Hello Mansour

>> "This is instructive analysis. Thank you."

You are welcome :D

Greetings,

Mahmoud

[Mahmoud Fayed]

Hello Ilir

>> "and then it switches to eval-free mode while executing above function where all optimizations are enabled (instructions replacement, functions cache, etc). That makes animation of the cubes double faster for example."

Very good news, Keep up the GREAT WORK :D

Greetings,

Mahmoud

[Ilir]

Hello Mahmoud,

thanks. I forgot to say: in official Ring we need thread synchronization because of the list race condition, but in Ring2A mutex is not used! Because internal array is used (even lists swap works without synchronization).

Furthermore, I managed to run wavingcubes_threads using only single buffer, but then threads synchronization must be used where main thread releases worker immediately before drawing occurs.

[Mahmoud Fayed]

Hello Ilir

>> "Yes, there is no GIL, but we have problem where global lists are in race condition which is solved in Ring2A by using internal array after the newlist (or list) function is called or [] syntax is used with up to 16 elements (same rule for sub-elements)"

What about generating the array when

(1) Creating the List

(2) Updating it (Add/Delete/ChangingItem Type)

As Ring does with it's internal lists for (Variables)

The point is to avoid the 16 elements limit. Also testing both ideas and checking the performance difference (Then sharing these results will be very useful)

Greetings,

Mahmoud

[Ilir]

Hello Mahmoud,

my idea is simple. I don't expect users to modify a list created using newlist or a list function. But if that happens, penalty is moderately high because internal array is going to be freed using standard C function (slow because of the hash). To rebuild array here for me doesn't make sense either, for example wawingcubes lists are having 2X15x15x3 elements.

In case of the [] syntax, idea is to go trough GC allocated/reallocated blocks of 64 bytes where 16 32-bit addresses can be placed. So if user crates a list like

lst = ["one","two","three"]

internal array is going to be allocated fast using GC-PoolManager block of 64 bytes. At the moment, if users start modifying such array, array is immediately removed fast (and reused through GC for other data). In a future, and I want that to be in Ring2B, array will rebuild itself during modification up to 16 elements for above reason, but then list will be able to grow although internal array will stay at 16 elemens. I have already mechanism for this, but there is no enough time to test this (or anything else in that matter)