1. RE: Threads [Was: Re: 64 bit euphoria]
- Posted by Mike <vulcan at win.co.nz> Apr 24, 2005
- 475 views
Mario, In your consideration of this issue have you reckoned on the ability of Win32 apps to emulate threads? Some Windows libraries have a background processing capability that can be used to mimic a multi-threaded process. However, the granularity of each operation would be coarser. Mario Steele wrote: > > > Currently, if you need to load a bunch of graphics, your not gonna be > able to > do a whole lot of other things, till all of thoes graphics are loaded > up. > Even to let the user know that your loading up graphics, you have to > write your > loading routine around the idea of having to display a progress bar each > time > you load up a graphic into memory, so they know the game hasn't frozen > on them. 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.) > Game events is another problem..to manage multiple events, such as Enemy > AI, > special events that need to occur at a certian interval, or at a certian > point > in the game. That's not also considering all the networking that may be > involved. Periodic events could be (& are) detected by using API SetTimer() or polling time() (or something else) in the Idle section. > Switching to a diffrent aspect, instead of games, moving to a Office > use, so to > say, basic editors even use threads. Especially thoes that require > special > rendering, such as HTML, or syntax Highlighting, such as Code editors. > Right now > in Euphoria, if you have to write a Syntax Highlighter, customly, you > have to do > it when the user loads the document. And that has been prone to > slowness, and non > responsiveness of the program in the past. > > Taking the fact of Writting a Custom Syntax Highligher, such as Syntax2 > by Don > Phillps. The library has to load up the Source code, then parse it, > searching for > keywords, and identifying them, then applying the color codes to each > part it > finds. That's just with loading the document. Then you have to render > it to > screen, which proccesses the parsed information, making the appropriate > points displayed. Along with that, there's mathmatical expressions that > need to be > evaluated, such as where the user is currently scrolled to, where each > word should > be placed on the "Virtual" document based on the scroll, and the line > data, > as well, as the color to be using at that said time. > > All of this alone just for syntax coloring. This doesn't include the > fact that > you need to process the user's input, as they enter it, looking for new > keywords, > based on what line, and what data comes before the user's new input. > All of this > contributes to slowing down the entire application in a single thread > ideal. But > should you design it for a Multi-Thread idea, you can have 1 thread > proccessing the > syntax coloring, 1 thread proccessing the rendering of the buffer to > screen, and > one thread to handle all of the user's input. This can give speed to > the program > that wasn't there before, and can't be done through multi-proccesses, > cause of > the fact, of the ammount of data that would need to be passed through > shared > memory, or through TCP/IP, it would always create a lag. Not to mention > the fact > that it's next to impossible to pass buffer drawings in between > proccesses, since, > like memory, would always have a diffrent address. 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". > 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. This argument doesn't affect the single-threaded single-process model. > 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 > http://enchantedblade.trilake.net > 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
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...
3. RE: Threads [Was: Re: 64 bit euphoria]
- Posted by Mike <vulcan at win.co.nz> Apr 25, 2005
- 448 views
Mario, I think threads do have their programming niche but the vast majority of apps don't need them, eg: www.cs.utah.edu/~regehr/research/ouster.pdf > posted by: Mario Steele <eumario at trilake.net> > > 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. 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? > Then try to make it cross-platform compatable. As in, it can > run just as it sits on both windows, and linux. 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. > > 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 > >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.) 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. > 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? 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
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...
5. RE: Threads [Was: Re: 64 bit euphoria]
- Posted by "Kat" <gertie at visionsix.com> Apr 25, 2005
- 454 views
- Last edited Apr 26, 2005
On 25 Apr 2005, at 3:43, Mario Steele wrote: <snip> > 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. The problem is: the entire OS (and everything in/on/under it) is sequential and timesliced. Threads in Eu would eliminate the blocking action of the Eu app not getting anything done until the OS returns control to it, because the OS would effectively see more than one Eu app. The primary app would launch more "apps" with specialized control over them (see Al Getz's windows server). So RobC's assertion (and mine, to a certain limit) is: we can do more than one Eu app now, controlling the "sub app threads" with the memshare msg passing libs or sockets or etc. Granted this is more complicated for the programmer until a reuseable framework for it is built. Also unnoticed is the option for linking multiple machines running different OSs. With more than one i86 cpu core per "chip" coming out soon (and people think that is new??), separate apps may be much faster than true threads. Your mileage may vary, Kat
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
7. RE: Threads [Was: Re: 64 bit euphoria]
- Posted by jacques deschĂȘnes <desja at globetrotter.net> Apr 26, 2005
- 467 views
About threads I would add those points: 1) It's not because euphoria would be threads enabled that someone as to use this feature. If one only needs a single thread app, it could write it anyway. The point is not to have un multithread interpreter but to have a multi-thread enabled interpreter (one that enable us to write multithread app). 2) If it's true that a single processor can run only thread at a time. Threads are still usefull to go around blocking procedures. 3) If one open task magager and goes to the processes tab and configure it to display the number of theards per processes it would see that single thread processes are indeed very few. In fact on my system, without any program running, on 26 processes running only 1 is single threads. I don't think that all those programs where written multi-threads just for the fun of it. regards, Jacques D.