Re: 2.6 feature request: foreach (off topic)
Robert Craig wrote:
>
> 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.
Ok, I made a program that will create a 30 million element linked list. The
program indexes to a random element position ranging from 0 to 30 million, and
outputs the position on the Windows console. The program is enclosed in an
infinate while loop, and thus random indexing goes on forever until a manual
exit. Results: It Takes 30-32 seconds on my Pentium 4 2.66 GHz machine w/ 512 MB
RAM to index between each random element (a few seconds less if I dont print to
console). The program uses between 240-420 MB of RAM (fluctuates randomly), and
between 5-15% CPU usage.
So you were correct to assume that it is much slower. But it only started to
show at around 3 to 4 million elements.
>
> > 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!)
Explain to me how it is possible for me to make a 2KB blank EXE or DLL
(uncompressed) then, and a typical <= 1000 line program that is around 15-20 KB?
That is about 48x smaller than a uncompressed EXE or DLL created with the Windows
Euphoria to C translator w/ OpenWatcom 1.3. That kind of size seems only possible
with a optimizing assemebler. PowerBASIC's compiler is the same way. If indeed
this is the case, this should also represent ASM speed (perhaps C/C++, because it
is converted).
>
> 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.
>
It sure is, I bet it took his team several months or even a year or more to
produce a compiler that was even remotely stable. 7 years has gone by though, it
is now pretty darn stable now. They are expert ASM and C coders.
> > 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.
>
One thing you have to do when migrating from Euphoria to a different language,
is "forget" about those sequences. Sequences are beautiful, but virtually no
other language has them. When I was making those examples, I relized I was trying
to emulate their basic functionability with linked lists. I relized there were
better ways in this case, without sacrificing speed. It works good with smaller
amounts of data, but as I just found out, you shouldn't try and do that with
really large amounts of data that you want to move around data a bunch. Instead
use another better method, like dimentional arrays, and/or structures, you can
use them together too. The fact that a simular functionability exists, doesnt
mean it should be abused.
> > > 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.
>
Not any fewer than what is made with Euphoria. The Visual Desginer for example,
was written entirely in Purebasic, as is the new and improved one coming out. In
fact, according to the creaters, only a small portion of it used external Windows
API, and almost all the GUI components were from the Gadgets library. Linux and
MacOSX form designers exist too.
There are lots of user programs & libraries on their sites.
> > 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.
>
The biggest reason why this isnt a problem is because almost all functionability
you need is provided with PureBasic, in the form of "core" libraries. As I said
before, ALL the core libraries provided were written in hand crafted 680x0,
PowerPC, and/or x86 ASM. "Core" libaries dont need to be "included", thus name
colisitions do not happen, unless done intentionally. With Euphoria, from the
start you will need to begin using other peoples code, or make your own libraries
(not productive).
Another reason is the majority of user made libraries are also "core", and were
written in either C or ASM, because using them is more convenient (no need to
"include" them). Tools and documentation are provided with registered version to
assist in making core libraries. But yes, it's quite easy to to create libraries
like Euphoria written in PB.. that you can include into your main programs. It is
also possible to create DLLs and SOs that you could use directly or wrapped as
well.
There are three main catagories: General Libraries, 2D Game Libraries,
3D Games Libraries.
The General catagory consists of 35 libraries, the 2D Games catagory consists of
9 libraries, and the 3D Games catagory consists of 10 libraries.
Each catagory consists of at least several routines. All in all... it makes up
for over 600 commands that you can use as if they were "built-in".
Plus there are litterly hundreds of user made libraries available as well.
If you compare that to the standard library provided with Euphoria, well there
just is no comparison.
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
>
Regards,
Vincent
----------------------------------------------
___ __________ ___
/__/\ /__________\ |\ _\
\::\'\ //::::::::::\\ |'|::|
\::\'\ //:::_::::_:::\\ |'|::|
\::\'\ //::/ |::| \::\\ |'|::|
\::\'\ //::/ |::| \::\\|'|::|
\::\'\__//::/ |::| \::\|'|::|
\::\','/::/ |::| \::\\|::|
\::\_/::/ |::| \::\|::|
\::,::/ |::| \:::::|
\___/ |__| \____|
.``.
',,'
|
Not Categorized, Please Help
|
|
