π³π±
I wish i knew someone skilled and motivated enough to be worth partnering with on my new company. I've got a good board and other aspects figured out but I always struggle to find other tech talents that are both interested and have the time to invest when I start a new project...
@freemo
perhaps you could tell more about how do you define [ tech talents]. in that way, you will probably find the people you wanted 
@igeljaeger
I dont really expect to find what I need on here. The stuff I deal with tends to be some of the more difficult stuff but nothing that requires a specific talent. Take Aparapi as a pretty good example. Its a java project that literally reverse engineers java bytecode ont he fly and rewrites it into different languages (specifically for a opencl). The biggest bottleneck for people helping on that isnt lack of opencl knowledge or any particular tech, its just being sharp enough to know how to address a problem as difficult as what I describe.
Sort of, though I dont look at a degree as a factor when hiring. But it would likely be suited for people at that sort of level I suppose yea.
@freemo
Aparapi and OpenCL
never heard of before... I hope you will find this person soon!
hmmm, I wonder if considering an entire social network too "dull" to work on the high grade, purely intellectual stuff (java bytecode plumbing, seriously?) that you're about has something to do with your inability to find "sharp" people.
I'm not sure reverse engineering java bytecode into C code capable of being able to be compiled and run on a GPU in real time is "plumbing", but hey whatever you gotta tell yourself I guess.
I never claimed the entire social network was too dull to be capable of it. Only that I dont find it an effective way to scout for programmers is all.
I'm sure that's what you meant. It's just that your words sometimes line up in funny ways, and I can't help but mock them.
I didn't mean to imply that it's somehow unimpressive by calling it plumbing. Just that, contrary to the implication that it requires solely some vague notion of "pure intelligence", I think it requires someone with very particular prior knowledge and motivation - someone who is either in love with Java or otherwise dependent on it, as I don't think it is a language that lends itself to highly parallel programming any better than those already supported by opencl.
OpenCL doesnt support any languages, it is itself a language though based on C99.
As far as I know there are no software solutions on any high end languages that does what this app already does. Only the JVM was selected because it supports many other languages. While it was written in java it supports any language that can run on the JVM which is most languages.
I do agree previous knowledge of Java or at least a willingness to work in it is critical. But I find once people are at the intellectual arena of focusing on the more algorithmic stuff the language isnt really much of a barrier for them. I can usually write in any language I feel like that day though I am a bit more advanced in some it doesnt really effect what I do much.
@freemo @Sphinx @igeljaeger sure, replace Java with, Java bytecode. I don't think it lends itself to parallel programming better, than the C(C++14 I read?) subset that opencl uses(supports? is? whatever). If it did I'm sure it would lose any advantage it had when going through C instead of directly to spirv. And any language that has any sort of advantage in the field over others is likely to loose that advantage by going through the bytecode(and than C). I don't think anyone asking themselves "how can I do high level highly parallel programming well" will arrive at this. Instead people who already use and depend on Java bytecode (whatever language they are using) will arrive at this.
No other solutions? I don't know the full feature set of your project, but wouldn't llvm spirv backend, or various projects surrounding it, be a direct competitor? (again if you ask "what to use for highly parallel programming language backend in general" not "what to use for Java bytecode specifically").
Thats not really the point of the project, to lend itself to parallel programming.. as is it isnt intended to parallelize any old arbitrary code (most wouldnt speed up).
The point is that if I want to write an app that is specifically written to be parallelized on a GPU but also capable of falling back to running as plain-old java should GPU support not be available.
Its more about platform independence than anything else. Write some code once and it will accelerate as fast as hardware lets it but wont ever completely fail due to lack of hardware either.
Not sure how useful a fallback would be for a program that is written specifically for a GPU. According to the visualization presented on your project it would be equivalent of freezing :D
A hardware independence I would say is much more important for general code that can run reasonably well on CPU, but also benefit from GPU.
That said, I believe that's what llvm is about as well, and in attempts to go as fast as hardware allows it has much better chances, since the IR is much richer from what I understand(not an expert).
Depends how you write it. If the example were real life then there would be fewer bodies simulated when falling back to java. So the app wont usually freeze it will just reduce the workload ideally.
Aparapi is built on llvm actually. All the criticism aside its used by many projects and companies.
Yeah, I suspected that the C has got to use llvm anyway :D
Even further proves the point that it is specific to projects/people who are otherwise attached to JVM. Nothing wrong with that, of course, not trying to bash your project, just nitpicking on your wording.
Most of our users do not appear to be using it because they are already on Java or the JVM. In fact most of them use other languages and werent on the JVM until they had a need for Aparapi at which point they moved their existing code base to run on the JVM specifically to leverate Aparapi. I'd say its probably 70% of our user base that fits that description.
Well I guess your users weren't "sharp" enough to move their codebase to llvm :D
Jokes aside, I wasn't talking about users, but people who would be personally interested to work on the project and invest in it. If they are "sharp" and the goal is "best way to do high level highly parallel programming", their first contribution would be to ditch JVM.
A much more humble premise such as "build a bridge between JVM and OpenCL/LLVM" would make more sense, but my point was it's much more specific on the skill and interest set.
Of course they could do the job without any prior experience or interest in JVM or Java( language doesn't matter and all) however how likely are they to be interested in such a project to the point of investment/partnership in that case?
No llvm would not replace the JVM in that respect, platform independence at runtime. llvm at best can ease compiling for an explicit set of platformsas seperate binaries.
Why exactly? Just because there isn't a pre-installed llvm runtime for the target platform? I mean, you can set that up if you are a bit "sharper" than average. Unless the use cases are even more niche than I imagined. Running on platforms that are out of your control and only allow JAVA bytecode?
@igeljaeger Looking more for a partner with the new project, not hiring at my other companies right now
@snow The number of companies you have is more a legal matter than anything else. Not all of them are active at any moment, some have just me in it.
