OpenEuphoria

2. RE: Threads [Was: Re: 64 bit euphoria]

• Posted by Mario Steele <eumario at trilake.net> Apr 24, 2005
• 456 views

Mike wrote:
> API function ReadFileEx() will load in a file asynchronously (in the 
> background)
> and then notify the user upon completion. (The progress bar is not even 
> needed in
> this case.)

Okay, first off with this, I wasn't refering to ReadFileEx(), or such things
as that, cause you also have to think, that ReadFileEx() loads a file into
memory, and should that file be a graphical file, still needs to be decoded
by your target graphics library.  Weither that be Windows API, Exotica, Allegro,
etc, etc.  And Memory Access may be faster, but it still takes time, especially
if it's a very graphical intense system, and you want certian graphics available
throughout the entire run of the program.

> Periodic events could be (& are) detected by using API SetTimer() or 
> polling time()
> (or something else) in the Idle section.

Correct, on Windows, you can do this, and on Linux, you can use the time()
feature.  HOWEVER.  One thing to remember, is that there is no idle section
in a single thread application.  I repeat, there is no idle section in a
single thread application.  I say that, cause the single thread is allways
being executed, until the application itself is terminated.

The reason WHY Windows API/Win32lib/wxEuphoria/Arwen/etc/etc libraries, do
not freeze up the whole system, and actually allow other proccesses to
do their things, is cause of the PeekMessage() function, or similar.

This is the equivelent of sleep(-1) in euphoria, if the sleep() function
actually took -1 as a value.  Cause in basic terms, your app is telling
windows, that your waiting for the user to do something, in order to
continue with the program.  So therefore, this is why I said, some time
ago, that Euphoria already has Multi-Threading capabilities, just not
the way we'd like them to be.  As in, being able to execute other code,
when the user isn't doing anything.

> When I was still learning Euphoria and programming I wrote one of the 
> earliest
> Windows-based editors. It had (has) syntax colouring and was (is) slow 
> loading
> documents. Perhaps this is one of the examples you have in mind when you 
> refer
> to "slowness, and non responsiveness". If I had to write one now all 
> these bad
> qualities etc would be gone since I now know much more now about 
> exploiting the
> power of Windows plus better programming technique. What I am getting at 
> is that
> my novice programming technique is not a legitmate argument against 
> single-threads
> (or in favour of multi-threads).
> 
> You suggest that only a multi-threaded app could "give speed to the 
> program that
>  wasn't there before" because the sheer volume of xfer data "would 
> always create a lag".
> Are you sure about this? Cooperating multiple processes are not the only 
> way to
> share data. In the single-threaded Win32 app any data "sharing" between 
> emulated
> threads can be as easy as "a=b".

As for the whole easy as "a=b" deal.  This may be true, but you run into one
big detail.  One VERY big detail.  If it's as easy as "a=b", write a program,
that can parse the entire Win32lib file, and convert it into a token format,
where Syntax Coloring can be applied by the front end, and actually display
it.  Like the Source Code Viewer in the Win32lib Demo directory.  I belive
it's ex13.exw.  Using any method of your choice, and see how fast, and how
far you can get with doing this method.  You can use whatever method for
exchanging the data between the Main proccess, and sub-proccess, as you
would like.  Then try to make it cross-platform compatable.  As in, it can
run just as it sits on both windows, and linux.

> > And speaking of Multi-Proccess arch, you come to another fault that 
> > comes with
> > said design.  And that's proper shutdown of all proccesses.  Should, by 
> > any chance
> > the user decides to use shared memory, in which to proccess anything, 
> > there would
> > be no way for the sub-proccesses of the program to know, if the main 
> > proccess was
> > killed, via kill pid on linux, or CTRL+ALT+DEL on windows.  TCP/IP 
> > communications
> > can help out with that, since all you have to do is detect a closing of 
> > the socket
> > on the oppisite end, and you can terminate based apon that.  But, 
> > there's still
> > things that can occur, such as crashing of the proccesses, that can't be 
> > detected
> > by the main proccess, or other problems, that effectivly ends the 
> > sub-proccess, but
> > leaves the main proccess running.

Yes, this one I wish to retract, cause we now have a feature, we didn't have
before.  But this is only useful in 2.5 of the interpreter.  And I do know
for a fact, that there are people out there, that still use the 2.4
Interpreter, and even the 2.3 Interpreter.

Since now, in 2.5, we have crash_routine(), we can setup a routine, to notify
the Main proccess, that an error has occured, and the sub-proccess has died.
In the same turn, the Main proccess, can notify all the sub-proccesses that
it has died, and it can "Clear out" the sub-proccess query.  So with that in
mind, I retract my previous statement about not being able to detect when a
sub-proccess, or main proccess crashes.

> > These are just some of the arguments, which could show that threads are 
> > indeed
> > better then sub-proccesses, and offer the programmer a easier way to 
> > manage his
> > code, without the need to write complex sub-proccess communiation, to 
> > account for
> > every possibility that could happen.
> > 
> > Mario Steele
> > <a
> > href="http://enchantedblade.trilake.net">http://enchantedblade.trilake.net</a>
> > Attaining World Dominiation, one byte at a time...
> 
> I think threads are better than sub-processes but I was hoping you'd 
> supply a real-life
> example of this superiority that *couldn't* be satisfactorily 
> accomodated using the
> above suggested model.
> 
> Regards,
> Mike

Real-Life example, alrighty.  How many Euphoria Developers, have actually
successfully created a popular 3D Intense Multi-Player Game?  And, when I
say that, I'm refering to games like Doom, Quake, EverQuest, Half-Life.  And
even then, in their most Simplistic of forms, not major forms.  How many
Euphoria programmers have successfully created Editor Programs, that can
match the speed of C/C++ Editors out there, in syntax highlighting speeds?
(True, Edita is very close, but it still lags on Win32lib, even on a 2.12GHz
proccessor, I know, cause I have tried it.)

And the main thing we need to remember here is, Not everyone uses Windows,
Some of us actually do use Linux (Recently Free'ed Pinguin here), and even
though we like the whole world to be on Linux, there are thoes out there,
that simply cannot handle Linux.  So, if we want to do anything with them,
we have to write cross-platform programs, that can run on both Windows,
and linux, without any trouble.  (As I'm currently doing)

We need to have the ability to do these kinds of things, with Euphoria,
that doesn't require us to have to re-invent the wheel to make it work,
and let alone, re-invent the wheel twice, to make it work on Windows, and
Linux.

One final note that I'd like to make, as this is actually, the perfect
real-life example, I think your looking for.  How many Libraries out there
can do MD5 Encryption, Blowfish Encryption, or any kind of Encryption
algorithim on the market, without resorting to using Assembly to speed it
up?

I'm more then certian, that multiple threads can be created, to
simultaniously proccess diffrent peices of data, and update the Encrypted
data, and key, in order, without messing it up, especially if your encrypting
LARGE files.

Does Sub-Proccess mean that it will be faster?  Depends on what your trying
to do.  Does Multi-Threading mean it will be faster?  Depends on what your
trying to do.  Does Single Thread mean it will be slow?  Depends on what
your trying to do.  Can Euphoria stand to not have Multi-Threading support
in it?  Very unlikely, even in the world today, where there are alot of
programs on the market, that heavily use Multi-Threading, to help boost
their performance.  (Just look at any Office Program, any Market, or
Open Source Project Game out there)

Mario Steele
http://enchantedblade.trilake.net
Attaining World Dominiation, one byte at a time...

4. RE: Threads [Was: Re: 64 bit euphoria]

• Posted by Mario Steele <eumario at trilake.net> Apr 25, 2005
• 447 views

Mike wrote:
> A file that requires a substantial amount of contiguous decoding *time* 
> may benefit by running in a separate thread so that the rest of the app 
> doesn't 'hang' for a bit. But, apart from action games or an Internet 
> browser when would this ever be a problem?

Let's see, Multimedia Applications, You don't honestly think Winamp is a
single thread program do you?  How about Windows media player, and it's
skinning capabilities?  Think that's a single thread system?

And honestly, do you think Microsoft Office honestly runs on a signle
stream arch?  If you do, load up Office, head to http://www.freshdevices.com
and grab their FreshDiagnose program, and see how many threads are being used
by Office in order to let it run, even for the simplistic of tasks.

How about the Euphoria interpreter itself?  How much of a speed boost would
it receive, if it used threaded setup for parsing files, and executing
statements?  If a threaded arch was put into the interpreter itself, it would
be next to the speed of an Actual C Program, and offer true execution on the
fly, as most interpreters do.

> Cross-platform compatibility is really a separate issue. So long as the 
> interface between app and xlibraries is the same then there is no 
> problem but it's up to the library writers to ensure this.

This is true, but still it's re-inventing the wheel, that allready exists
in C/C++ Programming, which is what the Euphoria interpreter is based after.

> Sure, on my <ahem> 0.15 GHz system there is a slight delay when loading 
> the file but this is a consequence of the direct programming technique 
> used. However, after a file has loaded the screen rendering code in 
> Edita executes (simultaneously) in the background. There is no technical 
> reason why loading a file (NOT using ReadFileEx()) in the background 
> can't be done in the same manner. Earlier, you suggested (nay, 
> challenged) that a Source Code Viewer, such as ex13.exw, could not be 
> developed [in Euphoria] having satisfactory speed. Obviously, it can be, 
> but it's success depends on whether each individual task can be 
> performed iteratively. In this case the answer must be yes as each line 
> can be processed individually.

Okay, this here is totally bias.  You honestly think that code parsing, and
code rendering is a simultaneously thing.  It isn't.  It is a single stream.
Whenever an instruction is being executed, that instruction blocks all other
instructions, till it is finished.

For example:

puts(1,"Hello ")
puts(1,"World")

This is not simultaneously executed, this is sequentially executed.  meaning
the first statement, puts(1,"Hello ") is executed, before puts(1,"World") is.
Even through using Win32 API, the Win32 API Can still receive events, and
such, cause that code is threaded.  But as far as Euphoria is concerned, when
interacting with said API, it can only proccess one event call at a time.
Meaning, that Euphoria doesn't proccess any Key Events (for example), during
a Paint Event, unless the User specifically Looks to see if there are any
key events to be proccessed.  Simultaneously execution means, that two
instructions can be executed at the same time.  That is threading, that's not
single thread.  Single thread is sequential execution.

Just because it happens in a matter of less then a millasecond, doesn't mean
that it's doing the instructions simultaniously, it just means that computer
is fast enough to successfully do this in a seemingly simultaniously method.

> If the algorithm is iterative (ie, not continuous) it can occur in the 
> background essentially seamlessly. If not then we have a problem. Sure, 
> ASM is used to boost the speed of many algorithms but mainly because 
> (interpreted) Euphoria is slow in comparison rather than to achieve an 
> appearance of concurrency.
> 
> Regards,
> Mike

Yes, interpreted Euphoria is slow, cause it's sequential.  Each instruction
at the proper placement.  Threads would allow for simultanious instruction
execution, in an enviroment that offers a safe way in which to do that with.
And correct me if I'm wrong Rob, that is your problem with Threads as they
are now, being able to determin which functions should be able to safely
be threaded, without screwing up the entire program, and causing alot of
un-nesscary instruction execution violations.  Personally, i think it depends
on one vital factor.  And that's the fact, of how simplistic you want to
make it, and how complex it can get.

We're oviously at a point in Euphoria's development, where there are alot of
people that want advance features, cause now they have a better hold of
Euphoria's feature set.  But we still have thoes that are new to the language,
and can cause serious harm to themselvs, trying to do the advance stuff,
without fully knowing the consiquences.

Mario Steele
http://enchantedblade.trilake.net
Attaining World Dominiation, one byte at a time...

6. RE: Threads [Was: Re: 64 bit euphoria]

• Posted by Mike <vulcan at win.co.nz> Apr 25, 2005
• 466 views
• Last edited Apr 26, 2005

Mario Steele wrote:
> 
> 
> posted by: Mario Steele <eumario at trilake.net>
> 
> Mike wrote:
> > A file that requires a substantial amount of contiguous decoding *time* 
> > may benefit by running in a separate thread so that the rest of the app 
> > doesn't 'hang' for a bit. But, apart from action games or an Internet 
> > browser when would this ever be a problem?
> 
> Let's see, Multimedia Applications, You don't honestly think Winamp is a
> single thread program do you?  How about Windows media player, and it's
> skinning capabilities?  Think that's a single thread system?

Those sorts of apps require a Device Driver to largely take care of the 
concurrency requirements. Writing a Device Driver in Euphoria would be 
extremely difficult but invoking one from Euphoria is not. Unless you 
think that Euphoria can be "all things to everyone" it may be best to 
limit the arguments to what is likely to be practical, though, I am not 
suggesting I wouldn't like Euphoria to suit a greater range of 
applications.

> How about the Euphoria interpreter itself?  How much of a speed boost 
> would
> it receive, if it used threaded setup for parsing files, and executing
> statements?  If a threaded arch was put into the interpreter itself, it 
> would
> be next to the speed of an Actual C Program, and offer true execution on 
> the
> fly, as most interpreters do.

If this is true then Rob, who is an expert programmer, has overlooked an 
excellent way to boost the performance of what may be the fastest 
interpreter in the world.
interpreter is based after.

> Okay, this here is totally bias.  You honestly think that code parsing, 
> and
> code rendering is a simultaneously thing.  It isn't.  It is a single 
> stream.
> Whenever an instruction is being executed, that instruction blocks all 
> other
> instructions, till it is finished.

> Even through using Win32 API, the Win32 API Can still receive events, 
> and
> such, cause that code is threaded.  But as far as Euphoria is concerned, 
> when
> interacting with said API, it can only proccess one event call at a 
> time.
> Meaning, that Euphoria doesn't proccess any Key Events (for example), 
> during
> a Paint Event, unless the User specifically Looks to see if there are 
> any
> key events to be proccessed.  Simultaneously execution means, that two
> instructions can be executed at the same time.  That is threading, 
> that's not
> single thread.  Single thread is sequential execution.
> 
> Just because it happens in a matter of less then a millasecond, doesn't 
> mean
> that it's doing the instructions simultaniously, it just means that 
> computer
> is fast enough to successfully do this in a seemingly simultaniously 
> method.

Under the heading of "Multitasking" the Win32 help document I have 
notes: 

<QUOTE>

A multitasking operating system divides the available processor time 
among the processes or threads that need it. Windows is designed for 
preemptive multitasking; it allocates a processor time slice to each 
thread it executes. The currently executing thread is suspended when its 
time slice elapses, allowing another thread to run. When the system 
switches from one thread to another, it saves the context of the 
preempted thread and restores the saved context of the next thread in 
the queue. 

The length of the time slice depends on the operating system and the 
processor. Because each time slice is small (approximately 20 
milliseconds), multiple threads appear to be executing at the same time. 
This is actually the case on multiprocessor systems, where the 
executable threads are distributed among the available processors. 
However, you must use caution when using multiple threads in an 
application, because system performance can decrease if there are too 
many threads.

<ENDQUOTE>

In other words, true simultaneous execution only occurs where there are 
two or more processors. Where there is one CPU the threading only 
appears to execute simultaneously. The background process in Edita 
mimics the latter model by setting a time slice for the (iterative) 
process. If you can assert that threads in a single-CPU are executing 
simultaneously then surely I can do the same for Edita since the basic 
principle is essentially the same.

Regards,
Mike