Re: 2.6 feature request: foreach (off topic)
Vincent wrote:
> I've done a test with Euphoria and PureBasic that creates a 5 million element,
> one
> level sequence/linked list and assigned random byte values to each of the 5
> million
> elements.
I don't care if the element *values* are random.
I want to see what happens when the element *indexes* are chosen randomly.
That's where a linked list is going to get really slow.
> When I timed the execution.. It took ~3.4 seconds to run and finish with
> compiled PB, and about ~2.1 seconds with interpreted Euphoria. In most
> bentchmarks,
> PB would be Euphoria by a long shot,
> perhaps even beat C/C++ in a few,
Not likely. I'll put my money on Richard Stallman,
Microsoft, WATCOM or Borland, over "Fred" any day.
(No offense Fred!)
It's also difficult for one person or a small team to
produce solid, reliable, optimized non-buggy machine code.
Lcc was always buggier than the other C compilers I tried.
> because the
> code is converted directly to optimized ASM before being compiled. It just
> seems that
> linked lists might not be all that efficent internally.
> I will do more tests with linked lists using "SelectElement", and if infact
> this is
> a problem, I will notify the team developers about this issue...
Linked lists just aren't meant to handle random access very well.
There are a few tricks you can do, but in general
the performance will be poor.
> > And there's no error checking, so if you ask
> > for an invalid element, your program will likely crash.
>
> I'll bring that up with the developers, thanks. As for arrays, bound checking
> is done
> only when the debugger is enabled.
>
> >
> > They of course have (inflexible) arrays:
> >
> > "Once an array is 'sized' it can be resized
> > but its content will be deleted"
> > (ouch!)
> >
> Yea I didnt like that, but you can copy the contents into a temp structure or
> linked
> list, then once it's resized, paste the values back in. Dynamic arrays in PB
> can have
> infinite dimentions, arrays in some other basics are limited to 2 or 3
> dimentions.
>
> > "Arrays are always globally accessable in PureBasic."
> > (no way to restrict access by scope!)
> >
> Yea well the file scope is always global. You can control the routine scope of
> variables
> and stuff, using global, shared, static, and protected. But noone ever
> compained about
> naming conflicts.
Sounds like very few large programs have been written.
> When you compile the main source file and any includes, they are
> all binded togeather... and the debugger will catch any and all naming
> conflicts, thus
> a namespace system isn't needed (I already questioned this in the chatroom).
Right. Forget about namespaces. Forget about scope on arrays.
You just have to go through the source to some guy's library and
modify it so it doesn't conflict with yours. Then do the same
when he comes out with v1.1. *Every* array, even those that should
have private scope within a routine are global to the whole program!
If I suggested that as a good approach for Euphoria,
you'd see a lynch mob heading up to Canada.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
|
Not Categorized, Please Help
|
|
