PureBasic Forums - English

Posted: **Thu Oct 27, 2011 6:01 pm**

You don't seem to know much about how computers actually work and about optimizations.
At least I think you don't just based on your statements above. I'm not in a mood right now to go through them all,
that's why I picked just one:

Ion Saliu wrote: Problem is, C uses far shorter names. Un-Pure Basic uses longer function names which definitely affect the performance.

Let me tell you that the length of a function's name doesn't affect the execution performance at all.
PureBasic is compiled into machine code and in machine code there is no such things as function names, everything
is accessed by pointers and not string literals.

Posted: **Thu Oct 27, 2011 6:08 pm**

Quite frankly, that is rather unfair.

What you are seeking is either an extremely optimized math library, or a programming language BUILT for computational math.

PureBasic is a general purpose language, with a few extras like inline ASM.

You jumped the gun on your purchase, without demo-ing (or if you did, then not for long) the product for a few days. So it is no wonder if you are dissatisfied.

But again, what you want is not a general purpose language. You need a highly optimized Math library, or a language more friendly to computational math. So I think your expectations are somewhat invalid in this case.

There are many dialects of BASIC. That is the entire point, and in the original spirit of the language. Beginners All Purpose Symbolic Instruction Code. PureBasic fulfills that role quite well, I think. Languages change over time and evolve, this is only natural. PB has survived for over a decade without the exact replica of commands you note.

And further, while I don't do file operations often, I'm pretty darn sure you don't need to dump anything to an array to store it in a file.

I would say you are unfamiliar and are having trouble adapting to the differences in PB vs other languages you know, and that has affected the speed of what you have coded, as well as what you think you can or can't achieve with PB.

As for the veracity of your 64-bit point, I will leave that to someone far more experienced than myself to address, should they choose.

Posted: **Thu Oct 27, 2011 6:22 pm**

Also let me just say, I find your approach to be mildly insulting.
I am not a very skilled person, I learn something new about PB every day just by reading posts on the forum.

But I am slightly puzzled by your reaction to your impulsive purchase of PB.

Even a novice like me, knows what you should have done about your performance complaints, and other issues.

You should have:
(First and foremost.. Make sure you were compiling with the debugger turned off)

1) Posted your current "top end" program, or at least come up with an example program in the language it was written in, that performs very fast.
2) Posted the source of your Purebasic program.
3) Asked others to comment on how to improve your PB code to match or beat the performance of the program from #1
4) Asked about your other complaints, such as writing data directly to an open file, etc. To show you any better/faster ways to do what you are attempting, etc.

You could have done all this within the Demo version of PB, since you are only working with Console (command prompt/whatever you want to call it) applications. As long as your code was shorter than 800 lines, you weren't calling any Win32API, and you weren't trying to use any external libraries. You could have spent a couple days working with the demo, and asking questions about any shortcoming with your code on the forums... Without paying anything.

Instead you wrote something in a programming language you only just picked up, and then complained about how it wasn't the same as some other language, and then complained about the performance.

That was very "un-nerdy" of you, sir.

p.s
Although I doubt I could translate any of your code and calculations into PB (I am a hobbyist who learns very slowly). Even if I wanted to find the "Free" source code on your side (if it is really free and doesn't require membership to download) I would spend forever looking for the download link, unless you provided it directly. Your web site is a jumbled, chaotic, navigational mess; a throwback to the mid 1990's web sites I would make as a teenager.. If you have source code you want someone to help translate into powerful, efficient PureBasic, that can beat your current programs performance, just post the source code, or a direct link to the file.

Posted: **Thu Oct 27, 2011 6:25 pm**

Ion Saliu wrote:And because C is so much more error-prone than Basic, C is ill-suited for lottery programming. Lottery requires a lot of logical constructs and it is very easy to make mistakes.

Ion Saliu wrote: They removed all Basic statements and replaced them by C-like functions. Problem is, C uses far shorter names. Un-Pure Basic uses longer function names which definitely affect the performance. You won’t notice that in “Hello, world!” programs, but you will de definitely shocked in lottery programs.

Ion Saliu wrote: Lottery software checks millions and millions of combinations and prints them to screen or file. It is much faster to PRINT #1, than using the PureBasic cumbersome functions.

Ion Saliu wrote: Unfortunately, writing to an array uses the now hidden REDIM PRESERVE

Ion Saliu wrote: “PureBasic” should have ...

Ion Saliu wrote: I thought the 64-bit would be faster by an order of magnitude! NOT!

Ion Saliu wrote: This is a too-nerdy product. It will find a place in my collection only. Not for real use.

Ion Saliu wrote: Best of luck to you all, nerds, geeks and the like — I am one of you!

AAAAAAAAAAAAAH! DON'T EVEN JOKE ABOUT THAT.

Posted: **Thu Oct 27, 2011 7:07 pm**

Ion Saliu wrote:
Blood wrote:What the holy f**k: http://saliu.com/Ion_Saliu.html ???
You would say correctly:

“What the Bloody f**k!”

Ha, what would Americans know of the English language! ...I said it correctly!

lol, i knew this guy was bat shit crazy but to say C isn't suitable for his task is totally laughable! What a noob! lol!

He's a typical old school basic user, refuses to learn anything else then slags off all other compilers without even learning how to use them! lol, this has made my day!

Did he even turn the debugger off?? I rarely use PB anymore but to be honest it is a crazy fast compiler and produces extremely fast and tight exe's, what is this guy smoking!

Posted: **Thu Oct 27, 2011 7:10 pm**

Honestly, it doesn't help anything to get personal and flame him.

The best thing we can do is try to help him and convince him that he may be going about things wrong.
Calling him names isn't going to do anything but cause an argument unrelated to the thread..

Posted: **Thu Oct 27, 2011 7:17 pm**

Ion Saliu wrote:Danilo:

It's about US$ 1,500 / 900 Euro initial product price for the complete suite, but only US$ 600 / 360 Euro per year for support and upgrades.
Now, that’s affordable In all fairness, however, I would trust Intel the most, by far. Intel makes the CHIP!

Thanks for the info, really. It is absolutely the best tip I got here. “PureBasic” is only a collectible item for me from now on … Like QuickBasic, Basic PDS, VBDOS, Visual Basic — I paid for them more than what Intel charges upfront …

That's the price for the C++ suite and includes VTune Performance Analyzer and Thread Checker.

Without this tuning applications it is named Intel® C++ Composer XE 2011 for Windows, Linux, and Mac OS
and the price on Intel's website is US$ 599 for

Intel C++ Compiler
Intel Integrated Performance Primitives
Intel Threading Building Blocks
Intel Math Kernel Library

So it is US$ 900 less for the compiler + all libraries, without the tuning applications.

Please note that it does not come with an IDE for the C++ Compiler. It comes with
a plugin for Visual Studio on Windows (don't know about Linux and Mac) and you can
compile from command line using your own makefiles or .BAT files.

You can do with other products, but the Intel package is a good option
if you need very good optimizations, parallel programming and math libraries.
30 day evaluation versions of Intel® Software Development Products are available for free download.

Posted: **Sat Oct 29, 2011 7:13 pm**

Blood wrote:
Ion Saliu wrote:
Blood wrote:What the holy f**k: http://saliu.com/Ion_Saliu.html ???
You would say correctly:

“What the Bloody f**k!”
Ha, what would Americans know of the English language! ...I said it correctly!

lol, i knew this guy was bat shit crazy but to say C isn't suitable for his task is totally laughable! What a noob! lol!

He's a typical old school basic user, refuses to learn anything else then slags off all other compilers without even learning how to use them! lol, this has made my day! Did he even turn the debugger off?? I rarely use PB anymore but to be honest it is a crazy fast compiler and produces extremely fast and tight exe's, what is this guy smoking!

You would say correctly:

“Ha, what would Bloody f**k Americans know of the British English!”

Wouldn’t you?

“I rarely use PB anymore …”

Why the Bloody f**k are you here, then? You should be in the respective forums of the compilers you are using … shouldn’t ye?

I wanna make a safest bet. I bet you, Bloody, write only porno software! Instead of printing “Hello, world!” your porno program continuously prints “Bloody F**k … press X to stop …”

Posted: **Sat Oct 29, 2011 7:15 pm**

Danilo:

Again, your info is appreciated. However, you seem to advertise for … Microsoft! In fact, Intel themselves advertize for Micro$oft! All that expensive Intel suite must-have an installed Micro$oft Visual Studio, and especially Microsoft Visual C++!

What the Bloody F**k is that for? An Intel visitor loudly complains about that insane scheme! He honestly says he is only interested in buying Intel software, not Micro$oft products at all!

One must always go deeper than skin-deep. Intel compiler fully relies on Microsoft C++ compilers. Microsoft is loudly honestly clear about their 64-bit compilers: They are NOT true 64bit compilers. Micro$oft’s 64-bit compilers create hybrid software: 32bit+64bit. NO object can exceed the 2GB size limit!

How could Intel’s “64-bit” compilers go beyond the limits of their fathers?

Always think deeper, boys and “bloody” girls!

Posted: **Sat Oct 29, 2011 7:54 pm**

Ion Saliu wrote:I wanna make a safest bet. I bet you, Bloody, write only porno software! Instead of printing “Hello, world!” your porno program continuously prints “Bloody F**k … press X to stop …”

I can make a safe bet that you think God is real, the Earth is only 6,000 years old, evolution is just a theory, Fox news is fair and balanced and think homeopathic remedies really work?

Just stop posting, you are an old fool! By the way, you need to read this!!!

Posted: **Sat Oct 29, 2011 8:17 pm**

Ion Saliu wrote:Danilo:
They are NOT true 64bit compilers. Micro$oft’s 64-bit compilers create hybrid software: 32bit+64bit. NO object can exceed the 2GB size limit!

Every post you make I learn something new. The previous one was better tough.
I like the idea of the hybrid compiler anyway, not really 64 bit.

Back to Earth now. On x64 bit the only limit at 2GB is in static data (the executable code and the global data if you wish, or the data defined outside a procedure). This is due to the PE file format structure. And the stack obviously. I think it's 1GB for that.

Allocatable data is limited only by the OS and your configuration (physical ram, virtual memory). There is no 2GB limit.

@Blood:
GOTO (pun intended): http://www.purebasic.fr/english/viewtop ... 17&t=28690

Posted: **Sat Oct 29, 2011 8:19 pm**

It doesn’t have the HUGE data types I looked for. The applications created in “Not-Pure-Basic” are truly 64-bit, however. You can’t run them in a 32-bit operating system.

I had expected that 64bit software would be faster than 32bit software by an order of magnitude. In fact, it was slower. With great difficulty, I created a simplified lottery generator like in the source code published at SALIU.COM. The way it writes to files is cumbersome and slow. Some guys over there already got at me. They probably write only Hello, World-type of programs. Let them try a lotto program that crunches millions of combinations in thousands of operations!

To me, “PureBasic” is more like a project created by nerds! It might make sense for those who start programming from scratch. They can create Windows applications after a while. But the documentation is … just about 0.001% of the books written for Microsoft Basic’s!

http://forums.saliu.com/lottery-lotto-s ... ml#post884

Lol, comedy gold!

Posted: **Sat Oct 29, 2011 11:35 pm**

You know, as for someone who actually looked into lottery (read: Euro millions), I think that generating RND numbers based on time (in your case) and trying to "see" lotto numbers is equally dumb : sort of watching protons colliding with neutrons and expect to get a punch line like "your winning numbers for this Friday:...".

Numbers like to repeat them selfs, in pairs, in groups... History like to repeat itself, everything like to repeat itself. Even you.

I think you will have a more "luck" with your numbers, if you try to calculate or simulate them balls in those machines than calculate a probability based on time. They change lotto machines every so often, so maybe that mean something? plus you cannot get "history" of all previous results (at least in UK web site, but it was possible before) or something more natural mean "real".

Anyway, best of luck and don't forget about us, small PB users (...and £10000 or $15000 of donations for us for giving you an idea

)

Regards,

Posted: **Sun Oct 30, 2011 9:15 am**

Ion Saliu wrote:Danilo:

Again, your info is appreciated. However, you seem to advertise for … Microsoft! In fact, Intel themselves advertize for Micro$oft! All that expensive Intel suite must-have an installed Micro$oft Visual Studio, and especially Microsoft Visual C++!

For 64bit development with Intel C++ you require the (free) Microsoft Windows SDK for Windows 7 and .NET Framework 4 (ISO downloads)
This is required because it contains the headers, windows libraries, and documentation.

What do you mean with "hybrid software"? 64bit applications don't run on 32bit windows
because it is 64bit only. It is not hybrid in the sense that 32bit and 64bit versions are
compiled into one executable.

Posted: **Sun Oct 30, 2011 12:01 pm**

Small example to show use of Intel Math Kernel Library with PureBasic.
The original example is in C and from the MKL help.
It calls dgemm ("Computes a scalar-matrix-matrix product and adds the result to a scalar-matrix product")
and MKL memory allocation functions.

I added a call to mkl_get_version_string() to output the version of mkl_core.dll

Tested with 32bit and 64bit version of mkl_core.dll and PureBasic.

Code: Select all

EnableExplicit
DisableDebugger

OpenConsole()

PrototypeC   Def_mkl_get_version_string(*buffer.Ascii, len.i)
PrototypeC.i Def_mkl_malloc            (size.q,align.i)
PrototypeC   Def_mkl_free              (buffer.i)
PrototypeC.q Def_mkl_mem_stat          (*nbuffers)
PrototypeC   Def_mkl_free_buffers      ()
PrototypeC   Def_dgemm(transa.p-Ascii,transb.p-Ascii,*m,*n,*k,*alpha,*a,*lda,*b,*ldb,*beta,*c,*ldc)

If OpenLibrary(0,"mkl_core.dll")
    Define mkl_get_version_string.Def_mkl_get_version_string = GetFunction(0,"mkl_serv_getversionstring")
    Define mkl_malloc            .Def_mkl_malloc             = GetFunction(0,"mkl_serv_mkl_malloc")
    Define mkl_free              .Def_mkl_free               = GetFunction(0,"mkl_serv_mkl_free")
    Define mkl_mem_stat          .Def_mkl_mem_stat           = GetFunction(0,"mkl_serv_mkl_memstat")
    Define mkl_free_buffers      .Def_mkl_free_buffers       = GetFunction(0,"mkl_serv_freebuffers")
    Define dgemm                 .Def_dgemm                  = GetFunction(0,"mkl_blas_dgemm")
Else
    PrintN("Can't open mkl_core.dll")
    End
EndIf

Define buffer, Version$

buffer = AllocateMemory(200)
  mkl_get_version_string(buffer,200)
  Version$ = Trim(PeekS(buffer,200,#PB_Ascii))
  PrintN( Version$ )
FreeMemory(buffer)

Structure mem
   Array a.d(0)
   Array b.d(0)
   Array c.d(0)
EndStructure

Define mem.mem
Define.i  n, i
Define.d alpha, beta
Define.q AllocatedBytes
Define.i N_AllocatedBuffers

alpha = 1.1 : beta = -1.2
n = 1000
mem\a() = mkl_malloc(n*n*SizeOf(Double),64)
mem\b() = mkl_malloc(n*n*SizeOf(Double),64)
mem\c() = mkl_malloc(n*n*SizeOf(Double),64)

For i = 0 To n*n
    mem\a(i) = i+1
    mem\b(i) = -i-1
    mem\c(i) = 0.0
Next i

dgemm("N","N",@n,@n,@n,@alpha,mem\a(),@n,mem\b(),@n,@beta,mem\c(),@n)

AllocatedBytes = mkl_mem_stat(@N_AllocatedBuffers);
PrintN("AllocatedBytes  : "+Str(AllocatedBytes))
PrintN("AllocatedBuffers: "+Str(N_AllocatedBuffers))

mkl_free_buffers()

AllocatedBytes = mkl_mem_stat(@N_AllocatedBuffers);

If AllocatedBytes > 0
    PrintN("MKL memory leak!")
    PrintN("fter mkl_free_buffers there are "+Str(AllocatedBytes)+" bytes in "+Str(N_AllocatedBuffers)+" buffers")
EndIf

mkl_free(mem\a())
mkl_free(mem\b())
mkl_free(mem\c())

PrintN("press ENTER")
Input()

Output with 32bit version:

Code: Select all

Intel(R) Math Kernel Library Version 10.3.3 Product Build 20110314 for 32-bit applications
AllocatedBytes  : 1983872
AllocatedBuffers: 1
press ENTER

Output with 64bit version:

Code: Select all

Intel(R) Math Kernel Library Version 10.3.3 Product Build 20110314 for Intel(R) 64 architecture applications
AllocatedBytes  : 2072960
AllocatedBuffers: 1
press ENTER

EDIT:
Here the static version that does not require the mkl_core.dll at runtime:

Code: Select all

EnableExplicit
DisableDebugger

OpenConsole()

ImportC "mkl_core.lib"
    mkl_get_version_string(*buffer.Ascii, len.i) As "_mkl_serv_getversionstring"
    mkl_malloc            (size.q,align.i)       As "_mkl_serv_mkl_malloc"
    mkl_free              (buffer.i)             As "_mkl_serv_mkl_free"
    mkl_mem_stat          (*nbuffers)            As "_mkl_serv_mkl_memstat"
    mkl_free_buffers      ()                     As "_mkl_serv_freebuffers"

    dgemm                 (transa.p-Ascii,transb.p-Ascii,*m,*n,*k,*alpha,*a,*lda,*b,*ldb,*beta,*c,*ldc) As "_mkl_blas_dgemm"
EndImport

;ImportC "mkl_intel_c.lib"
;EndImport

ImportC "mkl_sequential.lib"
EndImport


Define buffer, Version$

buffer = AllocateMemory(200)
  mkl_get_version_string(buffer,200)
  Version$ = Trim(PeekS(buffer,200,#PB_Ascii))
  PrintN( Version$ )
FreeMemory(buffer)

Structure mem
   Array a.d(0)
   Array b.d(0)
   Array c.d(0)
EndStructure

Define mem.mem
Define.i  n, i
Define.d alpha, beta
Define.q AllocatedBytes
Define.i N_AllocatedBuffers

alpha = 1.1 : beta = -1.2
n = 1000
mem\a() = mkl_malloc(n*n*SizeOf(Double),64)
mem\b() = mkl_malloc(n*n*SizeOf(Double),64)
mem\c() = mkl_malloc(n*n*SizeOf(Double),64)

For i = 0 To n*n
    mem\a(i) = i+1
    mem\b(i) = -i-1
    mem\c(i) = 0.0
Next i

dgemm("N","N",@n,@n,@n,@alpha,mem\a(),@n,mem\b(),@n,@beta,mem\c(),@n)

AllocatedBytes = mkl_mem_stat(@N_AllocatedBuffers);
PrintN("AllocatedBytes  : "+Str(AllocatedBytes))
PrintN("AllocatedBuffers: "+Str(N_AllocatedBuffers))

mkl_free_buffers()

AllocatedBytes = mkl_mem_stat(@N_AllocatedBuffers);

If AllocatedBytes > 0
    PrintN("MKL memory leak!")
    PrintN("fter mkl_free_buffers there are "+Str(AllocatedBytes)+" bytes in "+Str(N_AllocatedBuffers)+" buffers")
EndIf

mkl_free(mem\a())
mkl_free(mem\b())
mkl_free(mem\c())

PrintN("press ENTER")
Input()

1st version is 11,5k but requires mkl_core.dll (6,7MB)
2nd version is 706k standalone

PureBasic Forums - English

True 64-bit Applications in PureBasic and Huge Numeric Types

Re: True 64-bit Applications in PureBasic and Huge Numeric T

Re: True 64-bit Applications in PureBasic and Huge Numeric T

Re: True 64-bit Applications in PureBasic and Huge Numeric T

Re: True 64-bit Applications in PureBasic and Huge Numeric T

Re: True 64-bit Applications in PureBasic and Huge Numeric T

Re: True 64-bit Applications in PureBasic and Huge Numeric T

Re: True 64-bit Applications in PureBasic and Huge Numeric T

Re: True 64-bit Applications in PureBasic and Huge Numeric T

Re: True 64-bit Applications in PureBasic and Huge Numeric T

Re: True 64-bit Applications in PureBasic and Huge Numeric T

Re: True 64-bit Applications in PureBasic and Huge Numeric T

Re: True 64-bit Applications in PureBasic and Huge Numeric T

Re: True 64-bit Applications in PureBasic and Huge Numeric T

Re: True 64-bit Applications in PureBasic and Huge Numeric T

Re: True 64-bit Applications in PureBasic and Huge Numeric T