Just because you didn't need it doesn't mean that there's no general need for it. However, I agree that probably only a minority of FB users would benefit from it. Potential users would also need some expertise to use it appropriately - it just doesn't make your existing applications magically faster. Anyway, as I mentioned earlier it is unlikely to be implemented anytime soon, so it's more or less pointless to discuss.lizard wrote:Seems LLVM and GPU support are not really needed, because all my programs were fast enough.
New version?
Re: New version?
-
- Posts: 538
- Joined: Dec 02, 2011 22:51
- Location: France
Re: New version?
One hand I agree angros47's post, other hand it is clear parallel processing is led to take an increasingly important place.
nVidia is pushing AI computing & big data,...
My opinion is a FB layer instruction set for parallel processing might be a lack in the future and we should think seriously about this one more issue.
On an other subject, how about my latest LZLE.bi (or an improved version) (https://freebasic.net/forum/viewtopic.php?f=8&t=26533) be included in package ? It is small, open source. The licence allows derivating programs and no limitations of use (till it is used into Fb ecosystem). I'm on a tutorial and I'll do a small support for bugs fixes. (Yes, certainly bugged but efficient and usable, I hope). Could be a great tool for beginners or middle programmers who expect for something fast and "easy" to code.
nVidia is pushing AI computing & big data,...
My opinion is a FB layer instruction set for parallel processing might be a lack in the future and we should think seriously about this one more issue.
On an other subject, how about my latest LZLE.bi (or an improved version) (https://freebasic.net/forum/viewtopic.php?f=8&t=26533) be included in package ? It is small, open source. The licence allows derivating programs and no limitations of use (till it is used into Fb ecosystem). I'm on a tutorial and I'll do a small support for bugs fixes. (Yes, certainly bugged but efficient and usable, I hope). Could be a great tool for beginners or middle programmers who expect for something fast and "easy" to code.
Last edited by Lost Zergling on Mar 27, 2018 12:17, edited 3 times in total.
Re: New version?
St_W wrote:I agree that probably only a minority of FB users would benefit from it.
Right. LLVM will not give much advantage i would guess, because we have seen recently in the speed comparison from benchmarksgame
http://benchmarksgame.alioth.debian.org ... stest.html
that gcc already is the fastest. GPU programming maybe useful if there are gigantic numbers of graphic operations to do, like in a professional game.
Working towards FreeBASIC 1.06 release
It's really great being able to add FreeBASIC to a PC and need *nothing* else to write a program in basic.multineu wrote:Hello,
what about a new freebasic release?
I agree.TeeEmCee wrote:Most users are likely to use the latest official release rather than an unofficial build.
Just want to throw this question out there: What makes a release "official?"
Currently, I would say:
1) available from a trusted source
2) has a (relatively) high level of quality (compared to development)
3) works as intended for a given platform
4) just binaries, no extra compiling/building needed
Here's an idea: what about an "official" source code release? To compare, many GNU/Linux packages are released as source code only. On windows, most mingw* binary packages are made by MinGW project, and not by the source code authors.
I saw the Raspberry PI interest in another thread, and thinking someone *should* make a release package for that platform. There's also the emscripten branch v1ctor added some time ago.
To make it happen this way, we would need to change our perspective. Instead of releasing all the binary packages on one day, we need to add a concept of source code release date and tag the new version in the repository. The source code would be the official release.
I know I am simplifying here, because to ensure the quality, we still do have to look at:
- compiler stability
- bindings (headers)
- documentation
- examples
- that the source release can build working binaries
however, any patches that are needed to make a release could be merged back in to the development tree through pull requests.
Final thought, if, for example, St_W, Keitlo, PaulSquires, Kuan Hsu, were to build a release, would it be any less trustworthy than an "official" release?
-
- Posts: 538
- Joined: Dec 02, 2011 22:51
- Location: France
Re: New version?
What makes a release "official" ? For me ? Spirit. https://freebasic.net/forum/viewforum.php?f=1 this : https://freebasic.net/forum/viewtopic.php?f=17&t=22903 Paul Squires forum maybe. There was another site I don't remember with a very old GPL repositery version Basic core (a sort of guardian of the temple). The few most honored are official.
Re: New version?
I'd say, it's (in a nutshell):coderJeff wrote:What makes a release "official?"
- 1) finished (executable binary, bindings, examples, doc, e.t.c.)
2) tested and "signed off" by an Administrator (and nobody else!)
Re: Working towards FreeBASIC 1.06 release
IMHO it's mainly what you mentioned first: the availability (and announcement) from a trusted source, which is the FreeBasic sourceForge page currently (or maybe the GitHub project page). The completeness and proper functioning is implicitly assumed for an official release, but it isn't really a criteria (at least not for a user) deciding whether a release is official or not.coderJeff wrote:What makes a release "official?"
While I definitely see the advantages and simplifications for compiler developers at one side there are unfortunately also some cons for users on the other side. Especially Windows (and DOS) users won't compile FreeBasic themselves, so they still want to get binary packages. However, how do they find them if they aren't available from the official project site? And, even worse, imagine that there are competing builds made by different users: how should a (new) user decide which to choose?coderJeff wrote:Here's an idea: what about an "official" source code release? To compare, many GNU/Linux packages are released as source code only. On windows, most mingw* binary packages are made by MinGW project, and not by the source code authors.
I think so too. RPi users are often new to Linux and thus uncomfortable with compiling software themselves.coderJeff wrote:I saw the Raspberry PI interest in another thread, and thinking someone *should* make a release package for that platform.
I agree that this is probably necessary, especially if additional platforms are going to be added. But IMHO there should still be some official maintainers who are responsible for creating a release package for a certain platform just like it has been done previously by a single person. The main difference will be that the work is distributed among several people.coderJeff wrote:To make it happen this way, we would need to change our perspective. Instead of releasing all the binary packages on one day, we need to add a concept of source code release date and tag the new version in the repository. The source code would be the official release.
Luckily we have a comprehensive set of unit/integration tests for the compiler itself (and nice tools like Travis CI), which should guarantee the first and last point. (similar tests for the rtlib/gfxlib2 would be nice to have, btw). For the other points maybe some manual checks are necessary.coderJeff wrote:[...] to ensure the quality, we still do have to look at:
- compiler stability
- bindings (headers)
- documentation
- examples
- that the source release can build working binaries
I don't know which tests were performend for previous releases, but it would be a good idea to document that and try to automate it. IMHO automation is the key to simplify the release process. Ideally the whole package creation would be automated and could be triggered at any time for any source code release.
As long as they (including my humble self) don't distribute the builds on "official" sources or the source isn't mentioned to be official on an official communication channel of the project (like the freebasic.net website) then IMHO Yes, I'd consider them less trustworthy (at least if I were new to FreeBasic).coderJeff wrote:Final thought, if, for example, St_W, Ketilo, PaulSquires, Kuan Hsu, were to build a release, would it be any less trustworthy than an "official" release?
Re: New version?
-----------angros47 wrote:Making FreeBasic able to compile existing code to run on GPU is not realistic: as far as I know, not even GCC or FreePascal can do that. The reason is that a GPU works in a completely different way, and the code has to be different. Even if it resembles C, the GLSL is not C, and existing C code cannot be compiled on it.
A GPU works in parallel, so a lot of things (like pointers and references) cannot be used (since every process is isolated, and there is no defined order of which one will run before or after). Also, the code optimization has to be different, since branching is slow (many cards have only one branching unit shared by several processes), and the parallel code makes it not necessary (instead of choosing a branch, they both can be evaluated in parallel, and after that the unwanted data can be discarded). So, code must be re-thought anyway.
Strange to hear all this: I often make programs using CUDA C/C++ and it seems a bit extended than normal C/C++.
If it is not possible to generate LLVM code then exporting CUDA C/C++ would not that difficult. Taking in account that __managed__ variables (SM > 3.0) allows to see a variable from host and from GPU in a direct way (hiding cudaMemcpy).
Pointers are pointers in CUDA too as GNU C (for example) does. The only things that changes is the access and the possibility to run in parallel.
declaring a variable visible from host and device:
const int N=4096;
__device__ __managed__ int array[N];
accessing the array from host:
.
.
for (int i=0;i<N;i++) {
... array ...
}
.
.
accessing the array from device:
.
.
int i=threadIdx.x + blockDim.x*blockIdx.x;
if (i<M) {
... array ...
}
and a suitable calling: <<<N/256,256>>>()
is it really so difficult to generate this kind of code?
Re: New version?
-------------------------angros47 wrote:Making FreeBasic able to compile existing code to run on GPU is not realistic: as far as I know, not even GCC or FreePascal can do that. The reason is that a GPU works in a completely different way, and the code has to be different. Even if it resembles C, the GLSL is not C, and existing C code cannot be compiled on it.
A GPU works in parallel, so a lot of things (like pointers and references) cannot be used (since every process is isolated, and there is no defined order of which one will run before or after). Also, the code optimization has to be different, since branching is slow (many cards have only one branching unit shared by several processes), and the parallel code makes it not necessary (instead of choosing a branch, they both can be evaluated in parallel, and after that the unwanted data can be discarded). So, code must be re-thought anyway.
Julia produces GPU code via LLVM. Does it seem realistic? Why shouldn't it be realistic? it is an imperative language, procedural.
FreeBASIC has a C backend. With a bit of tricks it could generate CUDA code.
The possibility to implenet __managed__ variables allows to access the variable from CPU and GPU hiding cudaMemCpy.
As far as I know pointers are pointers in C/C++ CUDA and in FreeBASIC: the only way is changes is access. Paralle via threadIdx.x / blockIdx.x / blockDim.x and <<<>>> calls VERSUS for () loops.
Of course would be needed a rethink of the code generated but.. is it so much difficult?
-
- Posts: 538
- Joined: Dec 02, 2011 22:51
- Location: France
Re: New version?
multineu. Implementation is difficult and would requires lots of work and serious skills in design, ergonomy, compiler, graphic prog and processors in general. Up to my humble opinion (if anyone still interested) your suggestion is more looking like a direct link access to nVidia solutions(hard & soft) than a thrue evolution of Basic language itself. Addendum : Clang is an interesting idea for creating models. Drawback : less "home made", some of the solutions are already provided.
-
- Posts: 2958
- Joined: Jun 02, 2015 16:24
Re: New version?
Why not reintroduce bundles? I mean, the first versions of FB came bundled with some IDE, indeed FBIDE. So it would be possible to post new "releases" that would be actually new bundles or new bundles updates, besides the naked pure fresh fbc update which could come when it comes, provided that we have something new to try in the meantime (IDEs).
Re: New version?
Nope, don't agree with bundles, since they are not comparable, to a new release!
And, in any case, only for beginners useful, since other users have their preferred
IDE already chosen ... (at least, most of them).
A new release is currently most needed since, there have been quite a lot of
updates, fixes e.t.c. to the compiler's (FBC 1.06.0 32/64).
They don't necessaryly have to be released at the same date, for all platforms.
Let's say, WIN first, then LIN second, then DOS (based on: num. downloads/OS).
And, in any case, only for beginners useful, since other users have their preferred
IDE already chosen ... (at least, most of them).
A new release is currently most needed since, there have been quite a lot of
updates, fixes e.t.c. to the compiler's (FBC 1.06.0 32/64).
They don't necessaryly have to be released at the same date, for all platforms.
Let's say, WIN first, then LIN second, then DOS (based on: num. downloads/OS).
Re: New version?
Yup, it is so much difficult. If it's not, then by all means go ahead and code it up and add submit it to the FB devs. FB is open to contributions from all of us forum members if we wish to help.multineu wrote:Julia produces GPU code via LLVM. Does it seem realistic? Why shouldn't it be realistic? it is an imperative language, procedural.
FreeBASIC has a C backend. With a bit of tricks it could generate CUDA code.
The possibility to implenet __managed__ variables allows to access the variable from CPU and GPU hiding cudaMemCpy.
As far as I know pointers are pointers in C/C++ CUDA and in FreeBASIC: the only way is changes is access. Paralle via threadIdx.x / blockIdx.x / blockDim.x and <<<>>> calls VERSUS for () loops.
Of course would be needed a rethink of the code generated but.. is it so much difficult?
Remember that Julia is a special purpose language, for one, and the problems it targets are benefited from GPU parallel-processing whereas FB is like C or C++, and is much more general. And Julia's a popular language that is supported by a number of developers actively. Currently the FB compiler is only being worked on by a very few people in their free time. Like between 0 and 1 persons to be precise. So it's just not going to happen, even if it was advantageous to a few people. If it's worth it to you, feel free to fund development, or contribute development time yourself.
So given the present amount of resources available, no it's absolutely not realistic to think FB would ever be able to emit CUDA code. Unless, like I say, some code shows up from a generous contributor.
And if there were resources, I don't think they'd be best spent adding CUDA capabilities to the language. It's just not needed. CUDA can be used by those who need it in FB just like it can in C or C++ already, through interface libraries. No one is calling for C or C++ to be integrated with CUDA. That might have something to do with the fact that most CUDA compilers compile a C-like language.
-
- Posts: 8586
- Joined: May 28, 2005 3:28
- Contact:
Re: New version?
FreeBASIC is a cross platform compiler Windows and Linux PC's and tablets
and for some ARM devices and may be in future MAC OS too. (If you give me a modern one)
Use open source OpenCL for cross platforms.
Windows, Linux, MAC OS supported by Intel, AMD, NVIDIA, ARM and many FPGA manufacturer.
I hate this NVIDIA only closed source CUDA bla bla bla ...
Joshy
and for some ARM devices and may be in future MAC OS too. (If you give me a modern one)
Use open source OpenCL for cross platforms.
Windows, Linux, MAC OS supported by Intel, AMD, NVIDIA, ARM and many FPGA manufacturer.
I hate this NVIDIA only closed source CUDA bla bla bla ...
Joshy
Re: New version?
Good point. Either way, the tools are available to FB programmers right now without any special integration.
I don't mean to come across snobbish when I say fund it if you want it, or do it yourself. People have weird expectations of open source software is all. Everything comes at a cost. Free software costs you still, just in different ways. It's not a wishing well, though I wish it were!
I don't mean to come across snobbish when I say fund it if you want it, or do it yourself. People have weird expectations of open source software is all. Everything comes at a cost. Free software costs you still, just in different ways. It's not a wishing well, though I wish it were!