1. 64bit support
- Posted by Critic Mar 02, 2009
- 1162 views
Hi!
How is the 64bit support implemented? Is an integer 63 bits or 31 bits?
2. Re: 64bit support
- Posted by jimcbrown (admin) Mar 02, 2009
- 1176 views
Hi!
How is the 64bit support implemented? Is an integer 63 bits or 31 bits?
Currently, there is no support for 64bit integers ala the GNU C style long long int.
However, you can use atoms to store values that would otherwise only fit in a 64bit int. The value is converted into floating point double format. (This isn't perfect, I believe there are some 64bit values that won't fit in an atom.)
3. Re: 64bit support
- Posted by Critic Mar 02, 2009
- 1129 views
(This isn't perfect, I believe there are some 64bit values that won't fit in an atom.)
True, this is not perfect and quite frightening 
. Converting 64 bit pointers to floating point values does not seem to be a good idea. Are there any plans to change this?
4. Re: 64bit support
- Posted by mattlewis (admin) Mar 02, 2009
- 1120 views
(This isn't perfect, I believe there are some 64bit values that won't fit in an atom.)
True, this is not perfect and quite frightening . Converting 64 bit pointers to floating point values does not seem to be a good idea. Are there any plans to change this?
Currently, Euphoria can't be built as a 64-bit application, so as far as Euphoria is concerned, there is no such thing as a 64-bit pointer. Since a double floating point only has 52-bits in the mantissa, it's correct that an atom cannot represent all 64-bit integers.
At some point in the future, I'm sure that Euphoria will be able to be built as a 64-bit application. It's impossible to say when that might happen, however. I, for one, don't have access to a 64-bit system. My personal feelings are that 64-bit desktop systems aren't ready for prime time (servers are an entirely different story). I can say that I'm not planning on making the jump to 64-bits any time soon (even without current financial constraints ).
There is likely to be considerable work involved in porting Euphoria to 64-bits. The assumption of 32-bits is very ingrained into the code, and while it's not an impossible task to make the jump to 64-bits, it's far from trivial. And for the record, the assumptions about 32-bits are part of why euphoria is so fast.
Matt
5. Re: 64bit support
- Posted by jeremy (admin) Mar 02, 2009
- 1123 views
For my own benefit, what does supporting 64bit get us?
Jeremy
6. Re: 64bit support
- Posted by mattlewis (admin) Mar 02, 2009
- 1174 views
For my own benefit, what does supporting 64bit get us?
Bigger integers, access to more memory, expanded feature list, probably better performance than 32-bit code when run on a 64-bit OS. Not to mention, eventually, most computers will likely be 64-bit, at least outside of embedded chips.
http://en.wikipedia.org/wiki/64-bit#Pros_and_cons
Matt
7. Re: 64bit support
- Posted by Critic Mar 03, 2009
- 1126 views
My personal feelings are that 64-bit desktop systems aren't ready for prime time.
Well, some Linux 64bit distributions manage to avoid 32bit binaries altogether. I'd argue that 64-bit desktop systems are ready for prime time since several years. (I use one.) I'd rather have a 64bit Euphoria executable than DOS support. (Hey, it's 2009, who cares for DOS support? ).
There is likely to be considerable work involved in porting Euphoria to 64-bits. The assumption of 32-bits is very ingrained into the code, and while it's not an impossible task to make the jump to 64-bits, it's far from trivial. And for the record, the assumptions about 32-bits are part of why euphoria is so fast.
Hm, seems to be a bad language design (and implementation)...
8. Re: 64bit support
- Posted by mattlewis (admin) Mar 03, 2009
- 1097 views
My personal feelings are that 64-bit desktop systems aren't ready for prime time.
Well, some Linux 64bit distributions manage to avoid 32bit binaries altogether. I'd argue that 64-bit desktop systems are ready for prime time since several years. (I use one.) I'd rather have a 64bit Euphoria executable than DOS support. (Hey, it's 2009, who cares for DOS support? ).
While there are plenty of things that can be done, especially in open source operating systems like Linux, it's only within the last week or so (IIRC) that Adobe released a 64-bit version for Linux. Still no 64-bit joy for other OSes, AFAIK. Most of what I've heard about Windows 64-bit sounds disastrous for typical desktop usage (largely stemming from driver availability and quality issues).
The main benefits of having a 64-bit architecture still seem to be on the server side. Is there much that the typical desktop user would benefit from by switching to a 64-bit architecture? I can definitely see how some niche applications that are very computationally intensive would benefit, but that seems like more of a traditional workstation role, than a desktop.
I certainly agree with you regarding DOS, but others don't. In any case, I don't see DOS support taking away from potential 64-bit support (nor from support of other 32-bit OSes). DOS will be supported as long as there is someone willing to put in the time.
There is likely to be considerable work involved in porting Euphoria to 64-bits. The assumption of 32-bits is very ingrained into the code, and while it's not an impossible task to make the jump to 64-bits, it's far from trivial. And for the record, the assumptions about 32-bits are part of why euphoria is so fast.
Hm, seems to be a bad language design (and implementation)...
In the sense that it isn't easily upgraded to 64-bits, I guess I'd agree with you, but it does what it was meant to do remarkably wellfor the last 16 years or so. I don't think that's a very interesting criterion upon which to judge the design or implementation (I suppose I'd argue that this is more of an implementation issue than language design).
Most of the code is fairly portable (it runs on DOS, Windows [95-Vista], Linux, MacOSX, FreeBSD). I'm not sure if it would be big-endian friendlycertainly things like poke4 aren't. Someone was even able to get most of euphoria working on something running on ARM.
In any case, as I said before, 64-bit support will come as soon as someone is willing (and able) to work on it. I'm not aware of any candidates, currently.
Matt
9. Re: 64bit support
- Posted by Critic Mar 03, 2009
- 1104 views
While there are plenty of things that can be done, especially in open source operating systems like Linux, it's only within the last week or so (IIRC) that Adobe released a 64-bit version for Linux. Still no 64-bit joy for other OSes, AFAIK.
True, but that is somewhat justified as Flash includes a just-in-time-compiler. But you are right.
Most of what I've heard about Windows 64-bit sounds disastrous for typical desktop usage (largely stemming from driver availability and quality issues).
I agree. Win64 is pretty crappy.
I certainly agree with you regarding DOS, but others don't. In any case, I don't see DOS support taking away from potential 64-bit support (nor from support of other 32-bit OSes). DOS will be supported as long as there is someone willing to put in the time.
Of course this is fine. But I suggest someone changes the homepage to de-emphasize (is that an English word?) DOS support and its lack of 640K memory limitations. In particular the sentence "The DOS version has been used to create many high-speed action games, complete with Sound Blaster sound effects" sounds like Euphoria is pretty archaic. And that Euphoria is the "34th most popular language" does not sound like good advertisement either IMHO.
In the sense that it isn't easily upgraded to 64-bits, I guess I'd agree with you, but it does what it was meant to do remarkably well--for the last 16 years or so.
Sorry, what does it do remarkably well? And please don't mention its performance: Even with the copy-on-write-optimization Euphoria copies sequences way to often, at least in the code examples I looked at (my practical experience with the language is limited). Apart from that the implementation seems to use a double indirection for accessing a sequence's element where a single indirection would suffice given the copying semantics.
Euphoria seems to be built on the mantra: "A simple programming language leads to simple programs." And this is wrong. The complexity that Euphoria avoids, pops up in the programs written in Euphoria: Missing language features need to be emulated. (The need to "peek" and "poke" to access C's structs, for example.) Sequences only allow tree-like structures, general graphs cannot be implemented that easily. And reference counting means that graphs don't have GC support. Euphoria is only simple to learn because it lacks a whole bunch of useful features IMHO.
10. Re: 64bit support
- Posted by mattlewis (admin) Mar 03, 2009
- 1092 views
Sorry, what does it do remarkably well? And please don't mention its performance: Even with the copy-on-write-optimization Euphoria copies sequences way to often, at least in the code examples I looked at (my practical experience with the language is limited).
Why would I not mention its performance? I agree that there are some cases where it would be nice to optimize the copy. That's one area we're working on right now. But in general, the performance is pretty good.
Apart from that the implementation seems to use a double indirection for accessing a sequence's element where a single indirection would suffice given the copying semantics.
By double vs single indirection, I can only guess that you're talking about the way it uses the symbol table, and object pointers. Could you be more specific?
Euphoria seems to be built on the mantra: "A simple programming language leads to simple programs." And this is wrong.
I agree that a simple programming language does not lead to simple programs. But I don't agree on that being a mantra of Euphoria:
] ] Euphoria is a simple, flexible, and easy-to-learn programming language. It lets you quickly and easily develop programs for Windows, DOS, Linux and FreeBSD.
I think you're confusing the program with the language. It's typically pretty easy to see what any piece of euphoria code is doingfrom a syntax/language, not algorithmic point of view. Compare that to C, or more pathologically, C++, where you can't even be sure of what operators do.
The complexity that Euphoria avoids, pops up in the programs written in Euphoria: Missing language features need to be emulated. (The need to "peek" and "poke" to access C's structs, for example.)
Yes, the lack of built-in structured memory access is something that would be nice to have. Interfacing with external code is definitely one area where, while possible, it often takes more work than with other languagesI've worked extensively doing this, and while it's certainly possible, there are undoubtedly some improvements that could be made.
Sequences only allow tree-like structures, general graphs cannot be implemented that easily. And reference counting means that graphs don't have GC support. Euphoria is only simple to learn because it lacks a whole bunch of useful features IMHO.
I suppose that if you tried to build, for example, a C-style implementation of a graph in euphoria, you'd certainly come to that conclusion. I can't figure out what you mean with respect to reference counting not garbage collecting a graph.
Euphoria is only simple to learn because it lacks a whole bunch of useful features IMHO.
Yes, it's not a tool suitable for every problem (let us know when you find it, please). I often find myself wishing for some Java or C/C or perl feature when coding in Euphoria. But then, I often wish for Euphoria features when coding in those other languages. What I like about euphoria is that it allows me to focus on an algorithm, without having to worry as much about other language details, but of course, YMMV.
Matt
11. Re: 64bit support
- Posted by Critic Mar 03, 2009
- 1087 views
Why would I not mention its performance? I agree that there are some cases where it would be nice to optimize the copy. That's one area we're working on right now. But in general, the performance is pretty good.
Well, I'd like to see some recent benchmarks.
By double vs single indirection, I can only guess that you're talking about the way it uses the symbol table, and object pointers. Could you be more specific?
I think (in C-like code) this is the current implementation:
struct {
long length;
long fill;
long refcount;
long* data;
} *s;
s->data[i] // i-th element, double indirection
It should be possible to do this instead:
struct {
long length;
long fill;
long refcount;
long data[1]; /* trick the compiler: can be more in reality */
} *s;
s->data[i] // i-th element, single indirection
I don't know how hard it would be to change this, though. I don't know if it improves the performance, either.
But I don't agree on that being a mantra of Euphoria:
] ] Euphoria is a simple, flexible, and easy-to-learn programming language. It lets you quickly and easily develop programs for Windows, DOS, Linux and FreeBSD.
Well, "simple and easy-to-learn" confirms my point. "Flexibility" is the result of dynamic typing, yet it is not quite flexible enough for complex graph-like data structures.
It's typically pretty easy to see what any piece of euphoria code is doing--from a syntax/language, not algorithmic point of view.
Hm, that is true for assembler too. The algorithmic point of view is IMHO the interesting part of a piece of code. (I don't get your C example here: There is no operator overloading in C.)
I suppose that if you tried to build, for example, a C-style implementation of a graph in euphoria, you'd certainly come to that conclusion. I can't figure out what you mean with respect to reference counting not garbage collecting a graph.
Well, I think I am wrong with the GC aspect: Implementing graphs with a matrix should work. However, reference counting does not work for cyclic structures.
Yes, it's not a tool suitable for every problem (let us know when you find it, please).
Well, IMHO Python and Lua have fewer problems than Euphoria. Lua is quite fast too and may be faster than Euphoria in some benchmarks.
But then, I often wish for Euphoria features when coding in those other languages.
I am interested. Could you please give an example?
12. Re: 64bit support
- Posted by DerekParnell (admin) Mar 03, 2009
- 1084 views
Sorry, what does it do remarkably well? And please don't mention its performance
Performance compared to what? Euphoria is faster than nearly all other interpreted languages (last time I checked). The Translator still needs lots of optimization work to be done, but it is still fairly young.
... the implementation seems to use a double indirection for accessing a sequence's element where a single indirection would suffice given the copying semantics.
By indirection I assume you mean address dereferencing. Double indirection makes resizing sequences fast and safe. If single indirection was used, each time a sequence was resized, all current references to that sequence would also have to be updated.
Sequences only allow tree-like structures, general graphs cannot be implemented that easily.
I assume you mean the inability to store references to sequences. This ability will probably be implemented after v4.0 is released.
And reference counting means that graphs don't have GC support.
Can you give an example of this assertion?
13. Re: 64bit support
- Posted by DerekParnell (admin) Mar 03, 2009
- 1077 views
Well, I'd like to see some recent benchmarks.
Me too. I'll prepare some and publish the results.
I think (in C-like code) this is the current implementation:
struct {
long length;
long fill;
long refcount;
long* data;
} *s;
s->data[i] // i-th element, double indirection
It should be possible to do this instead:
struct {
long length;
long fill;
long refcount;
long data[1]; /* trick the compiler: can be more in reality */
} *s;
s->data[i] // i-th element, single indirection
I don't know how hard it would be to change this, though. I don't know if it improves the performance, either.
I have already considered doing this, but what happens when the 'data' portion needs to be enlarged. A new allocation must be made and the length, fill, refcount, and all the existing elements must be copied to the new location, then all the active variables that point to the old structure must be now updated to point to the new structure - which means we must keep track of all those.
With the current implementation, all that happens is a new allocation is made and the existing elements are copied to the new location (and the length is incremented). All existing references to the structure do not have to be updated.
... reference counting does not work for cyclic structures.
Not quite true. Reference counting, when cyclic structures are involved, require a bit of cleverness, and this has already been implemented in Euphoria. For example, this works just fine ...
sequence A = {1,2,3} sequence B = {A} A = {4,5,6} ? A ? B
Output:
{4,5,6}
{1,2,3}
Well, IMHO Python and Lua have fewer problems than Euphoria.
Are there any supporting statistics available?
Lua is quite fast too and may be faster than Euphoria in some benchmarks.
I have never used Lua. If we agree to a set of performance tasks, can you write the Lua equivalent for us to test this assertion?
14. Re: 64bit support
- Posted by Critic Mar 03, 2009
- 1084 views
Performance compared to what? Euphoria is faster than nearly all other interpreted languages (last time I checked). The Translator still needs lots of optimization work to be done, but it is still fairly young.
I'd like to see some benchmarks (even though benchmarks are mostly worthless anyway). Well, I migth benchmark Lua vs. Euphoria myself some day.
By indirection I assume you mean address dereferencing. Double indirection makes resizing sequences fast and safe. If single indirection was used, each time a sequence was resized, all current references to that sequence would also have to be updated.
Well, if a sequence is resized, the sequence changes so copy-on-write ensures that there is only one reference to the new sequence anyway.
Can you give an example of this assertion?
I was not precise. See my above post.
15. Re: 64bit support
- Posted by DerekParnell (admin) Mar 03, 2009
- 1105 views
I think (in C-like code) this is the current implementation: ...
Actually the current implementation is ...
struct {
void* data;
long length;
long fill;
long refcount;
} *s;
By placing the data element at the front, we can gain a few cycles by not having to add an offet to get to the data pointer.
16. Re: 64bit support
- Posted by Critic Mar 03, 2009
- 1065 views
- Last edited Mar 04, 2009
Not quite true. Reference counting, when cyclic structures are involved, require a bit of cleverness, and this has already been implemented in Euphoria. For example, this works just fine ...
sequence A = {1,2,3} sequence B = {A} A = {4,5,6} ? A ? B
Output:
{4,5,6}
{1,2,3}
I don't get it: Where is the cycle? The language's semantics do not allow cycles, AFAIK.
Are there any supporting statistics available?
Well, I said "IMHO". Apart from that Lua is used as a scripting language in various comercial games (for example Far Cry, World of Warcraft) and there is a JIT available. Python is used by Google and YouTube and there is a JIT available too. I don't know if there are comercial products that use Euphoria.
I have never used Lua. If we agree to a set of performance tasks, can you write the Lua equivalent for us to test this assertion?
My Lua is rusty, but I can try. (I am forced to use Java at work 
)
17. Re: 64bit support
- Posted by DerekParnell (admin) Mar 03, 2009
- 1088 views
- Last edited Mar 04, 2009
Well, if a sequence is resized, the sequence changes so copy-on-write ensures that there is only one reference to the new sequence anyway.
From the point of view of the Euphoria code, you are right. But at the lower level, the run time engine (and translated code) can make a number of optimizations if it can safely assume double indirection. Basically, we can store the sequence reference in a temporary variable, and later use that variable knowing that any calls that might have been made to internal functions, have not invalidated it's reference. If we did not do that, we would be required to update every stored reference (in scope) after calling any internal function because we do not know what that function does to the active sequence.
18. Re: 64bit support
- Posted by DerekParnell (admin) Mar 03, 2009
- 1125 views
- Last edited Mar 04, 2009
I don't get it: Where is the cycle? The language's semantics do not allow cycles, AFAIK.
Ah, you are right. Here is a better example (I hope) ...
sequence A = {1,2,3} A = {A} A = {A} ? A
Output: 1,2,3
Unless we understand 'cycle' differently.
Well, I said "IMHO". Apart from that Lua is used as a scripting language in various comercial games (for example Far Cry, World of Warcraft) and there is a JIT available. Python is used by Google and YouTube and there is a JIT available too. I don't know if there are comercial products that use Euphoria.
The is no JIT for Euphoria (yet). So any comparisions for now must be done on plain interpreters.
There are commercial Euphoria products. eg. Nexus Radio
19. Re: 64bit support
- Posted by DerekParnell (admin) Mar 03, 2009
- 1085 views
- Last edited Mar 04, 2009
Oops, output formatted incorrectly ...
sequence A = {1,2,3} A = {A} A = {A} ? A
Output: {{{1,2,3}}}
20. Re: 64bit support
- Posted by Critic Mar 03, 2009
- 1141 views
- Last edited Mar 04, 2009
But at the lower level, the run time engine (and translated code) can make a number of optimizations if it can safely assume double indirection. Basically, we can store the sequence reference in a temporary variable, and later use that variable knowing that any calls that might have been made to internal functions, have not invalidated it's reference. If we did not do that, we would be required to update every stored reference (in scope) after calling any internal function because we do not know what that function does to the active sequence.
I see. But since s[i] is most likely the most common operation in any Euphoria program, it seems to be the wrong trade-off to me. But it is not that important.
21. Re: 64bit support
- Posted by Christopher Mar 03, 2009
- 1094 views
- Last edited Mar 04, 2009
I don't know if there are comercial products that use Euphoria.
I have developed a few commercial products with EU over the past 8 or so years. Cloak was developed by EU and then acquired by Avanquest a few years. My latest project Nexus Radio is also written in EU.
C Bouzy
22. Re: 64bit support
- Posted by Critic Mar 03, 2009
- 1127 views
- Last edited Mar 04, 2009
Ah, you are right. Here is a better example (I hope) ...
sequence A = {1,2,3} A = {A} A = {A} ? A
Output: { { { 1,2,3 } } }
Unless we understand 'cycle' differently.
Well, that is not a cycle conceptually. It may be implemented as a cycle because of copy-on-write semantics. For a true cycle the "?" would never finish.
The is no JIT for Euphoria (yet). So any comparisions for now must be done on plain interpreters.
Ok. But benchmarking the Euphoria-to-C-translator with the JITs would be interesting too.
There are commercial Euphoria products. eg. Nexus Radio
Interesting.
23. Re: 64bit support
- Posted by mattlewis (admin) Mar 03, 2009
- 1080 views
- Last edited Mar 04, 2009
It should be possible to do this instead:
struct {
long length;
long fill;
long refcount;
long data[1]; /* trick the compiler: can be more in reality */
} *s;
s->data[i] // i-th element, single indirection
I don't know how hard it would be to change this, though. I don't know if it improves the performance, either.
As Derek mentioned, the actual declaration is:
struct s1 { /* a sequence header block */
object_ptr base; /* pointer to (non-existent) 0th element */
long length; /* number of elements */
long ref; /* reference count */
long postfill; /* number of post-fill objects */
}; /* total 16 bytes */
What's not totally clear from this is that base actually points to the address of postfill, where the data comes after that (which is similar to what you were looking for). So we actually allocate a single, contiguous block of memory.
It's typically pretty easy to see what any piece of euphoria code is doing--from a syntax/language, not algorithmic point of view.
Hm, that is true for assembler too. The algorithmic point of view is IMHO the interesting part of a piece of code. (I don't get your C example here: There is no operator overloading in C.)
Sorry, with respect to operator overloading, I was referring to C. My sentence could have been clearer.
You're right with respect to assembler, but I'm not sure if you're serious. Assembler is so low level, that the algorithmic view is difficult to see. In any case, the algorithmic view is partially dependent on the coder, though certain languages can make this easier by not requiring the reader to spend time just figuring out what certain operations are doing. Perl, for instance, is often referred to as a write only language for just this reason.
I find that euphoria is high level enough, and the language small enough that it doesn't get in the way of getting a higher level understanding of the code than other languages sometimes do.
Yes, it's not a tool suitable for every problem (let us know when you find it, please).
Well, IMHO Python and Lua have fewer problems than Euphoria. Lua is quite fast too and may be faster than Euphoria in some benchmarks.
Yes, they have some nice features, though I haven't used either of them extensively.
But then, I often wish for Euphoria features when coding in those other languages.
I am interested. Could you please give an example?
Sometimes it relates to static typing, or simply the ease of dealing with sequences. And also not needing to worry about pointers or references, or memory management in general (obviously, memory management issues don't apply to languages like Java).
The pass by reference nature of euphoria can cut both ways. If I pass a value to a routine, I know that it won't be modified. Of course, that also means that I can't modify it if I want to.
Matt
24. Re: 64bit support
- Posted by mattlewis (admin) Mar 03, 2009
- 1081 views
- Last edited Mar 04, 2009
I don't know if there are comercial products that use Euphoria.
I've never released a commercial product, but I have used Euphoria in my work to do some serious analysis. For what that's worth.
Matt
25. Re: 64bit support
- Posted by Critic Mar 03, 2009
- 1135 views
- Last edited Mar 04, 2009
What's not totally clear from this is that base actually points to the address of postfill, where the data comes after that (which is similar to what you were looking for). So we actually allocate a single, contiguous block of memory.
In this case my suggestion should be simple to implement?
You're right with respect to assembler, but I'm not sure if you're serious.
I just checked if I got your point.
Perl, for instance, is often referred to as a write only language for just this reason.
Well, I think of Perl as a joke. No need to argue about Perl, though.
I find that euphoria is high level enough, and the language small enough that it doesn't get in the way of getting a higher level understanding of the code than other languages sometimes do.
I am not sure. In EU structs or objects are simulated with sequences which could be disturbing. "To break a butterfly on a wheel" does not make the code clearer. (Hope I got the saying right.)
Sometimes it relates to static typing, or simply the ease of dealing with sequences.
Python's lists do pretty much the same as sequences. AFAIK EU does not do much static type checking. User-defined types are checked at runtime, if I am not mistaken.
The pass by reference nature of euphoria can cut both ways. If I pass a value to a routine, I know that it won't be modified. Of course, that also means that I can't modify it if I want to.
And it means that procedures/functions cannot be split up in smaller parts easily.
26. Re: 64bit support
- Posted by GeorgeWalters Mar 04, 2009
- 1128 views
There are commercial Euphoria products. eg. Nexus Radio
and AcuTrack
[/quote]
27. Re: 64bit support
- Posted by CChris Mar 04, 2009
- 1091 views
Euphoria seems to be built on the mantra: "A simple programming language leads to simple programs." And this is wrong. The complexity that Euphoria avoids, pops up in the programs written in Euphoria: Missing language features need to be emulated. (The need to "peek" and "poke" to access C's structs, for example.) Sequences only allow tree-like structures, general graphs cannot be implemented that easily. And reference counting means that graphs don't have GC support. Euphoria is only simple to learn because it lacks a whole bunch of useful features IMHO.
Thanks for pointing this out, I thought I was the only one on this list to think that a simple language only leads to more complex programs, with more bugs and a less than decent debugger.
CChris
28. Re: 64bit support
- Posted by bernie Mar 04, 2009
- 1119 views
etc. etc. etc.
Critic:
You sound like you have a solid background creating
and developing new computer languages.
Maybe in stead of criticizing Euphoria you should join
the development team and help improve it.
By the way what other computer languages have you contributed to the development of ?
29. Re: 64bit support
- Posted by jeremy (admin) Mar 04, 2009
- 1118 views
Well, I'd like to see some recent benchmarks.
Me too. I'll prepare some and publish the results.
In the archives is a very good start on the benchmarks on the Computer Language Shootout. It was submitted to them a while ago but they denied us access because Euphoria was not open source at the time. Once 4.0 is completed and out the door, one of the first order of businesses should be to updated those programs to make use of new 4.0 features and resubmit to the Computer Language Shootout as we are now 100% open source.
Jeremy
30. Re: 64bit support
- Posted by znorq2 Mar 04, 2009
- 1075 views
- Last edited Mar 05, 2009
I don't know if there are comercial products that use Euphoria.
I have developed a few commercial products with EU over the past 8 or so years. Cloak was developed by EU and then acquired by Avanquest a few years. My latest project Nexus Radio is also written in EU.
C Bouzy
Though I haven't directly made money on it yet, some of the code I've produced at work are being used by Norway's biggest oil company - *and* the company I'm working for (one of the biggest - if not the biggest - contractors within the oil industry). I've done quite some promotional works in both companies, and that's because I see some benefits in the language.
Thanks to the Win32Lib library, Euphoria gives me the power *I* need, and the simplicity in which the language is formed gives me something I can easily grasp. That does not ofcourse mean that Euphoria isn't powerful - I think it is.... IMHO...
By the way, the H in 'IMHO' means 'humble', something that I (IMHO) do not think you've presented yourself as being, Critic. I don't see the point in arguing a case by stepping on toes. I do appreciate the feedback you're giving, Critic, but can you please use a tone that won't be interpided as agressive and insulting? Be constructive..
Also, making a statement backing it up with 'IMHO' doesn't seem to be very constructive; "IMHO, all other languages suck, Euphoria is king. Ofcourse, I don't have anything to back it up with as I haven't tried them out..." Don't seem very constructive, right? Oh, and if you didn't get the phun; my "all other languages suck" was just a dumb example of how statements without real backup just seems lame.
My two cents, anyway.
Kenneth / ZNorQ
