1. 64 bit euphoria
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
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
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
Regards, Alexander Toresson
5. Re: 64 bit euphoria
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
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
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
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
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
>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
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
-
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
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
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
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
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
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
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.
