Earlier quoted context omitted.
Note that they use C# and ASP.Net... (SO and DailyWTF are very much into Microsofts ecosystem)
Anything wrong about that?
No, I'm just pointing out that they are different from your average SV company.
A lot of complex “scalable” systems can be done with a simple, single C++ server
251–260 of 376 posts
Re: A lot of complex “scalable” systems can be done with a simple, single C++ server
#252Earlier quoted context omitted.
> The problem with shared_ptr is the fact that it uses atomics even in single-threaded code, which is obviously an overkill. On the other hand imagine the security issues if shared_ptr was not thread-safe - you could just not reliably destroy a shared_ptr in any thread. If you really know that you're going to get a graph of shared_ptr that do not move of a single thread, you can use boost::local_shared_ptr explicitel…
One of the advantages of rust is its ability to segregate safe-to-share (between concurrent contexts) and not so, at compile time. While it can’t (yet?) be generic over them, it lets you use the non-atomic Rc in thread-bound structures and know this is never going to be shared between threads, whereas the more expensive Arc can have handles be moved from one thread to an other.
Counterparts for Rc [1] and Arc [2] (and compiler enforcement of their safe use [3]) are available in C++, though not standard.
[1] https://github.com/duneroadrunner/SaferCPlusPlus#reference-c...
[2] https://github.com/duneroadrunner/SaferCPlusPlus#tasyncshare...
Re: A lot of complex “scalable” systems can be done with a simple, single C++ server
#253Many developers severely underestimate how much workload can be served by a single modern server and high-quality C++ systems code. I've scaled distributed workloads 10x by moving them to a single server and a different software architecture more suited for scale-up, dramatically reducing system complexity as a bonus. The number of compute workloads I see that actually need scale-out is vanishingly small even in indu…
But isn't the containerization trend leading us to a completely opposite direction ie. scale-out by default and do that not only because of performance but mainly because of how you want to manage your production environment?
Re: A lot of complex “scalable” systems can be done with a simple, single C++ server
#254Earlier quoted context omitted.
Talked to many people lit you mentioned. Large percentage repeats these points: 1) We always wait for database, so performance of our code does not matter . This comes from places where ironically the whole database can fit into RAM. 10+ gbps connectivity - well it is almost commodity for business so the latency is not much of a bottleneck. Fast IO to store data - well imagine array of Optane drives. Not very cheap b…
> Sorry but experienced developer can implement those just as fast as in any scripting language and it will save a ton on maintenance. This is just a no true Scotsman argument. For 10 years I’ve watched python/ruby shops drastically outpace projects in C++/Java shops. What you’re failing to realize is how trivial most apps are and how fast fully functional back ends can be created with frameworks in those languages (…
"What you’re failing to realize is how trivial most apps are and how fast fully functional back ends can be created with frameworks in those languages (django/rails)."
Sorry but I have the exact opposite experience. First of all I would not call line of business applications incredibly simple. They're rather quite complex business rule wise. I saw floors filled with web developers constantly writing /rewriting endless stream of scripts often without any meaningful attempts to organize the code. In one example I was writing Python (yes guilty it is good for this type of tasks) scripts to process literally thousands of files of their source code to find and properly replace database access methods of which single app had not less then 5.
Ability to maintain code is entirely up to how well organized and documented it is. It has nothing to do with “scripting”
This I can 100% agree with
Re: A lot of complex “scalable” systems can be done with a simple, single C++ server
#255Many developers severely underestimate how much workload can be served by a single modern server and high-quality C++ systems code. I've scaled distributed workloads 10x by moving them to a single server and a different software architecture more suited for scale-up, dramatically reducing system complexity as a bonus. The number of compute workloads I see that actually need scale-out is vanishingly small even in indu…
Can you expand on this? I have some pretty massive compute loads that need to be scaled onto a cluster with 100+ workers for most computations. This is after I use a library called dask that graphically does its own mapreduce optimisation inside its modules. This is all for a relatively small 250GB raw data file that I keep in a csv (and need to convert to SQL at some point). Are you saying this can be optimised to f…
If there are floating point numbers in those csvs, I sped up a system like that 10x just by writing a custom (Java equivalent of) atof() that didn't do variable decimal separators and scientific notation. That's not even counting the improvements in I/O speed from the size reduction. Any system that works from CSV's is going to be slow. I don't know what sort of computations you're doing of course, but I did all the work on a laptop, couldn't be bothered to scale it out after the improvements I made in the first pass. How much of your code spends its time in I/O (including conversions) vs actually calculating?
Re: A lot of complex “scalable” systems can be done with a simple, single C++ server
#256Earlier quoted context omitted.
Many other people "know" about the GIL, to the extent of believing there's no point using threads in python "because of the GIL". I had a funny such experience lately in a job interview. I told the interviewer his misconception could be falsified with ~10 LOC summing a list with 2 threads.
Ok, I see some comments (rightfully) asking for less talk and more code. # main.py import random from concurrent.futures import ThreadPoolExecutor as Pool items = [random.random() for _ in range(10 ** 7)] def run(items, n): step = len(items) // n with Pool(max_workers=n) as ex: res = [ex.submit(sum, items[i*step : (i+1)*step]) for i in range(n)] return sum(r.result() for r in res) if __name__ == '__main__': import ti…
And with no threads: 49.6 ms ± 947 µs per loop.
I’m pretty sure the time “savings” you are seeing here come from somewhere else. At a first glance, your copying the huge list while submitting it to the thread pool, this has overhead. Maybe lots of smaller copies are faster on your machine.
Re: A lot of complex “scalable” systems can be done with a simple, single C++ server
#257Scalability and performance are very different.
Opting for a performant but not scalable solution is basically an acknowledgement that:
- The project will only succeed up to a certain point.
- After the initial launch, no further changes will be made to the project since new additions are likely to cost performance and lower the upper bound on how many users the system can support.
Not many projects are willing to accept either of these premises. Nobody wants to set an upper bound on their success.
Also, it should be noted that no language is 'much faster' than any other language. Benchmarks which compare the basic operations across multiple languages rarely find more than 50% performance difference. The more significant performance differences are usually caused by implementation differences in more advanced operations and in any given language, different libraries can offer different performance characteristics so it's not fair to say that a language is slow because some of its default advanced operations are slow.
Usually, performance problems come down to people not choosing the best abstract data type for the problem. Some kinds of problems would perform better with linked list, others perform better with arrays or maps or binary trees.
Time complexity of any given algorithm is way more significant than the baseline performance of the underlying language.
Re: A lot of complex “scalable” systems can be done with a simple, single C++ server
#258A site for proof. It keeps amusing me on what hardware/software Stack Overflow/Stack Exchange is running on: https://stackexchange.com/performance This is way less in HW than most people in the trade (from web devs to devops) seem to think when asked about it. SO ranks #36 in Alexa right now: https://www.alexa.com/siteinfo/stackoverflow.com
Any reason for such a low (<5%) average CPU usage? It seems like a waste of resources to me; that's assuming a "normal" CPU usage read that includes wait i/o time.
Re: A lot of complex “scalable” systems can be done with a simple, single C++ server
#259Earlier quoted context omitted.
Can you expand on this? I have some pretty massive compute loads that need to be scaled onto a cluster with 100+ workers for most computations. This is after I use a library called dask that graphically does its own mapreduce optimisation inside its modules. This is all for a relatively small 250GB raw data file that I keep in a csv (and need to convert to SQL at some point). Are you saying this can be optimised to f…
You have 250GB of "raw" data stored in CSV format. The parsed version of this data in memory is likely to be a fraction of the on-disk size. A `long` or `double` only take up eight bytes in memory but 10-20 bytes on disk stored as ASCII in a CSV file. Even if your raw data was 250GB you could store it in memory mapped files. A fast SSD can easily hit a gigabyte per second sequential read speed, far faster than your t…
> A fast SSD can easily hit a gigabyte per second sequential read speed, far faster than your typical network.
It's important to note that often your disks aren't directly attached to your compute. That's frequently the case in (particularly cheap) cloud instances.
Re: A lot of complex “scalable” systems can be done with a simple, single C++ server
#260Earlier quoted context omitted.
It's mostly a fallacy that a demanded product becomes "developed". Maybe a game that gains cult status and therefore a long tail end of life. But popular web services are in constant churn and in that space it's valid to trade hardware for programmer productivity.
Backend web development doesn't change much once developed. How many ways can one do CRUD on the backend?
Out of curiosity, have you ever actually been employed as a backend web developer?