OpenEuphoria

1. Benchmarks Available?

• Posted by Critic May 15, 2009
• 1317 views

Are there any new benchmarks available? Or is this statement still only based on myths?

3. Re: Questions from a Beginner.

• Posted by irv May 15, 2009
• 1303 views

You wouldn't have to ask that question if you actually used those languages.

5. Re: Questions from a Beginner.

• Posted by Critic May 15, 2009
• 1386 views

Nice. But that's only one benchmark that "coincidently" does not seem to catch EU's copying problems. Try - hm, perhaps - the meteor-contest. (But most benchmarks of the language shootout are crap anyway.)

7. Re: Questions from a Beginner.

• Posted by unkmar May 15, 2009
• 1336 views

I have to agree with Irv. I have generally abandoned Euphoria. My decision was not based on Euphoria's speed. In fact, That is what makes the decision difficult for me. I have used perl and python in the past. Many things that I have programmed simply don't have the kick that I had come to expect. When I tried out python, It was simply slow. I didn't time compare it. I wrote code, Executed, and said. What the ......? I had grown accustom to Euphoria's speed. I have written things in perl that just don't cut it. I intentionally wrote one program in Euphoria for convenience and then rewrote it in Perl for commonality. Easier for others to run and read. Simply because more people know perl. Not because perl is easier to read. The Euphoria version ran much faster. If I had cared, I probably could have written the same program in python. And python wouldn't have held up to perl's speed. Let alone approach that of euphorias.

With all of that having been said. I write console apps. I don't do much graphics. My apps tend to either crunch numbers or parse data. They sometimes do both. So, My experience with euphoria has shown it to always be faster at crunching numbers, ymmv. And usually faster at parsing data. Perl's regex makes parsing data much easier than Euphoria and likely faster when regex type things are nearly required. My general take on parsing data has been, Change this into that. Remove this, or that. Find these specific items in the text. But it has not been, Find things that match this pattern. Such as, Finding phone numbers.

9. Re: Questions from a Beginner.

• Posted by jimcbrown (admin) May 15, 2009
• 1325 views

From the same thread, http://openeuphoria.org/EUforum/index.cgi?module=forum&action=message&id=104536#104536

And earlier, http://openeuphoria.org/EUforum/index.cgi?module=forum&action=message&id=104531#104531

In other words, you claim your method is slower, and Matt is trying to explain why it is really faster.

Anyhow, the specific issue Matt is talking abuot seems to have been fixed in svn revision 1960:

• Fixed ASSIGN_SUBS so that assignment using a temp does not result in an extra reference count.

See my previous post. I, or rather Jeremy, already did.

(On a side note, the documentation should be updated to be more accurate, if that specific line has not already been fixed.)

11. Re: Questions from a Beginner.

• Posted by irv May 15, 2009
• 1332 views

So, give us some links to things you have written in your favorite, pain-free language. Maybe we will see the light.

13. Re: Questions from a Beginner.

• Posted by mattlewis (admin) May 15, 2009
• 1327 views

Implementing automatic cleanup via reference counting has exposed some issues that weren't obvious about how euphoria dealt with reference counting. In particular, references were sometimes held by temps until the end of the routine, which could cause COWs that weren't strictly necessary.

I've found at least one place where something wasn't getting de-referenced properly. And now (if you read my last post) we can see that we've (ok, it was probably me) introduced another leak where our reference counts are unbalanced.

Of course, the most important thing to remember is to not write FORTRAN in euphoria.

Matt

15. Re: Questions from a Beginner.

• Posted by neophyte May 15, 2009
• 1294 views

Critic,

Be carefull what You wish for. Dont try to prove the negative of an assertion ( keep Sadam Husein in mind..he could not prove the negative )

17. Re: Questions from a Beginner.

• Posted by Critic May 16, 2009
• 1291 views

Yeah, probably not. Because even EU's devs are incompetent. The amount of incompentence in this forum is astonishing and very entertaining which is the reason I am still around.

Or I think about it from a theoretical standpoint. Which I have done. You seem to be unable to do this. Pity.

19. Re: Questions from a Beginner.

• Posted by rowrasaur May 16, 2009
• 1309 views

Alright, can of worms aside, thank you to those who responded.

I'm making good progress on reading Think Euphoria now, with much credit to a forum user named Crusty who brought up a simple, yet frusterating problem.

Having something like "? getc(0)" at the end of code (to prevent the prompt window from quickly closing when the code is done running) would be an excellent tidbit of information to put in a preface or 'how to use this book' section that emphasizes getting the user comfortable in the environment by getting them writing working code as quickly as possible, and emulating the examples they are reading about.

This is documentation that I would be happy to write if whoever is editing Think Euphoria deems it worthwhile.

21. Re: Questions from a Beginner.

• Posted by mattlewis (admin) May 16, 2009
• 1294 views

Awesome. We're thrilled to keep you entertained.

What you seem to be unable to do is to understand that there are trade offs to any approach. For instance, picking a forum on which to be the resident net kook won't win you many friends, but you may feel a false sense of superiority, or make up for times when others slighted you.

While we are pretty happy with the trade offs that euphoria has made, as far as I know, none of us have gone the kook route that you have chosen.

Still, even a broken clock is correct twice a day, and your request for benchmarks did direct my attention to a memory leak. So thanks for that, anyways. See, there's another trade off. We interact with you, and occasionally find something interesting, and you insult us.

Matt

23. Re: Questions from a Beginner.

• Posted by jimcbrown (admin) May 16, 2009
• 1289 views

This is like saying, "The sky is blue, not green, but I was still right because the sky had a color."

You can not claim either your original issue (which Derek showed was wrong) or the issue that Matt discovered (since this was fixed). So you are correct, it seems I can not comprehend what issue you are talking about when you say that Eu's sequences are too slow.

25. Re: Questions from a Beginner.

• Posted by mattlewis (admin) May 16, 2009
• 1321 views

[quote SDPringle]

Yes, Java was the fastest (according to the maintainers of the shootout). I only listed times for tests that I ran.

Matt

27. Re: Questions from a Beginner.

• Posted by jimcbrown (admin) May 16, 2009
• 1332 views

This is false.

This sentence speaks for itself.

More work may be needed in this area.

29. Re: Questions from a Beginner.

• Posted by jimcbrown (admin) May 16, 2009
• 1285 views

I am inclined to agree, when a conversation gets to the point where people are simply pointing fingers and saying "no you're lying", that conversation should probably end.

Since the relevant parts have been snipped from this part of the subthread, I'll provide a short summary for future readers of this post. Critic attempted to demonstrate a flaw in Euphoria by modifying a stack implementation written in Euphoria (which was written in response to another claim made by Critic). When told that his example was actually faster (thus doing the very opposite of demonstrating the flaw), he jumped to another unrelated issue that was discovered and reported on the same thread. This unrelated issue was since fixed. So, the first time the O(n) claim was made, it was shown to be false. The second time the claim was made, it was valid at the time, but no longer is.

I also note that this is not the first time Critic has accused a developer of lying.

31. Re: Questions from a Beginner.

• Posted by DerekParnell (admin) May 16, 2009
• 1315 views

And "critic" can not run benchmarks himself because he fears that they will prove him wrong. It is much easier to argue from "theory" than practice.

When the steam train was first invented, many experts of the day argued that the human body could not withstand such huge speeds. The arguments relied on untested "theories" and they convinced a lot of people, until of course people actually travelled at these outrageous speeds (25+ MPH) and lived.

We believe that Euphoria is one of the fastest interpreted languages going round and we know that there are still further optimisiations that can be done to make it run even faster. Once v4.0 is released, a lot of the focus for 4.1 will be under-the-hood improvements rather than changes to the language itself.

33. Re: Questions from a Beginner.

• Posted by Critic May 17, 2009
• 1254 views

Yeah, I know you have no idea about computing theory. You don't even know what a cycle is.

Yeah, because EU is a religion for you. Unfortunately speed is objective and measurable.

35. Re: Questions from a Beginner.

• Posted by Critic May 17, 2009
• 1263 views

Yes. Exactly.

An algorithm which requires O(n) instead of O(1) is crap and will break you neck soon enough. Always. Why do you think Quicksort has been invented? Because sorting in O(n^2) sucks big time, no matter how many micro-optimizations you implement. This has nothing to do with premature optimization.

"Very fast in other ways" does not help, especially since it is only "very fast" for micro benchmarks. Biggest bang comes from algorithmic optimizations. This is a well known fact.

O(n) vs. O(1) is not an example of premature optimization. That's ridiculous. Again you try to argue about things you don't know about or you consiously misrepresent the issue to defend EU.

So what? Your argumentation skills consist of spreading FUD, so maybe you should mind you own business.

37. Re: Questions from a Beginner.

• Posted by DerekParnell (admin) May 17, 2009
• 1275 views

So you agree that Euphoria currently does some things slower than the perfect possible implementation. Wow! Its a good thing that no other language's implementation is the same - which which means that every C implementation runs at the same speed.

Not only FUD but an out of context reply - well done kid. An extra elephant stamp for you this week.

By the way, what is the O(1) algorithm for calculating Prime Numbers? Or the O(1) sort?

Ok, here's an easier one... given two sets of numbers - A and B, what is the difference between each number in set A and each number if set B?

eg.

A = {1,2,13} 
B = {5,9,18} 
Difference set is {-4, -8, -17, -3, -7, -16, 8, 4, -5} 

Is there an O(1) algorithm? Is there even an O(n) algorithm?

You do have proof for the "only 'very fast' for micro benchmark" comment don't you?

Yep. But that is not what anyone here is talking about - another diversionary tactic to sow Fear, Uncertainty and Doubt.

You are really struggling to understand what's being discussed aren't you.

You have given one single example of where Euphoria is slower than it needs to be, and we have shown you that this is only due to sub-optimal optimisation by the interpreter, and that there is a workaround anyway. And by "premature optimisation", Matt is saying that spending a lot of resources on making this situation run faster will not necessarily make the application run any faster. Your comment re "algorithmic optimizations" is a better target for effort than sequence element access algorithms.

By the way, future editions of Euphoria will be improving in this area anyway.

This is Matt's business, boy. You are the real FUD spreader.

Don't be discouraged though. Keep trying to keep up. Start by helping us rather than shovelling manure.

39. Re: Questions from a Beginner.

• Posted by mattlewis (admin) May 17, 2009
• 1381 views

But you've still left out a key fact, which is that the big-O notation doesn't tell us everything about an algorithm. You still need to consider the size of n and the coefficient. This is what actually profiling your code does for you.

Of course, you're correct that in general quicksort will beat, say, bubble sort. But in the context of an application, that's merely a micro-optimization. And maybe not the most important one. If you only ever sort 3 or 4 items at a time, you're probably not losing a whole lot using a bubble sort. Please, tell me why I'm wrong and/or lying. I can't wait.

Yes, it is. But in order to get those algorithmic optimizations, you first have to know which part of your algorithm is causing the slow down. This is the very crux of premature optimization.

In fact, that's the very definition of premature optimization. You're arguing that you should never ever do anything O(n) when O(1) is available somewhere, somehow. If the O(n) algorithm isn't hurting your performance, but is easier to use and maintain, why would you change it?

In some cases, it might even be faster. Consider a case where your O(1) algorithm has a coefficient of 25, and the O(n) of 2. In this case, the O(n) algorithm is faster until n = 13. Your misuse of big-O notation has just slowed you down if your n is always smaller than 13.

Oh, please. You come here, call me a liar, call me incompetent, and I'm the one who should mind his own business? I've agreed with you that in certain places you've had good points. In some cases, I've mentioned that your very points were things that we wanted to look at. In other places, I've explained why some of those things aren't likely to change.

If anyone is spreading FUD around here, it's you. Yes, I've defended euphoria in some cases. But I certainly don't have a hidden agenda, which you seem to. At least, that's what your behavior suggests to me. Here's how wikipedia defines FUD:

Wow, if you were pushing some other programming language, that definition would be a great description of how you've acted on this forum. Since you brought up the FUD angle, and the shoe seems to fit, are you pushing some other programming language.

Matt

41. Re: Questions from a Beginner.

• Posted by irv May 18, 2009
• 1247 views

Critic clearly does not KNOW any other programming language. If he did, he would provide some code to prove his points.

43. Re: Questions from a Beginner.

• Posted by irv May 18, 2009
• 1225 views

Agreed. Perhaps a good title would be "Things I post when the attendants in white coats aren't watching".

As you may recall, our previous champion troll sounded much like Critic when he was off his meds.

45. Re: Questions from a Beginner.

• Posted by useless May 20, 2009
• 1211 views

Before that happens, i'd like to add another totally offtopic topic:

Does critic want to purchase openeuphoria.com ?

useless

47. Re: Questions from a Beginner.

• Posted by Critic May 20, 2009
• 1202 views

Is making a good joke that hard?

49. Re: Questions from a Beginner.

• Posted by jimcbrown (admin) May 20, 2009
• 1220 views

In fairness to you, Matt did admit there were some areas where Eu is still O(n) but could be O(1), but he did not specify what they were.

At this time, I don't know of any examples or any proof that demonstrates this, as the first time "proof" was offered (by you) it was discredited, and the second time (that Matt, not you, discovered it), it was fixed.

51. Re: Questions from a Beginner.

• Posted by jeremy (admin) May 20, 2009
• 1193 views

I'm waiting for the day when you have better things to do with your time then to antagonize a group of people who like their language and see the vast reasons to use it over Lua or Python. Please, give it a break and go somewhere else! I've wanted to ban you for a while now but the three people who you criticize the most, call liars and incompetent say that I shouldn't

Jeremy

53. Re: Questions from a Beginner.

• Posted by mattlewis (admin) May 20, 2009
• 1196 views

I believe he's referring to copy on write when assigning to a sequence element. At least, that's the assumption I've been making in my responses. Consider the following code:

function set_element( sequence s, integer element, object value ) 
    s[element] = value 
    return s 
end function 
sequence foo = {"a","b", "c"} 
foo = set_element( foo, 1, "A" ) 

When the assignment to s happens, it must first be copied, since there are multiple references on the sequence. The copying itself is O(n), because it depends upon the length of the sequence.

Derek provided a way to achieve the O(1) result, by storing the sequence in some other container, and using what is effectively a pointer, which implements passing by reference.

I seriously doubt that this is really an overlooked design flaw. I think it's a deliberate part of the design, and one that seems to have worked out rather well. The O(n) nature of COW doesn't appear to have dominated the performance of euphoria code, certainly not in the subjective view of its users, nor, apparently in most or all benchmarking that's been done to date.

There are some things that can be done to eliminate this without changing anything about the current syntax. I've had a plan for a while to detect situations like the above when inlining code, and avoiding the extra reference altogether.

There's probably more that can be easily done on the translator side, even in cases where we're not inlining. Some of those same tricks might slow the interpreter down unacceptably, which is why I mention the translator, where translation speed isn't terribly important in the same way that parsing and runtime speed is important for the interpreter.

There has been talk about adding a way to pass by reference to euphoria, but that won't happen before 4.1 (if, ultimately, it happens at all).

Matt

55. Re: Critic: Benchmarks Available?

• Posted by jimcbrown (admin) May 20, 2009
• 1191 views

Critic's posts and the responses have been moved to a new thread called "Benchmarks Available."

Hmm, I just noticed that replies to the new thread still show up with a subject of "Re: Questions from a Beginner." by default. This might be confusing for those who follow an RSS feed.

57. Re: Critic: Benchmarks Available

• Posted by jimcbrown (admin) May 20, 2009
• 1214 views

Ok, then what I said my previous post applies.

First, lets not confuse language design (or more clearly, design of the language specification) with design of the implementation. The "flaw" is part of the former, but your response to Matt's quote is a criticism of the latter.

Addressing that, the lack of re-entrance is not due to a lack of references. The C backend uses pointers to do this extensively, and any issues with the front end (that is written in Euphoria) go away once we're past translation to C.

Admitredly, the current implementation (C backend) is not reentrant. Of course, we could always adopt something like the Big-Kernel-Lock. Then we'd be reentrant with a more horrible design. I think it is better to wait until 4.1 (or possibly 4.2), when the time and resources can be devoted to fixing the internals in The Right Way (tm). This is just imvho, of course.

59. Re: Critic: Benchmarks Available

• Posted by jimcbrown (admin) May 20, 2009
• 1207 views

To make this clear, Euphoria outperforms both Lua and Python. You aren't explictly stating otherwise, but it can be implied.

We do not trade O(1) performance with O(n) performance for programming convenience. There are two issues here:

That we trade off a O(n) performance for the statement "a = b" where a and b are both sequences (making it O(1)), for making the statement "a[1] = x" O(n) instead of O(1). This is called COW and is pretty obvious to most computer science students.

That, to workaround the problem of the lack of PBR, we need to use global-lifetime variables. (Actually, I believe this is not entirely true with the new delete_routine functionality.) This is unrelated to the above.

Slated for 4.1

4.0 is intended for changes that break existing code. 4.1 is intended for changes that can be made without breaking existing code or libraries.

I believe one of the developers for Pike praised the elegance of the interface of Euphoria to the W32API.

31bit integers are a pain, but the Euphoria coder doesn't see this problem when interfacing to a C from interpreted Euphoria code.

Actually, there is an 80-bit long double floating point type that solves this problem.

Then you're an idiot for thinking that Matt is the only one who understands big-O notation.

Matt has already explained why you are wrong about your O(n) complaint in great detail.

This is a valid criticism.

Several of us are arguing that you are wrong on the facts you present.

61. Re: Questions from a Beginner.

• Posted by mattlewis (admin) May 20, 2009
• 1213 views

I wish I could live in your black and white world. It's true that three are some use cases where a change to the language could go from O(n) to O(1), but as I mentioned before, you're focusing on a micro optimization. For the sort of things that euphoria programmers do, the O(n) seems to be a minor issue. The sum of euphoria's performance has been good enough compared to other interpreted languages.

There's a lot to be said for programming convenience. It's probably the main reason that languages such as python have had their success, and why more programmers are no longer writing everything in C. It's fine that you put different weights on your criteria. It's less fine that you insult others with different priorities.

Again, this was a deliberate choice (please don't tell us again that you think it was a bad choice), although it's in the process of being revisited. This is definitely a trade off. Values aren't modified inside a function call. It's definitely an inconvenience, and reference semantics would be a performance boost, but it's often easier to understand, especially to beginning programmers.

I suspect we'll have something OOP-like before another couple of versions. But there are plenty of languages out there that lack OOP, which is just one programming paradigm, not the paradigm. I'm not a complete fan of structured exception handling, but I suspect we'll end up with something along those lines, too. There have been discussions about features similar to closures.

Yes, this is mainly a market share issue, and is one reason why I'm sometimes forced to use other languages.

I don't think the euphoria integer is the biggest drawback to interfacing with C. By far, it's the lack of support for memory structures. The Win32Lib approach is my favorite of any library to address this, but clearly something better is needed.

I don't follow you here. We'll just use something other than doubles.

You're by far not the biggest asshole around. You're just the euforum poster who is the most full of himself. I guess the thought that someone can accomplish something and enjoy themselves using something that doesn't conform to your priorities or that isn't mainstream is too much for you to bear.

Every so often, some such nuisance presents himself in these parts. In another month or two, you'll probably get bored of pestering us, and will move on. Eventually, we'll attract the attention of another troll/kook, and the cycle begins again.

Matt

63. Re: Questions from a Beginner.

• Posted by jeremy (admin) May 21, 2009
• 1177 views

You have said that Euphoria stinks. You have also said that Euphoria should not try to catch up that it should just be abandoned, that people should simply use Lua or Python. With these two statements for context, please answer this simple question... Why exactly are you here posting on EUforum?

Jeremy