-
Notifications
You must be signed in to change notification settings - Fork 776
Description
Hello,
At enterprise quality programming LLC, performance is one of the top priorities that a company would have. The slower the performance is, the less clients a company would have. It's one of our top goals to maximize the performance.
That being said, while Java is a great programming language, it can't beat the speed of C and C++.
So, in order to maximize the performance of the fizz buzz: enterprise edition, and to beat the competitors, we need to rewrite Fizz Buzz: Enterprise Edition in C++.
While it's possible to write assembly code that has better performance than C++, it would cost too much. Most C++ compilers, such as the Microsoft MSVC compiler, generate very fast executables, where optimizing it further is not worth it.
Since we are on C++, our very serious enterprise project only supports the very serious enterprise platform called "Windows NT", we can leverage:
- The native Windows API. Java has a translator which translates the instructions for a specific operating system. However, since we're only on Windows NT, we can avoid doing such conversions and instead directly use the Windows API.
We also don't have to worry about destroying the performance and significantly increasing the dependency count when leveraging:
- The C++ standard library. It has a lot of useful things which don't destroy the performance, unlike Java. It also doesn't require a lot of dependencies (just an 11 gigibyte installation of Visual Studio) to run quickly and without performance issues.
I haven't listed all of the upsides of rewriting our very serious enterprise project to C++.
The only downside of this is that we will be using the Windows API, which means that if some company ever decides to use Linukz as their operating system, even though it's not a serious business environment, they won't be able to use our project, which will lead to revenue loss.
What do you think about my proposal?
Activity
GEOEGII555 commentedon Jul 7, 2024
We could also use transactional NTFS to avoid data corruption on unexpected system crashes, however, unfortunately, Microsoft corporation has deprecated it. From their website:
We could use one of the following alternatives, as suggested by the Microsoft corporation:
GEOEGII555 commentedon Jul 7, 2024
I may be able to implement this, but be aware that I don't have a lot of experience in enterprise development
Tylersuard commentedon Jul 8, 2024
I have seen roadblocks like this kill perfectly good projects. Please code directly in Prod.
GEOEGII555 commentedon Jul 8, 2024
I don't have access to the production (
uinverse
) branch.GEOEGII555 commentedon Jul 8, 2024
#694
ryanolee commentedon Jul 23, 2024
It appears that c++ is simply too slow for our applications. It pains me to say that we will have to rethink this as a custom FPGA or if demand allows our own custom silicon. I have contacted TSMC: they have given me a 200 year lead time to get on their sub quantum node. ASML have been dragging their heels on making the lithography machine required and have given such asinine excuses "it is not physically possible".
I will keep you posted
GEOEGII555 commentedon Sep 6, 2024
This can't be true. C++ is a blasingly fast and (if used correctly) memory safe programming language.