Pharo and Pi
Locked
 
|
Stef wrote:
>Our goal is to remove the dependencies to nativeboost. I know that FFI is now maintained again and there is some initiative on a (more) unified FFI. Also there may be some issues with NB: harder to understand than FFI, not complete for ARM, ... Also for Apple devices it is not able to generate/perform machine code in memory. But when you go native you usually have to take care of the underlying system anyway. But if I understood correctly all this new improvements/movements away from NB will be at the cost of performance: FFI will slower than NB. Or did I misunderstood? The only issues I had with NB so far ist that it initially takes some effort to know the details. But it worked great once one get used to it and I like that Pharo gets fast with it... Why not complete 64 bit, AsmJIT/NB for ARM beside x86 and where possible provide the NB layer? For other platforms we can fall back to FFI when needed. For sure there could be a more unified way to call. Maybe thats the goal of the unified FFI and I just do not know the details. Maybe NB is already planned as a possible backend and it is still possible to use it. Or will it be legacy afterwards? I do not care if it is called "NB" or "FFI" or other, but I would dislike if I had to give up performance or native possibilities or if we just throw away something that was developed/integrated with effort into the image initially. I guess more info or patience is required... |
|
|
> Stef wrote: >> Our goal is to remove the dependencies to nativeboost. > I know that FFI is now maintained again and there is some initiative > on a (more) unified FFI. Also there may be some issues with NB: harder to > understand than FFI, not complete for ARM, ... not working with Spur, not working with 64bits > Also for Apple devices it is not able to generate/perform machine code > in memory. But when you go native you usually have to take care of the > underlying system anyway. > > But if I understood correctly all this new improvements/movements away from > NB will be at the cost of performance: FFI will slower than NB. Or did I > misunderstood? probably in the first period. > The only issues I had with NB so far ist that it initially takes > some effort to know the details. But it worked great once one get > used to it and I like that Pharo gets fast with it... Me too. But between fast on principle and not working in reality and slower and working, I chose the second. I want Pharo to run on Spur. > > Why not complete 64 bit, AsmJIT/NB for ARM beside x86 and where possible > provide the NB layer? Do you know how to do it? Should we burn months of Esteban to learn it so that after he can extend it. Should we be relying on the knowledge of one single person? > For other platforms we can fall back to FFI when needed. > For sure there could be a more unified way to call. I spent 14 000 Euros on my budget to pay max as intern to work on virtualCPU with igor so that NB could take advantage of having a CPU abstraction. They worked great and hard. But NB was never updated to take advantage of virtualCPU and probably virtual CPU was not totally finished. I thought that Igor would continue to improve NB and use Virtual CPU but I was wrong. To me this is a pure lost of money and max should have worked on updates. So I learned something: I will not pay interns on projects that I cannot use/or maintain myself I was stupid but I'm learning. > > Maybe thats the goal of the unified FFI and I just do not know the > details. Maybe NB is already planned as a possible backend and it is > still possible to use it. Or will it be legacy afterwards? NB will be a possible backend if uFFI happens and if NB works with the system. So the first step is use NB syntax for "uFFI front end" provide FFI as back-end hope that ronie delivers low end hope that igor release NB Spur > > I do not care if it is called "NB" or "FFI" or other, but I would dislike if I had > to give up performance or native possibilities or if we just throw away > something that was developed/integrated with effort into the image initially. I can tell you that I did my best (and even more) but that this is not something that I can control. If Igor turned into a pumpskin is not my fault or wish. He always got all my support (you can ask the team here). Now there is a lesson in that story: we should not rely on a single person. > > I guess more info or patience is required... We want Pharo on Spur! This is key for clement's works and for all the community. Stef |
|
I agree with Stef that Pharo needs code that is easy to understand , because code that is easy to understand is far more likely to be maintained. There is little value to boosted performance if you come face to face with show stopper bugs that never get fixed because none dares touch them. Also I am still not convinced that NB is as fast as people claim to be unless I see a very detailed performance test suite that compares NB vs other FFIs side by side. So far it seems to me that people are easily convinced that NB is fast because its based on Assembly code but that is debatable since C is perfectly capable to generate heavily optimized machine code. The one thing that makes NB cool for me is that it can generate machine code on the fly the only downside is that is uses Assembly, which is very verbose and too low level. If NB used C type of syntax for Pharo I think it would be ideal . It would allow you to write C code using Pharo syntax and without a need for a compiler or compiling / linking. In any case none stops anyone from moving NB forward as a third party library. I know I wont be one to do so ;) |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |