Re: speed of eu 2.5 + dynamic inclusion

new topic     » goto parent     » topic index » view thread      » older message » newer message

Alexander Toresson wrote:

> Juergen Luethje wrote:
>>
>> Alexander Toresson wrote:
>>
>>> Juergen Luethje wrote:
>>>> Of course, I also see the disadvantage, but I think it mainly concerns
>>>> to:
>>>> o newbies
>>>
>>> Newbies scared off by slowness => fewer newbies => lesser growth
>>
>> Or more people will buy the binder, in order to increase speed. But
>> I think your consideration above is right.
>
> Hmm? Do the binder use the c frontend? Have I interpreted it wrongly?

No, I don't think so. So I believe that the binder (I don't have it
currently) takes the same time for parsing a given program as the
interpreter does.
By binding a big program, you'll save much time anyway, because you bind
it *only once*. Then the startup time of the bound program is almost
zero. If that program is not bound, the interpreter will have to do the
time consuming parsing every time you run the program.

>>>> o other people who don't have the binder/shrouder
>>>
>>> I didn'thave it for a long time, because ordering something from Canada
>>> seemed quite strange to my parents (I'm 16).
>>
>> Your parents took it away? Is there something we can do about it? Maybe
>> we can write an e-mail to your parents, telling them who we are, and
>> that we don't do any illegal or otherwise strange things here.
>> I also can do this alone, privately, or your parents could write me a
>> mail if they want, asking me whatever they like. I'm a 46 old physician
>> from Berlin, Germany.
>
> I do have it now. Maybe I formulated it wrongly. It took a year to convince
> them.

Ooops, misunderstanding. I'm glad that you could convince them. I think
your parents can be happy, that their son has a hobby which is very good
for the "little gray cells". smile

>>>> o the developement process of a program/library
>>>
>>> This is the point I'm mostly concerned about.
>>
>> Me too.
>>
>>> Using 2.5 would slow down my development process significantly.
>>>
>>>>   ==> I hope we can inlude "shrouded" IL libraries!!
>>>
>>> Why should that be needed, other as a work-around (may I say hack)
>>> for making the start-up for programs faster?
>>
>> Yes, programs then would start up faster (significantly if they include
>> large libraries such as Win32Lib).
>> Such a mechanism is e.g. also used in PowerBASIC (using the keyword
>> "link"), and also in C, as Andy Drummond recently wrote.
>> I wouldn't call it a work-around or a hack, I think it's quite logical
>> behaviour. Parsing and compiling (in this case to IL code) takes time,
>> and why do the same work over and over again, if it's not necessary?
>
> Yeah, it was radical to call it a hack. But I do still think that
> translating the frontend into euphoria code, making it 20x slower,
> and using this in the official interpreter, is bad. I mean, the old one
> was extremely fast, which makes il libraries completely unnecessary.

I agree. With a very fast front-end like the one used by Eu 2.4, IL
libraries are not necessary.
As far as I understood, the main reason why RDS translated the front-end
to Euphoria was better maintainability, which also probably means less
bugs in Euphoria, which is good for our programs (altough there are only
few bugs in Euphoria anyway).
My suggestion for the possibility of including/linking (or whatever the
proper technical term would be) IL libraries was an attempt to find a
solution that meets all demands. smile

> [snip]
>
>>>>> I've also found out that because everything is parsed before the program
>>>>> is run,
>>>>> dynamic inclusion cannot be done, ie writing include statements to a file
>>>>> and then including it. For example, both the jarod library, my asm
>>>>> debugger and
>>>>> a project I currently work on is affected. They simply won't run.
>>>>>
>>>>> It can be worked around for jarod and the asm debugger, though it cannot
>>>>> be worked around
>>>>> for my current project. It includes all *.e files it finds in a specific
>>>>> directory,
>>>>> using them as plugins. And no, don't tell me to compile them into dlls.
>>>>> Because that
>>>>> shouldn't be needed. And I don't own the full translator.
>>>>
>>>> Concerning this point, I had an idea some time ago (URL might wrap):
>>>>
>>>> http://www.listfilter.com/cgi-bin/esearch.exu?fromMonth=2&fromYear=9&toMonth=2&toYear=9&postedBy=Juergen+Luethje&keywords=%2214+Feb+2004+10%3A54%3A22%22
>>>>
>>>> Maybe you can tell me, whether it actually works? smile
>>>
>>> That is good idea, though not always usable.
>>
>> When is it not usable? Maybe we can find here another solution for those
>> cases.
>>
>
> What if one doesn't want to add that extra complexity to one's code?
> It adds an extra step in program execution that wasn't needed before.
> But I do not see how this 'argument' of mine would hinder me from using
> it. It is just an observation of what people may think.

After some time gathering experience with the method, we'll probably see
how good it meets the needs in practice.

Regards,
   Juergen

-- 
Have you read a good program lately?

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu