1. 64 bit euphoria
- Posted by codepilot Gmail Account <codepilot at gmail.com> Apr 20, 2005
- 495 views
Has anyone been considering porting euphoria to 64 bit yet? I'm getting an Opteron system soon, and think it would be an awful waste to use it in 32-bit mode. Daniel
2. Re: 64 bit euphoria
- Posted by CoJaBo <CoJaBo_7th_EUforum_Address at CJBN.net> Apr 20, 2005
- 471 views
codepilot Gmail Account wrote: > > Has anyone been considering porting euphoria to 64 bit yet? I'm > getting an Opteron system soon, and think it would be an awful waste > to use it in 32-bit mode. I have an Athlon 64 and it would be nice to use it in 64-bit mode. Another question: is it possible to even use 64-bit programs in Win XP 32(I have a program "Athlon 64 processor driver" installed, but I don't know what it is actully for), or do I have to use a 64-bit OS? > Daniel > >
3. Re: 64 bit euphoria
- Posted by codepilot Gmail Account <codepilot at gmail.com> Apr 20, 2005
- 478 views
You have to get a 64-bit os to do anything 64-bit. I wonder if a 64-bit dos version of EU is possible. On 4/19/05, CoJaBo <guest at rapideuphoria.com> wrote: > > posted by: CoJaBo <CoJaBo_7th_EUforum_Address at CJBN.net> > > codepilot Gmail Account wrote: > > > > Has anyone been considering porting euphoria to 64 bit yet? I'm > > getting an Opteron system soon, and think it would be an awful waste > > to use it in 32-bit mode. > > I have an Athlon 64 and it would be nice to use it in 64-bit > mode. > Another question: is it possible to even use 64-bit programs > in Win XP 32(I have a program "Athlon 64 processor driver" > installed, but I don't know what it is actully for), or do I > have to use a 64-bit OS? > > > Daniel > > > > > > > > >
4. Re: 64 bit euphoria
- Posted by Alexander Toresson <alexander.toresson at gmail.com> Apr 20, 2005
- 473 views
Regards, Alexander Toresson
5. Re: 64 bit euphoria
- Posted by Alexander Toresson <alexander.toresson at gmail.com> Apr 20, 2005
- 469 views
codepilot Gmail Account wrote: > > You have to get a 64-bit os to do anything 64-bit. I wonder if a > 64-bit dos version of EU is possible. > LOL! 64-bit DOS! Best joke I've heard in a while. Notice that you just said "You have to get a 64-bit os to do anything 64-bit". Anyway, about 64-bit euphoria. There has to be at least 2 versions of it. There is a big difference between 64-bit code in an Athlon 64 and Intel's IA-64 architecture. And a question to RobC: Is the sequence operations etc written in asm or in C? If they are written in C, it'd be quite easy to compile for 64-bit architectures. If it's asm, it'd have to be rewritten. Regards, Alexander Toresson
6. Re: 64 bit euphoria
- Posted by Robert Craig <rds at RapidEuphoria.com> Apr 20, 2005
- 472 views
Alexander Toresson wrote: > codepilot Gmail Account wrote: > > > > You have to get a 64-bit os to do anything 64-bit. I wonder if a > > 64-bit dos version of EU is possible. > > > > LOL! 64-bit DOS! Best joke I've heard in a while. > Notice that you just said "You have to get a 64-bit os to do anything 64-bit". > > Anyway, about 64-bit euphoria. There has to be at least 2 versions of it. > There is > a big difference between 64-bit code in an Athlon 64 and Intel's IA-64 > architecture. > > And a question to RobC: Is the sequence operations etc written in asm or in C? > If they > are written in C, it'd be quite easy to compile for 64-bit architectures. If > it's asm, > it'd have to be rewritten. There is hardly any asm in the Euphoria interpreter. The front-end is written in Euphoria. The back-end is 99.9% C. integers would likely become 63 bits instead of 31. That could lead to some small compatibility issues, e.g. if integer(x) then ... might have a different meaning. It would probably not bother many people if a simple declaration of: integer x now allowed x to be 63 bits in size. The use of 64-bit pointers internally by the interpreter would probably not disturb most Euphoria programs. It would just allow much larger sequences to be created. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
7. Re: 64 bit euphoria
- Posted by codepilot Gmail Account <codepilot at gmail.com> Apr 20, 2005
- 464 views
On 4/20/05, Alexander Toresson <guest at rapideuphoria.com> wrote: > > posted by: Alexander Toresson <alexander.toresson at gmail.com> > > codepilot Gmail Account wrote: > > > > You have to get a 64-bit os to do anything 64-bit. I wonder if a > > 64-bit dos version of EU is possible. > > > > LOL! 64-bit DOS! Best joke I've heard in a while. I thought I would get some laughs > Notice that you just said "You have to get a 64-bit os to do anything 64-= bit". You have to have a 32-bit os to run 32-bit programs too, in dos it uses causeway 32-bit extender, I was curious if there was a 64-bit extender, that would work on top of 16-bit dos. Dan > > Anyway, about 64-bit euphoria. There has to be at least 2 versions of it.= There is a big difference between 64-bit code in an Athlon 64 and Intel's = IA-64 architecture. > > And a question to RobC: Is the sequence operations etc written in asm or = in C? If they are written in C, it'd be quite easy to compile for 64-bit ar= chitectures. If it's asm, it'd have to be rewritten. > > Regards, Alexander Toresson > > > > >
8. Re: 64 bit euphoria
- Posted by codepilot Gmail Account <codepilot at gmail.com> Apr 20, 2005
- 462 views
What would I need to port it? On 4/20/05, Robert Craig <guest at rapideuphoria.com> wrote: > > posted by: Robert Craig <rds at RapidEuphoria.com> > > Alexander Toresson wrote: > > codepilot Gmail Account wrote: > > > > > > You have to get a 64-bit os to do anything 64-bit. I wonder if a > > > 64-bit dos version of EU is possible. > > > > > > > LOL! 64-bit DOS! Best joke I've heard in a while. > > Notice that you just said "You have to get a 64-bit os to do anything 6= 4-bit". > > > > Anyway, about 64-bit euphoria. There has to be at least 2 versions of i= t. There is > > a big difference between 64-bit code in an Athlon 64 and Intel's IA-64 = architecture. > > > > And a question to RobC: Is the sequence operations etc written in asm o= r in C? If they > > are written in C, it'd be quite easy to compile for 64-bit architecture= s. If it's asm, > > it'd have to be rewritten. > > There is hardly any asm in the Euphoria interpreter. > The front-end is written in Euphoria. > The back-end is 99.9% C. integers would likely become 63 bits > instead of 31. That could lead to some small compatibility issues, > e.g. > if integer(x) then ... > might have a different meaning. > > It would probably not bother many people if a > simple declaration of: > integer x > now allowed x to be 63 bits in size. > > The use of 64-bit pointers internally by the interpreter > would probably not disturb most Euphoria programs. > It would just allow much larger sequences to be created. > > Regards, > Rob Craig > Rapid Deployment Software > http://www.RapidEuphoria.com > > > > >
9. Re: 64 bit euphoria
- Posted by Matt Lewis <matthewwalkerlewis at gmail.com> Apr 20, 2005
- 493 views
codepilot Gmail Account wrote: > > What would I need to port it? > First, a 64-bit OS. There are 64-bit versions of Windows and Linux. Then, you'd need the Euphoria source code and a compiler. You could obviously use gcc in 64-bit linux, but I'm not sure what compilers there are to support windows. I believe Intel has one, and, of course, MS must, as well. As mentioned, you'd have to make sure that it matches your architecture, because IA-64 isn't the same as AMD's 64-bit architecture. Matt Lewis
10. Re: 64 bit euphoria
- Posted by "Elliott S. de Andrade" <quantum_analyst at hotmail.com> Apr 20, 2005
- 472 views
- Last edited Apr 21, 2005
>From: Alexander Toresson <guest at RapidEuphoria.com> >Reply-To: EUforum at topica.com >To: EUforum at topica.com >Subject: Re: 64 bit euphoria >Date: Wed, 20 Apr 2005 07:55:46 -0700 > >posted by: Alexander Toresson <alexander.toresson at gmail.com> > >Anyway, about 64-bit euphoria. There has to be at least 2 versions of it. >There is a big difference between 64-bit code in an Athlon 64 and Intel's >IA-64 architecture. > Fortunately, I don't think you do. Intel's Itanium (aka IA-64) is mainly a server processor and it's pretty much just fizzled. Intel's new EMT64 (which is on the new Prescotts) is compatible with AMD's x86-64, so you don't need another version for it. > >Regards, Alexander Toresson > ~[ WingZone ]~ http://wingzone.tripod.com/
11. Re: 64 bit euphoria
- Posted by jxliv7 <jxliv7 at hotmail.com> Apr 21, 2005
- 470 views
as early as August 2002 and even August 2003 i asked Rob if he was going to support the AMD 64 bit machines (search "64 bit"). the answer was basically no. since then, i not only put together an AMD64 and saw the fantastic growth of AMD's 64 bit CPUs, but i watched the IA64 fail. more AMD 64 bit chips were sold last year than the IA64 in its entire history. because AMD64's are offered in the older socket 754 and the newer 939 socket and motherboards are priced as low as $70, plus the fact the CPU can run on a 32 bit or 64 bit OS, the are now lots of AND64 machines out there. to compile for the AMD64 is relatively easy with any "-nix" box, Linux or FreeBSD and GCC have been 64 bit for a long time (and GCC is available for Windows). Window1's 64 bit beta versions (XP Pro and Server 2003) are excellent, and the gold versions should be release within days. Rob is correct that there is relatively little work to convert Euphoria to 64 bit. but to take full advantage of the registers and word lengths, etc., is beyond my simple knowledge and experience at this point. i would like to try, anyway, and if anyone wants to team up, let me know. the future is 64 bit, and the faster Euphoria can run true 64 bit apps, the better off Euphoria will be. come on, Rob. by the way, my letter about Euphoria was published in the April 2004 issue of "Nuts & Volts". i hope it's helped Euphoria, Rob. progressively, -- jon
12. Re: 64 bit euphoria
- Posted by Kenneth Rhodes <wolf_man_jacques at excite.com> Apr 22, 2005
- 476 views
- Last edited Apr 23, 2005
Robert Craig wrote: > > There is hardly any asm in the Euphoria interpreter. > The front-end is written in Euphoria. > The back-end is 99.9% C. integers would likely become 63 bits > instead of 31. That could lead to some small compatibility issues, > e.g. > if integer(x) then ... > might have a different meaning. > > It would probably not bother many people if a > simple declaration of: > integer x > now allowed x to be 63 bits in size. > > The use of 64-bit pointers internally by the interpreter > would probably not disturb most Euphoria programs. > It would just allow much larger sequences to be created. Just how big of a performance hit would the interpreter take if that 1% of the front-end code was written in C? I believe that most, if not all, of the 64 bit processors will run at clock speeds exceeding 2Ghz which is probably about X50 faster than when Euphoria was first released. If the interpreter's speed is not throttled drastically, it might be just as appealing for development and would make the faster translated/compiled option an even more attractive purchase. Also, it seems that hence forth the 64bit cpus will multi-core, so shouldn't threads be a "must" feature for the next version of Euphoria? Ken Rhodes 100% Microsoft Free!
13. Re: 64 bit euphoria
- Posted by Daniel Kluss <codepilot at gmail.com> Apr 22, 2005
- 464 views
- Last edited Apr 23, 2005
Kenneth Rhodes wrote: > > Robert Craig wrote: > > > > > There is hardly any asm in the Euphoria interpreter. > > The front-end is written in Euphoria. > > The back-end is 99.9% C. integers would likely become 63 bits > > instead of 31. That could lead to some small compatibility issues, > > e.g. > > if integer(x) then ... > > might have a different meaning. > > > > It would probably not bother many people if a > > simple declaration of: > > integer x > > now allowed x to be 63 bits in size. > > > > The use of 64-bit pointers internally by the interpreter > > would probably not disturb most Euphoria programs. > > It would just allow much larger sequences to be created. > > Just how big of a performance hit would the interpreter take > if that 1% of the front-end code was written in C? > > I believe that most, if not all, of the 64 bit processors will > run at clock speeds exceeding 2Ghz which is probably about X50 > faster than when Euphoria was first released. If the interpreter's > speed is not throttled drastically, it > might be just as appealing for development and would make > the faster translated/compiled option an even more attractive > purchase. > > Also, it seems that hence forth the 64bit cpus will multi-core, > so shouldn't threads be a "must" feature for the next version of > Euphoria? The threads should definetly be a must, real threads, not simulated threads. Dan > > > Ken Rhodes > 100% Microsoft Free! >
14. Re: 64 bit euphoria
- Posted by Jason Gade <jaygade at yahoo.com> Apr 22, 2005
- 471 views
- Last edited Apr 23, 2005
Kenneth Rhodes wrote: > > Robert Craig wrote: > > > > > There is hardly any asm in the Euphoria interpreter. > > The front-end is written in Euphoria. > > The back-end is 99.9% C. integers would likely become 63 bits > > instead of 31. That could lead to some small compatibility issues, > > e.g. > > if integer(x) then ... > > might have a different meaning. > > > > It would probably not bother many people if a > > simple declaration of: > > integer x > > now allowed x to be 63 bits in size. > > > > The use of 64-bit pointers internally by the interpreter > > would probably not disturb most Euphoria programs. > > It would just allow much larger sequences to be created. > > Just how big of a performance hit would the interpreter take > if that 1% of the front-end code was written in C? I think some of the assembly is the callback code, isn't it? For X86-64 (or AMD-64 or whatever you want to call it) I don't think that porting it would be too difficult. > > I believe that most, if not all, of the 64 bit processors will > run at clock speeds exceeding 2Ghz which is probably about X50 > faster than when Euphoria was first released. If the interpreter's > speed is not throttled drastically, it > might be just as appealing for development and would make > the faster translated/compiled option an even more attractive > purchase. Processors already go >2GHz. Do we really need so much extra performance, though? * 64-bit OS's are still not mainstream although they are coming. * 64-bit OS's will still run 32-bit software for the forseeable future. * We will still be using 32-bit computers and OS's for many years to come. > > Also, it seems that hence forth the 64bit cpus will multi-core, > so shouldn't threads be a "must" feature for the next version of > Euphoria? Threads and 64-bitness would be okay but I think that Euphoria has other, more pressing needs. Maybe a 64-bit translator could be another value-added proposition for RDS. One thing that I have noticed is that RDS is very careful with changes made to the language. I know that it has frustrated many developers that it has not moved beyond a "beginner's" language. Whether that is by design or not I don't know. > > > Ken Rhodes > 100% Microsoft Free! > ===================================== Too many freaks, not enough circuses. j.
15. Re: 64 bit euphoria
- Posted by cklester <cklester at yahoo.com> Apr 22, 2005
- 467 views
- Last edited Apr 23, 2005
Jason Gade wrote: > > One thing that I have noticed is that RDS is very careful with changes made to > the > language. I know that it has frustrated many developers that it has not moved > beyond > a "beginner's" language. Whether that is by design or not I don't know. It's more than just a beginner's language. It's also a professional language. So, I guess it covers both points of that spectrum. ;) -=ck "Programming in a state of EUPHORIA." http://www.cklester.com/euphoria/
16. Re: 64 bit euphoria
- Posted by Jason Gade <jaygade at yahoo.com> Apr 22, 2005
- 463 views
- Last edited Apr 23, 2005
cklester wrote: > > Jason Gade wrote: > > > > One thing that I have noticed is that RDS is very careful with changes made > > to the > > language. I know that it has frustrated many developers that it has not > > moved beyond > > a "beginner's" language. Whether that is by design or not I don't know. > > It's more than just a beginner's language. It's also a professional language. > So, I guess it covers both points of that spectrum. ;) I understand what you are saying, and I kind of agree, but I also kind of disagree. I know that professional apps have been written with Euphoria. I also know that a lot of "professionals" (I'm actually only an amateur) take a look at it and consider it a toy. Or like some people they use it for awhile and then move on when things aren't changed to their liking, right or wrong. > > -=ck > "Programming in a state of EUPHORIA." > <a > href="http://www.cklester.com/euphoria/">http://www.cklester.com/euphoria/</a> > ===================================== Too many freaks, not enough circuses. j.
17. Re: 64 bit euphoria
- Posted by Jason Gade <jaygade at yahoo.com> Apr 22, 2005
- 473 views
- Last edited Apr 23, 2005
Jason Gade wrote: > > cklester wrote: > > > > Jason Gade wrote: > > > > > > One thing that I have noticed is that RDS is very careful with changes > > > made to the > > > language. I know that it has frustrated many developers that it has not > > > moved beyond > > > a "beginner's" language. Whether that is by design or not I don't know. > > > > It's more than just a beginner's language. It's also a professional > > language. > > So, I guess it covers both points of that spectrum. ;) > > I understand what you are saying, and I kind of agree, but I also kind of > disagree. > > I know that professional apps have been written with Euphoria. I also know > that a > lot of "professionals" (I'm actually only an amateur) take a look at it and > consider > it a toy. > > Or like some people they use it for awhile and then move on when things aren't > changed > to their liking, right or wrong. > > > > > -=ck > > "Programming in a state of EUPHORIA." > > <a > > href="http://www.cklester.com/euphoria/">http://www.cklester.com/euphoria/</a> > > But my *real* point is that while threading and 64-bit are pretty cool there are other improvements that Euphoria could use. > > > ===================================== > Too many freaks, not enough circuses. > > j. > ===================================== Too many freaks, not enough circuses. j.
18. Re: 64 bit euphoria
- Posted by Robert Craig <rds at RapidEuphoria.com> Apr 22, 2005
- 459 views
- Last edited Apr 23, 2005
Kenneth Rhodes wrote: > Robert Craig wrote: > > > > There is hardly any asm in the Euphoria interpreter. > > The front-end is written in Euphoria. > > The back-end is 99.9% C. integers would likely become 63 bits > > instead of 31. That could lead to some small compatibility issues, > > e.g. > > if integer(x) then ... > > might have a different meaning. > > > > It would probably not bother many people if a > > simple declaration of: > > integer x > > now allowed x to be 63 bits in size. > > > > The use of 64-bit pointers internally by the interpreter > > would probably not disturb most Euphoria programs. > > It would just allow much larger sequences to be created. > > Just how big of a performance hit would the interpreter take > if that 1% of the front-end code was written in C? By "1% of the front-end code", I assume you mean "0.1% of the back-end code". The main use of asm is for things that can't be expressed in C, such as pushing values onto a machine-level stack, not so much for speed. There would be little point in trying to eliminate the few lines of asm. It's just a minor nuisance in porting and understanding the code. > Also, it seems that hence forth the 64bit cpus will multi-core, > so shouldn't threads be a "must" feature for the next version of > Euphoria? My main concern with threads isn't how to implement them, it's what are people going to do with them? Can any of the pro-thread people give some examples (that couldn't easily be done some other way, such as the Language Wars technique, or simply using multiple processes communicating via shared memory)? Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
19. Re: 64 bit euphoria
- Posted by Daniel Kluss <codepilot at gmail.com> Apr 22, 2005
- 457 views
- Last edited Apr 23, 2005
Jason Gade wrote: > > Jason Gade wrote: > > > > cklester wrote: > > > > > > Jason Gade wrote: > > > > > > > > One thing that I have noticed is that RDS is very careful with changes > > > > made to the > > > > language. I know that it has frustrated many developers that it has not > > > > moved beyond > > > > a "beginner's" language. Whether that is by design or not I don't know. > > > > > > It's more than just a beginner's language. It's also a professional > > > language. > > > So, I guess it covers both points of that spectrum. ;) > > > > I understand what you are saying, and I kind of agree, but I also kind of > > disagree. > > > > I know that professional apps have been written with Euphoria. I also know > > that a > > lot of "professionals" (I'm actually only an amateur) take a look at it and > > consider > > it a toy. > > > > Or like some people they use it for awhile and then move on when things > > aren't changed > > to their liking, right or wrong. > > > > > > > > -=ck > > > "Programming in a state of EUPHORIA." > > > <a > > > href="http://www.cklester.com/euphoria/">http://www.cklester.com/euphoria/</a> > > > > > But my *real* point is that while threading and 64-bit are pretty cool there > are other > improvements that Euphoria could use. > One improvement that would be great, and I think has been promised is to add a suggested improvement section to the euphoria web site, so we can all see the suggested improvements, why not to do some, and why to do others, and status on them. This is a MUST improvement. Dan > > > > > ===================================== > > Too many freaks, not enough circuses. > > > > j. > > > > ===================================== > Too many freaks, not enough circuses. > > j. >
20. Re: 64 bit euphoria
- Posted by Jason Gade <jaygade at yahoo.com> Apr 22, 2005
- 479 views
- Last edited Apr 23, 2005
Daniel Kluss wrote: > > Jason Gade wrote: > > But my *real* point is that while threading and 64-bit are pretty cool there > > are other > > improvements that Euphoria could use. > > > One improvement that would be great, and I think has been promised is > to add a suggested improvement section to the euphoria web site, so > we can all see the suggested improvements, why not to do some, and why to > do others, and status on them. > This is a MUST improvement. > Dan I think some kind of suggestion page, with a polling system similar to the microeconomy, would be a great idea. I don't think that Euphoria needs a *lot* of new features. I agree with the generally conservative direction of the language. But there are some features that could be added and some design decisions that could be changed without ruining the simplicity and orthoganality of the language. * A better way to handle namespaces, the include "bug", and modularity. * Forward referencing for routine_id(). * Implement the optimization for the case where x = foo(x) to make up for lack of modifying pass-by-reference variables. Probably lots of others, but these are off the top of my head, and probably the least controversial. Of course, there is the list of more controversial features... ===================================== Too many freaks, not enough circuses. j.
21. Re: 64 bit euphoria
- Posted by jacques deschênes <desja at globetrotter.net> Apr 23, 2005
- 458 views
Robert Craig wrote: > > Kenneth Rhodes wrote: > > Robert Craig wrote: > > > > > > There is hardly any asm in the Euphoria interpreter. > > > The front-end is written in Euphoria. > > > The back-end is 99.9% C. integers would likely become 63 bits > > > instead of 31. That could lead to some small compatibility issues, > > > e.g. > > > if integer(x) then ... > > > might have a different meaning. > > > > > > It would probably not bother many people if a > > > simple declaration of: > > > integer x > > > now allowed x to be 63 bits in size. > > > > > > The use of 64-bit pointers internally by the interpreter > > > would probably not disturb most Euphoria programs. > > > It would just allow much larger sequences to be created. > > > > Just how big of a performance hit would the interpreter take > > if that 1% of the front-end code was written in C? > > By "1% of the front-end code", > I assume you mean "0.1% of the back-end code". > > The main use of asm is for things that can't be expressed in C, > such as pushing values onto a machine-level stack, > not so much for speed. There would be little point in trying > to eliminate the few lines of asm. It's just a minor nuisance > in porting and understanding the code. > > > Also, it seems that hence forth the 64bit cpus will multi-core, > > so shouldn't threads be a "must" feature for the next version of > > Euphoria? > > My main concern with threads isn't how to implement them, > it's what are people going to do with them? Can any of the > pro-thread people give some examples (that couldn't easily be done > some other way, such as the Language Wars technique, or simply > using multiple processes communicating via shared memory)? > > Regards, > Rob Craig > Rapid Deployment Software > <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a> > 1) threads inside the same process take less resources than 2 processes communicating. 2) a thread switching is faster (more efficient) than a context (process) switching. 3) One obvious usage of threads is to get a more responsive applications. I hate those situation where the application doesn't answer to mouse click (keypress) because it's caugth in a waiting loop for some network resource or something else. So when the application is designed with a thread for the user interface and a thread for others cores, the user interface keep responding. 4) why to bother designing threads machanics inside the application when it already exist in the operating system in a more flexible an efficient way. regards, Jacques Deschenes
22. Re: 64 bit euphoria
- Posted by Daniel Kluss <codepilot at gmail.com> Apr 23, 2005
- 455 views
Robert Craig wrote: > > Kenneth Rhodes wrote: > > Robert Craig wrote: > > > > > > There is hardly any asm in the Euphoria interpreter. > > > The front-end is written in Euphoria. > > > The back-end is 99.9% C. integers would likely become 63 bits > > > instead of 31. That could lead to some small compatibility issues, > > > e.g. > > > if integer(x) then ... > > > might have a different meaning. > > > > > > It would probably not bother many people if a > > > simple declaration of: > > > integer x > > > now allowed x to be 63 bits in size. > > > > > > The use of 64-bit pointers internally by the interpreter > > > would probably not disturb most Euphoria programs. > > > It would just allow much larger sequences to be created. > > > > Just how big of a performance hit would the interpreter take > > if that 1% of the front-end code was written in C? > > By "1% of the front-end code", > I assume you mean "0.1% of the back-end code". > > The main use of asm is for things that can't be expressed in C, > such as pushing values onto a machine-level stack, > not so much for speed. There would be little point in trying > to eliminate the few lines of asm. It's just a minor nuisance > in porting and understanding the code. > > > Also, it seems that hence forth the 64bit cpus will multi-core, > > so shouldn't threads be a "must" feature for the next version of > > Euphoria? > > My main concern with threads isn't how to implement them, > it's what are people going to do with them? Can any of the > pro-thread people give some examples (that couldn't easily be done > some other way, such as the Language Wars technique, or simply > using multiple processes communicating via shared memory)? > Well the main argument for threads is multiple simultaneous operations, and in windows, not having to wait for blocking API functions. Multiple processes with shared memory do provide that, but there is alot of startup delay with each new process and not with threads. That the story I think. Dan > Regards, > Rob Craig > Rapid Deployment Software > <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a> >
23. Re: 64 bit euphoria
- Posted by Jason Gade <jaygade at yahoo.com> Apr 23, 2005
- 485 views
jacques deschênes wrote: > > Robert Craig wrote: > > > > Kenneth Rhodes wrote: > > > Also, it seems that hence forth the 64bit cpus will multi-core, > > > so shouldn't threads be a "must" feature for the next version of > > > Euphoria? > > > > My main concern with threads isn't how to implement them, > > it's what are people going to do with them? Can any of the > > pro-thread people give some examples (that couldn't easily be done > > some other way, such as the Language Wars technique, or simply > > using multiple processes communicating via shared memory)? > > > > Regards, > > Rob Craig > > Rapid Deployment Software > > <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a> > > > > 1) threads inside the same process take less resources than 2 processes > communicating. True, but how much does this affect current hardware/software(OS's)? > 2) a thread switching is faster (more efficient) than a context (process) > switching. See above question -- is it really an issue? *nixes preferred heavy processes over threads for a long time. I read something comparing *nix threads vs. processes and there wasn't that big a difference between the two. > > 3) One obvious usage of threads is to get a more responsive applications. I > hate > those situation where the application doesn't answer to mouse click (keypress) > > because it's caugth in a waiting loop for some network resource or something > else. > So when the application is designed with a thread for the user interface and a > thread for others cores, the user interface keep responding. Couldn't this be done with callbacks? In modern OS's, how many API calls are blocking calls versus taking a callback? > > 4) why to bother designing threads machanics inside the application when it > already exist in the operating system in a more flexible an efficient way. Of course the OS needs to support it, but the application (Euphoria) would still need to have infrastructure for starting new threads and synchronization/locking for global resources. Otherwise someone could just write a library using the existing infrastructure. Wouldn't much of the interpreter/translator have to be rewritten to be reentrant as well? > > regards, > Jacques Deschenes > ===================================== Too many freaks, not enough circuses. j.
24. Re: 64 bit euphoria
- Posted by Daniel Kluss <codepilot at gmail.com> Apr 23, 2005
- 502 views
Jason Gade wrote: > > jacques deschênes wrote: > > > > Robert Craig wrote: > > > > > > Kenneth Rhodes wrote: > > > > Also, it seems that hence forth the 64bit cpus will multi-core, > > > > so shouldn't threads be a "must" feature for the next version of > > > > Euphoria? > > > > > > My main concern with threads isn't how to implement them, > > > it's what are people going to do with them? Can any of the > > > pro-thread people give some examples (that couldn't easily be done > > > some other way, such as the Language Wars technique, or simply > > > using multiple processes communicating via shared memory)? > > > > > > Regards, > > > Rob Craig > > > Rapid Deployment Software > > > <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a> > > > > > > > 1) threads inside the same process take less resources than 2 processes > > communicating. > > True, but how much does this affect current hardware/software(OS's)? Well threading would be faster, buit people have argued that the 386 is all anyone should ever need. Shoot with todays manufacturing process(90nm), the 386 would probably be too small to see, and super cheap.(hmm multicore(like 1000 of them) 386 is a good thing) > > > 2) a thread switching is faster (more efficient) than a context (process) > > switching. > > See above question -- is it really an issue? *nixes preferred heavy processes > over > threads for a long time. I read something comparing *nix threads vs. > processes and > there wasn't that big a difference between the two. Processes should be more robust, but threading does have its place. Here though I don't know, but I would like it. > > > > > 3) One obvious usage of threads is to get a more responsive applications. I > > hate > > those situation where the application doesn't answer to mouse click > > (keypress) > > because it's caugth in a waiting loop for some network resource or something > > else. > > So when the application is designed with a thread for the user interface and > > a > > thread for others cores, the user interface keep responding. > > Couldn't this be done with callbacks? No actually, callbacks require the thread to be in a waiting state, they only callback when waiting for getmessage or the like. There is NO way to communicate between processes( And I've looked ) that is non-blocking, and would allow one to handle the GUI and the other to handle the network resources. Although Shared memory and polling it does come close. > > In modern OS's, how many API calls are blocking calls versus taking a > callback? There are lots of callbacks in windows, but windows was designed for multithreading programs, even the callbacks, you cannot make a responsive program that has to wait for anything, or does any processing, even with callbacks without threading. > > > > > 4) why to bother designing threads machanics inside the application when it > > already exist in the operating system in a more flexible an efficient way. > > Of course the OS needs to support it, but the application (Euphoria) would > still need > to have infrastructure for starting new threads and synchronization/locking > for global > resources. Otherwise someone could just write a library using the existing > infrastructure. > > Wouldn't much of the interpreter/translator have to be rewritten to be > reentrant as > well? ALL of the interpreter(backend) and some of the translator out put would need to be gone over, and changed. But it might be worth it. Dan > > > > > regards, > > Jacques Deschenes > > > > ===================================== > Too many freaks, not enough circuses. > > j. >
25. Re: 64 bit euphoria
- Posted by D. Newhall <derek_newhall at yahoo.com> Apr 23, 2005
- 481 views
Daniel Kluss wrote: > > The threads should definetly be a must, real threads, not simulated threads. > Dan But as I've said before, what about DOS compatability? DOS isn't multitasking and currently none of them are 64-bit but DOS is still used and people still use Euphoria on it. I use the DOS32 version of Euphoria at work and at home and if I remember correctly Euphoria was briefly mentioned as a possible candidate as a "standard" scripting language for FreeDOS (only in the context to show that there are other languages besides Python, Perl, etc. that can be used) on their mailing list (although this could never happen since Euphoria's not open source).
26. Re: 64 bit euphoria
- Posted by Vincent <darkvincentdude at yahoo.com> Apr 23, 2005
- 481 views
D. Newhall wrote: > (although this could never happen > since Euphoria not open source). Oh, yes it is... The frontend is opensource, the backend can be bought with restrictions. The PD source interpreter is a great example of opensource Euphoria. The purchaced Euphoria source isn't allowed to be opensource, but the PD source is. If you dont like it because it's slower, then that is your problem. :) Regards, Vincent Without walls and fences, there is no need for Windows and Gates.