In Germany you need 20k Euros cash, and an accountant, and to pay all the "bureaucracy costs" of registering a new company.
That's something you have to pay independently of whether your startup is making money or not.
2,917 karma · joined April 21, 2019
That's something you have to pay independently of whether your startup is making money or not.
Everything your employer gives you as part of your salary is subject to the salary tax. Whether your employee gives you options or shares, doesn't matter, you need to taxate them, and that requires assigning them a value.
If your employer gives you options, you can only exercise them when the shares you buy have a value (via an IPO, acquisition, etc.), so you pay taxes on the value when you exercise them - verifying this value is trivial for the tax office (check purchase price of shares, IPO share value, etc.).
For publicly traded companies, if your employee gives you shares, you pay taxes when you get the shares on the value of the shares on the day that you got them.
If your employee gives you shares from a private hold company, those shares have no value until the company gets public or acquired. You'll taxate them not on the share price that the share had when you got them, but the one it has when it went public.
Exactly my point.
The reason there is really no cool tech firms in the EU is because the EU economic policies make them impossible.
Working for a startup is an extremely risky decision. As a top engineer, you get shitty pay, and a really good options package that in most cases ends up being worth nothing because most startups fail.
In the US, however, if your startup cashes out, you end up rich. This is not only a life changing experience, some of these rich top tech engineers end up creating their own startups afterwards with the money they make, which perpetuates the cycle.
In Europe, if as a top engineer your startup cashes out, you only end up marginally better than if you had had an 8-5 job at BigTech (Google, Apple, Microsoft). Almost 50% of your cashout goes away in taxes, and the rest barely compensates the bad paid you got the last 5-10 years of your life, and if you take "worked hours/week" into account, quality of life, and risk taken, the value proposition is just a joke.
Startups already have a very hard time flourishing with top talent. Europe makes it almost impossible for these to attract top talent, so that's why you don't see as many unicorns here as you do in the US.
This doesn't mean there aren't any startups in Europe. There are. There are just much fewer than in the US, have an even lower success rate, and a less qualified and risk-friendlier employee base.
Source: my own personal experience job hunting in Germany, for many US startups operating here, where most of them actually try to offer BigTech salaries without option packages because they know option packages do not make sense here.
Source 2: https://notoptional.eu/
Techcrunch: https://techcrunch.com/2018/11/27/30-european-startup-ceos-c...
It's pretty much impossible to see the US getting involved.
The UN doesn't recognize Taiwan as an independent country, so China would just be exercising their authority over a chinese company, just like they do with Huawei, Lenovo, and many others.
NATO couldn't help either, because the US is not being militarily attacked by this. And well, the US has severed both their military ties with NATO, as well as their political ties with all countries in NATO (Paris agreement, Iran nuclear deal, tarifs, empty embassies, in bed with North Korea...). Also, many NATO countries are in bed with China economically, building the new Silk Road...
So... if China were to grab TSMC, and the US would try any kind of military action, who would support the US ? Europe, Russia, South Korea, Japan, South America, the Middle east, Australia, ... they would all stand by China. The US has been screwing them over the last 4 years, while China has been giving them money for them to return them the favor in a time like this.
Or do you imagine Trump going throughout the world kissing others asses to get their support?
Yeah, no. If Trump was "brave" enough to take military action, it would be game over before it even starts: world-wide embargo against the US, all US international companies assets frozen, the S&P500 would hit zero in a matter of days, inflation would explode, the troops wouldn't be getting paid, etc. The largest military force in the world would crumble in a week before even taking the first shot.
Once you have put a lot of money into a product, it is very hard to start a new one from scratch and let the old one die.
I'll bite.
Have you ever been getting a haircut, and the hair dresser had to stop to pick up the phone to make an appointment?
Have you ever go to actually pick up a pizza at a small pizzeria and noticed that from 4 employees, 3 are making pizzas, and one is 99% of their time on the phone?
Every single business that you've ever used in your life would be better off with an Alexa that can handle the 99% most common user interactions.
In fact, even small pizzerias and hair salons nowadays are using third-party online booking systems with chat bots. Larger companies are able to turn a 200 people call center into a 20 man operation by just using an Alexa to at least identify customers and resolve the most common questions.
Give the Id to everybody who wants it for free. If someone cannot prove citizenship, but they can prove having worked or lived in the US for more than 5 years (checks, bank receipts, etc.), give them citizenship.
There, problem solved. That way, you only discriminate against those who are either in the US illegally and are not working, or are working but have been illegally living in the US for less than 5 years, and both situations are fixable by the individuals themselves (work for 5 years and "earn" your citizenship).
Of course, what many want is an Id that can actually be used to prevent poor people from voting, while also being able to employ those same poor people at very low rates using the fear of "reporting them".
Like, if a bank is able to reset my password, how safe is it really ?
You can also mix C, OpenACC, and CUDA C, and compile to x86-64. So I'm really not sure about what point you are trying to make here.
You were claiming that OpenACC and CUDA only runs on nvidia's hardware, yet I suppose you now agree that this isn't true I guess.
I do agree that PGI is still nvidia owned, but there are other compilers that do what PGI does.
So to me the main realization here is that in tech, if one competitor ends up with tech that's 10 years more advanced than the competition, it is basically a divergence-type of phenomenon. It isn't worth it for the competition to even invest in trying to catch up, and you end up with a monopoly.
This isn't very surprising I think. AMD cards often have higher FLOPs than NVIDIA's, and I can imagine that they run HPL really well.
I can't wait to try these systems. I want to see what the OpenMP performance there looks like for normal applications.
If your floating-point precision isn't high enough, you'll end up instead with a "subspace" that isn't spanned by orthogonal vectors, and the consequences of this are pretty drastic (requiring n-times the number of iterations to solve the system, you'll never find a solution, etc.). These all happen even if your system of equations has a good condition number, you just need to make the precision low enough.
This is why most people use double precision, and some people use quad precision. For many systems, e.g., if you are using CG as your solver, quad precision can cut the number of iterations by a large factor (2x-4x). These problems are still bandwidth bound, and using quad precision duplicates your memory bandwidth requirements, but if it reduces the number of iterations by 4x, you just halved your time to solution.
Today, you can write numpy code, and that runs on pretty much all CPUs from all vendors, with different levels of quality.
A one line change allows you to run all numpy code you write on nvidia GPUs, which at least today, are probably the only GPUs you want to buy anyways.
In practice, you would probably be also running your whole software stack on CPUs, at least for debugging purposes. So if you change your mind about using nvidia hardware at some point, you can just revert that one line change and go back to exclusively targeting CPUs. Or who knows, maybe some other GPU vendors might provide their numpy implementation by then, and you can just go from CuPy to ROCmPy or similar.
Either way, if you are building a numpy stack today, I don't see what you lose today from using CuPy when running your products on hardware for which that's available.
Clang already has a CUDA parser, and all the code to lower CUDA specific constructs to LLVM-IR, some of which are specific for the PTX backend. If you try to compile CUDA code for a different target, like SPIRV, you'll probably get some errors saying that some of the LLVM-IR instructions generated by clang are not available in that backend, and you'll need to generate the proper SPIRV calls in clang instead.
Its probably a great beginner task to get started with clang and LLVM. You don't need to worry about the C++ frontend side of things because that's already done, and can focus on understanding the LLVM-IR and how to emit it from clang when you already have a proper AST.
If you have 1 triangle mesh, and instance it 100 billion times, you don't need to do that.
> "more than 33 million triangles."
The assets the company they mention makes have 100s of millions of triangles, and billions as well. So I wonder if they are not using those original assets after all.
IIUC they are, but they are only rendering at lower triangle counts and the LOD happens automatically.
But in the late 80s and early 90s they actually had the i860 and its variants: https://en.wikipedia.org/wiki/Intel_i860
which contained a graphics processor! That wasn't a particular success but it landed us the MMX ISA on x86.
Surprisingly enough, Intel went then to make similar mistakes with Itanium, and then with Larabee. But both things landed us features on x86.
How can they sue you for using something that they give you with a license that says "we allow you to do whatever you want with it" ?
This is widely inaccurate.
While Google did developed a PTX backend for LLVM, the student that worked on that as part of a GSOC got later hired by NVIDIA, and ended up contributing the current NVPTX backend that clang uses today. The PTX backend that Google contributed was removed some time later.
> Nothing is "stable" nor "branded" in this work.
This is false. The NV part of the backend name (NVPTX) literally brands this backend as NVIDIAs PTX backend, in strong contrast with the other PTX backend that LLVM used to have (it actually had both for a while).
> OpenACC backend targets directly the nvidiaptx (proprietary) format.
This is false. Source: I've used the PGI compiler on some Fortran code, and you can mix OpenACC with CUDA Fortran just fine, and compile to x86-64 using OpenMP to just target x86 CPUs. No NVIDIA hardware involved.
> That's wrong again. > > Most of the work done for the parallel STL and by the C++ committee originate from work from HPX and the STELLAR Group
This is also widely inaccurate. The Parallel STL work actually originated with the GCC parallel STL, the Intel TBB, and NVIDIA Thrust libraries [0]. The author of Thrust was the Editor of the Parallelism TS, and is the chair of the Parallelism SG. The members of the STELLAR group that worked on HPX started collaborating more actively with ISO once they started working at NVIDIA after their PhDs. One of them chairs the C++ library evolution working group. The Concurrency working group is also chaired by NVIDIA (by the other nvidia author of the original parallelism TS.
AMD is nowhere to be found in this type of work.
[0] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n372...
NVIDA open-sourced their CUDA implementation to the LLVM project 5 years ago, which is why clang can compile CUDA today, and why Intel and PGI have clang forks compiling CUDA to multi-threaded and vectorized x86-64 using OpenMP.
That you can't compile CUDA to AMD GPUs isn't NVIDIA's fault, it's AMD, for deciding to pursue OpenCL first, then HSA, and now HIP.
NVIDIA announced today that Apache Spark 3.0 is built on RAPIDS and showed some benchmarks claiming same perf at 1/5 the cost.
Not your classical database application though.
There is a "library replacement" for CUDA from AMD called HIP, that you can use to map CUDA programs to ROCm. But... it doesn't work very well.
NVIDIA also open-sourced CUDA support for Clang and LLVM. So anybody can extend clang to map CUDA to any hardware supported by LLVM, including SPIRV. The only company that would benefit from doing this would be AMD, but AMD doesn't have many LLVM contributors.
Intel drives clang and LLVM development for x86_64, paying a lot of people to work on that.
This sounds like you'd like NVIDIA to open-source all their software. I see this type of request a lot, but I don't see it happening.
NVIDIA's main competitive advantage over AMD and Intel is its software stack. AMD could release a 2x powerful GPGPU tomorrow for half the price and most current NVIDIA users wouldn't care because what good is that if you can't program it? AMD software offer is just poor, of course they open-source everything, they don't make any software worth buying.
ARM and Intel make great software (the Intel MKL, Intel SVML, ... libraries, icc, ifort, ... compiler), and it doesn't open-source any of that either for the same reasons as NVIDIA.
Intel and NVIDIA employ a lot of people to develop their software stacks. These people aren't probably very cheap. AMD strategy is to save a lot of money in software development, maybe hoping that the open-source communities or Intel and NVIDIA will do it for free.
I also see these requests that Intel and NVIDIA should open-source everything together with the explanation that "I need this because I want to buy AMD stuff". That, right there, is the reason why they don't do it.
You want to know why NVIDIA has 99% of the Cloud GPGPU hardware market and AMD 1%? If you think 10.000$ for a V100 is expensive, do the math on how much does an AMD MI50 costs: 5000$ for the hardware, and then a team of X >100k$ engineers (how much do you think AI GPGPU engineers cost?) working for N years just to play catch on the part of the software stack that NVIDIA gives you with a V100 for free. That goes into multiple million dollars more expensive really quickly.
That already happened [0]. NVIDIA has a 1:1 replacement for Numpy called CuPy that does this and is what powers their RAPIDS framework (which is a 1:1 replacement for Pandas that runs on GPUs).
Some people were complaining in [0] about CuPy reproducing numpy's bugs..