How much your computer can do in a second (2015)

As others have commented, it's bytes per second. But also, they are not flushing the file to disk, so this might really just writing to memory (in form of the OS's page cache).

Sebb767• 6 years ago

Great idea! However, I found the hash part a bit confusing; why not use hashes per seconds or bytes per second for both of them?

bigdict2• 6 years ago

Great idea, but this is complicated by having to model the Python interpreter.

Asraelite• 6 years ago

Agreed, it would be better to stick to a low level language for this. It's made even worse by the fact that some operations will be internally delegated to C code while others are pure Python.

closeparen4• 6 years ago

This is so important. I see so many people farting around in the problems of highly scalable distributed cloud systems with thousands of nodes, not realizing that single-digit QPS per node is insanity, why don't you look there first? Computers are fast.

colecut• 6 years ago

I think they do this because their priority is decentralization and not speed

closeparen4• 6 years ago

You can achieve decentralization with a handful of nodes, and you can manage them using simple techniques without inviting the whole large-scale cluster scheduler problem.

What I'm talking about is like 3,000 nodes to serve 15,000 QPS. That seems like a lot of QPS, and so it makes intuitive sense to people that they'd need a big distributed system for it, unless they have a sense of how fast computers actually are.

dahfizz• 6 years ago

I think people do it because they buy into the hype train of some cloud tech and don't really think about if they need it or not.

yachtman• 6 years ago

No they do this because horizontal scalability is more general. Once you cross the threshold of what your meganode can handle you have to rewrite your code from the bottom up

lemmsjid2• 6 years ago

Having spent a lot of time in highly scalable distributed system land, I can perhaps give you few reasons:

1. Sometimes business needs require non-linear growth quickly. One day your perfectly optimized process now requires an n-squared algo across billions of records. Suddenly your one machine is tiny compared to what it used to be.

2. If you haven't scaled the workload horizontally, it can lead to a rewrite just to begin to distribute the load. When you hit the limits of a single machine, it is often a hard barrier that you cannot easily cross.

3. Distributed systems are distributing 3 main resources: memory, IO, and computation. IO especially quickly becomes a bottleneck on a single system, but memory is also quite thorny because memory management itself can be a bottleneck on a vertically scaled system.

4. People with distributed systems do obsess over single-node QPS. If it takes 5k nodes to do work and you can optimize down to 2k nodes, you are saving a lot of money! However, it isn't that simple and this is where being properly distributed gives you cost leverage. You might find that 5 highly scaled machines are more costly than 50 commodity machines, especially in the cloud ecosystems.

5. Finally, and probably to your point and the GP's points, you kind of have to go with the flow when it comes to the level of abstraction people are writing the code at. It takes increasingly specialized knowledge to optimize a process that will run well on a 100gb process (e.g. virtual machine garbage collection issues). You are knowingly sacrificing efficiency for the nice higher level abstractions.

That said, I would emphasize that the abstractions become a smaller slice of the performance pie when you're dealing with algorithmic complexity. C won't magically make your Python algo O(1).

I don't disagree with your main point btw. I think a well done processing / data pipeline should have distributed systems available and single-node computational scenarios available, because there is an undeniable complexity gain when you reach for a distributed system immediately.

closeparen4• 6 years ago

I'd argue that throughput that bad usually means you are doing something stupid and easy to fix, like making a blocking call in your single-threaded server process, doing per request what you should have done at startup, not indexing for your query pattern, etc. It's not like you need multiple person-years of Brendan Gregg-level wizardry to serve QPS in the low hundreds from <= 10 boxes. It should just happen, or else you should have a clear understanding of what about your workload is so intense.

Olreich• 6 years ago

Two things: scaling well in a single node environment necessitates separating concerns such that scaling across nodes won’t suck as much. And, C often cuts down O(n^2) algorithms in python to O(1) because the algorithm is O(1), but Python was doing n^2 memory allocations behind the back.

therealdrag02• 6 years ago

Who do you see doing that?

The places I’ve worked (small/med companies) with lots of instances were always well utilized. People understood well the cost of infrastructure and put effort into minimizing it. But as features and services and customers grow, so do instances.

therealdrag02• 6 years ago

Sometimes node count is a function of code organization (micro services) not throughput. And when the instances are collocated (10 on a single host) it’s not like they’re not utilizing the machines firepower. Individual instances might have low throughout but some and in aggregate there could be lots more.

dang2• 6 years ago

If curious see also

2017 https://news.ycombinator.com/item?id=13960183

2015 https://news.ycombinator.com/item?id=10445927

saagarjha4• 6 years ago

I'm not sure if you've decided to switch up the usual "past discussion" with "if curious see also", but FWIW the latter suggests to me "here is more material that is tangentially relevant that you might find interesting" while the former is very direct in what it's claiming to link to.

dang2• 6 years ago

I'm just looking for concise wording that no one will misunderstand as somehow critical of the repost.

The intention is simply link to interesting things that readers might be curious to look at. If the repost were bad we'd mark it [dupe] instead.

osrec• 6 years ago

Very interesting! I think every dev should have a sense of how long loops like these take, if only to have a good starting point for where to optimise code (only if needed - * insert quote on premature optimisation *).

alister• 6 years ago

How many times can we download google.com in a second? Exact answer: 4

I was a little suprised by this one. Sure, network connections are are going to be much slower than local operations, but where's the time going? Is it mostly the network latency? Google has a lean webpage, so I assume it has nothing to do with google specifically.

Junk_Collector4• 6 years ago

If your average connection has 100 ms (50 ms would be extremely good but doable these days) of round trip latency to Google.com, then you have a hard upper limit of 10 loads per second just to connect to the system. Then you have to move the data, store it in memory, parse it, and run it.

ummonk• 6 years ago

I'd be shocked if my latency to Google were even as high as 50 ms. Though downloading http will take 3 round trips for http and four round trips for https which will add up if the connection isn't kept alive after each download.

Edit: just tested and got these numbers for myself:

7-13ms to ping google.com

50-80ms to curl http://google.com

90-130ms to curl https://google.com

140-160ms to curl http://google.com http://google.com http://google.com http://google.com http://google.com

180-220ms to curl https://google.com https://google.com https://google.com https://google.com https://google.com

So should be able to download something like 20-30 copies of google with keep-alive, and ~10 without.

ghj2• 6 years ago

I think those were synchronous requests one after another. 250ms per page load sounds about right.

humblebee• 6 years ago

This also surprised me. A large part of it I'm sure has to do with the fact that I'd assume (given these numbers) urllib2 auto follows redirection. The request is to `http://` so it must make an additional request. Otherwise I'd expect them to be much higher as there would be no 'body' to the responses.

EdTsft• 6 years ago

On mobile Firefox (at least for me) nothing appears below the intro message. The last line I see is "Made for you by ...".

markstos4• 6 years ago

Computers are also slow and sometimes getting slower, because real world applications are built with increasing layers of abstractions. while the hardware in the bottom layer is getting faster, the top layer is sometimes slower because there are so many layers and so much complexity in the stack.

Take this review of terminal emulator benchmarks: https://lwn.net/Articles/751763/

Uxterm, released in 1994 is the clear winner.

A "modern" terminal like Gnome Terminal has more than 10x the latency.

Booted an Electron app lately?

PragmaticPulp11• 6 years ago

A few extra seconds of app startup time or an extra frame of latency in your terminal is a small price to pay for the absolutely massive difference in functionality of newer apps.

It’s fun to see how fast apps were when everything was extremely simple, but you can’t dismiss the fact that it was orders of magnitude less capable than modern software.

The bottom line is that modern apps are fast enough. I’ve never once thought that my terminal latency is too slow or that a few extra seconds of app startup time made a any impact on my day whatsoever.

The difference between the fastest and slowest terminals on that list is less than 30ms, or 3/100ths of a second. Literally less than a blink of an eye. It’s a fun study and enjoyed the article, but the reality is that it just doesn’t matter at all.

Anyone suggesting that computers felt faster a decade ago is misremembering the past. Try using a 2008-era computer with a mechanical HDD and you’ll quickly realize that apps did not launch faster back in the day.

antepodius• 6 years ago

Modern programs are 100 times slower, but they definitely aren't 100 times more functional. And speed is a part of functionality and UX! I don't want to have to use a high-powered workstation or a gaming laptop to get reasonable responsiveness in my text editor. Many Javascript-powered websites with 'fancy' canvas features are janky and slow as shit on hardware that's only 10 years old, where as websites that use HTML are still snappy and fast.

That 'nothing at all' matters when our current culture involves building layers and layers and mountains of stacks on top of software. That 30 ms compounds, because everyone working on each layer thinks 'hey, this is a bit slow, but it doesn't matter because it's only milliseconds.' Given this, it's obvious that modern software will be as slow and inefficient as it possibly can be before normal people notice and complain (usually only because they've used other equivalent software that's smoother and faster- it's easy to get used to jank, like low FPS in a video game.)

I think that people undervalue the cost of all these layers of abstraction.

Junk_Collector4• 6 years ago

A really good typist runs around 100 words per minute. 30 millisceonds of delay vs 2 is enough that the terminal won't keep up with the person working on it. And these are TERMINALS, other software has gotten much worse in typing latency.

FpUser2• 6 years ago

"few extra seconds of app startup time"

This is atrocious. Barring the cases when the application loads and deciphers some massive dataset upon startup normal application should start instantly or close to that.

deiznof• 6 years ago

At this point I'm not even sure what people mean when they say "slow" or "poor performance", since I have a mid-tier PC and have no problems with VSCode or anything else. Everything starts fast and I have no latency issues when typing. Imperceptible differences in time are not something I would ever consider a performance problem, certainly not in the case of UX.

Same thing with memory usage. If I'm not even using a third my RAM with my browser, editor and a few other random things open I'm not going to complain about something being a "resource hog".

znpy• 6 years ago

I would be okay and favour the tradeoff... But I recently decided to eradicate gnome-calculator in favour of xcalc because gnome-calculator (probably due to being packaged as a snap) was taking 5-10 sec to show up whereas xcalc is literally instantaneous.

MaxBarraclough• 6 years ago

absolutely massive difference in functionality of newer apps

As antepodius already said, this isn't really true.

Slack has a few more features than the chat applications of 15 years ago. I suspect it may also lack a few of their features. It uses vastly more resources.

Visual Studio is a full IDE, with more features than the Electron-based Visual Sudio Code.

userbinator4• 6 years ago

Try using a 2008-era computer with a mechanical HDD and you’ll quickly realize that apps did not launch faster back in the day.

I'm still using one! And it's fast enough for what I do with it --- mainly native development in C, but also the usual communications: email, IM, watching videos, reading content-focused web sites (not web apps), etc. Since I don't use anything bloated, 4GB of RAM is more than enough and the HDD remains silent most of the time.

I experience far more delay and frustration using a much newer, ~1-year-old work laptop with much faster CPU and several times the RAM, but with Electron apps or any other "modern crap" that has a fraction of the functionality. The most vivid recent example is the YouTube "new design" --- it is disturbingly slow and dumbed-down. On this new machine I still experience lag often when interacting with bloated JS web apps, which can't even keep up with my typing speed (web-based Outlook is a notable example of this.)

Even presumably-native applications are not immune to this cancerous growth. UWP is another example; the Win10 calculator somehow needs a loading screen, and so does the Settings app, whose featureless pathetic excuse of a UI somehow manages to be less responsive than the classic Control Panel, which opens basically instantly and is just as responsive to input.

wolco2• 6 years ago

I still use a machine like that. They were faster hands down.

Even faster a commodore 64. Flick a switch the os is ready. Load geos now you have a basic windows.

hedora• 6 years ago

My desktop is about 10 years old with an old SSD, but /home is on a btrfs raid NAS on spinning disk (over WIFI). It runs a minimalist WM. I paid about $1000 for it (and a few hundred later for the boot SSD, a new video card, and a 802.11ac pcie card)

It is significantly faster at all mainstream tasks than my late 2018 $2700+ work laptop running $VENDOR_DEFAULT desktop environment.

tonymet• 6 years ago

Sorry the opposite is true here . Desktop gui apps from the 90s were much more advanced , with more features and more responsive

pjc50• 6 years ago

Quite a lot of the new functionality is "value subtraction": adware or spyware that makes the user experience worse.

The recent fiasco where Facebook accidentally broke startup for all apps using their toolkit is a good example.

drew-y4• 6 years ago

VSCode, an Electron app, is my favorite application of all time. It starts up quickly and is incredibly responsive in use.

It's easy to customize, there are loads of community extensions, and it's free. When abstractions allow software to have a flourishing community like that, to me its worth the cost.

Retric2• 6 years ago

Meanwhile I find VSCode to be a slow resource hog. I can only assume your simply so used to terrible applications that your standards have slipped.

Smithalicious• 6 years ago

Emacs has all those properties except fast startup and it's like 40 years old. Added layers of abstraction aren't to thank here.

GuB-42• 6 years ago

Still slower than Sublime Text. I gave VSCode a try and this is the reason I went back to Sublime Text. I already have a ST3 license so I didn't care about "free". Feature wise and community wise they are both very good, with maybe a small advantage for VSCode.

It isn't slow but it has noticeable micro stuttering. Enough to be annoying when coming from an editor that doesn't have this problem.

EDIT: Emacs feels surprisingly slow for such an old software, though not in the same way as VSCode. Vim is fast but I never really got into it.

blackrock2• 6 years ago

The killer-app feature for me on VSCode, is the ability to auto save over SSH.

I tried other things like Emacs, in Tramp mode, terrible. Gawd, it’s so terrible. It took me several days to figure out how to set it up. The documentation and examples were poor or non-existent. And when I finally got it to work, I was thoroughly underwhelmed.

I looked for something else, and found VSCode had a feature for SSH. I downloaded the module, connected to my SSH server, and I was operational in a few minutes. The difference between this and Emacs, was night and day.

And VSCode had all the other nice features, like code folding, syntax highlighting, and especially, function definition lookup, which makes it so convenient to work with your functions library.

hinkley2• 6 years ago

I wish I had a reference for this. I should probably go looking for it.

Someone claimed that the speed of software doubles every 18 years. I presume they meant this from a theoretical/algorithmic standpoint, rather than median behavior of software systems.

As computer speed progress slows, we should expect more effort to go into this kind of work. It seems like we are paying a good bit of attention lately to extracting the embarassingly parallel parts of our code, and chipping away at the easy end of the shared state spectrum. Amdahl tells us there is gold to be had but the digging gets harder very quickly, so I'm curious to see what will be next, after the great artists steal more of the lessons of Elixir/Erlang, Rust and friends.

cellularmitosis• 6 years ago

I believe that quote refers to compiler optimizations producing a net doubling of performance every 18 years. In effect, “software” doubles in performance.

CyberDildonics• 6 years ago

Bill Joy talked about scientific computing software advancing like that. Academic papers and new techniques filter down and the same things can be done faster.

seangrogg• 6 years ago

You don't get promoted for removing actions.

And now to drink away that depressing thought.

markstos4• 6 years ago

In the real world, when I type close to 100 wpm on keyhero.com, the highlighting of the current word can't even keep up with a human typist.

jrockway2• 6 years ago

I don't have this problem. I did some profiling and it's not doing much of anything expensive. Maybe there's some ad that I blocked or something that degrades performance for you.

monkpit• 6 years ago

Or the fact that you’re not using the same computer.

martincmartin4• 6 years ago

  for (s = i = 0; i < NUMBER; ++i) {
      s += 1;
  }

I'm surprised gcc can't figure out that this is NUMBER*(NUMBER-1) and eliminate the loop entirely.

zozbot234• 6 years ago

It probably can, at high-enough optimization level.

jrockway2• 6 years ago

gcc and clang both perform this optimization for me at -O3.

martincmartin4• 6 years ago

They used -O2, which produces the straight forward loop. [0]

But with -O3, for NUMBER > 51, is uses some other odd loop. [1]

Seems to be O(n) no matter what though.

[0] https://godbolt.org/z/czcaYf [1]: https://godbolt.org/z/sP194Y

bigdict2• 6 years ago

I'm surprised gcc can't figure out that this is NUMBER * (NUMBER-1)

Huh? Do you mean NUMBER instead? If it were s += i then that would be NUMBER * (NUMBER-1) / 2.

martincmartin4• 6 years ago

You're right, I forgot the / 2.

entha_saava2• 6 years ago

Did you mean s += i; ?

bserge• 6 years ago

Anyone interested in how much your brain can do in a second? I'm making a mindmap/chart for that in my quest to better understand natural intelligence and how it could be replicated as AI.

EricBurnett• 6 years ago

The brain is always a fun comparison. It's this crazy super-scalar architecture that can do thousands of trillions of primitive operations per second (petaflops), yet with pretty terrible latencies: propagation through synapses on the order of single digit milliseconds, individual neurons only fire order of 1 time per second, input processing latencies in the hundreds of milliseconds, and primitive "logical" algorithms like "how many numbers can you count in a second?" netting out to "less than 10".

So we end up in this state where what the brain does well computers are still (comparatively) terrible at, and what computers do well the brain is (comparatively) terrible at. We're slowly bridging that divide, with e.g. TPUs focussing on larger volumes of low precision operations happening in parallel, but we've got a long way to go yet.

ghj2• 6 years ago

The empty loop in python was surprisingly slow (68,000,000 iterations per second).

What is it actually doing here? A 3ghz cpu has 3 billion cycles per second. So it's spending an average of 44 cycles to increment an integer and compare???

(also fun fact, python integers are 28 bytes, but it still doesn't really explain the slowness: `import sys; sys.getsizeof(123456)`)

smallpipe2• 6 years ago

Python might have changed since this was written, but on my machine, with any number, it finishes in 0.0s!

My understanding was that to access a variable, python does a dictionary lookup to match the name to a memory location, which would explain what happens with an older python.

wwright2• 6 years ago

That happens for global lookups, but methods should use a stack-like lookup for local variables which should be much faster IIRC

(Personally, I really question the extremely-dynamic-by-default design of that generation of languages; is being able to treat globals as a dictionary occasionally worth forcing a key lookup on every single global use?)

teraflop• 6 years ago

I just tested this on a Linux box I happened to have running, using the "perf" tool. By my measurements, each iteration takes about 104 instructions, of which 23 are conditional branches, and completes in about 31 cycles.

(That's after subtracting about 30 million cycles of startup overhead. Tested with Python 2.7.9 on an Intel i3-4160 processor.)

Remember, Python is a bytecode-interpreted language. Each iteration of the loop involves multiple bytecode operations:

      2           0 SETUP_LOOP              20 (to 23)
                  3 LOAD_GLOBAL              0 (xrange)
                  6 LOAD_FAST                0 (NUMBER)
                  9 CALL_FUNCTION            1
                 12 GET_ITER
            >>   13 FOR_ITER                 6 (to 22)
                 16 STORE_FAST               1 (_)
    
      3          19 JUMP_ABSOLUTE           13
            >>   22 POP_BLOCK
            >>   23 LOAD_CONST               0 (None)
                 26 RETURN_VALUE

Executing each of those instructions means fetching it, jumping to the implementation of the appropriate opcode, and then updating the VM's state -- or, in the case of FOR_ITER, calling the native C function that advances the iterator.

Frankly, it's impressive that it's as fast as it is.

f1refly• 6 years ago

tested with python 2.7.9

Oof.

https://www.python.org/doc/sunset-python-2/

heavenlyblue• 6 years ago

Python integers are also not limited in size and you also run the overhead of the interpreter.

asifgdinio• 6 years ago

If we just run /bin/true, we can do 500 of them in a second, so it looks like running any program has about 1ms of overhead.

This is off by at least three orders of magnitude, at least on my machine.

    $ time for i in $(seq 1000000); do true; done

    real 0m1.049s
    user 0m1.037s
    sys  0m0.019s

This article would be better if it were about computers in general, not about Python. I specifically avoid using Python for anything serious because I find its performance impossible to reason about. Then again, perhaps it's a good thing to have examples that require thinking rather than just reciting the machine's specs like most of these lists I've seen.

mrob• 6 years ago

Your "true" is probably a shell builtin. Try it with /bin/true instead.

FastedCoyote• 6 years ago

Two tips, if you're using Bash:

1. Use the external "true" command.

2. Use {a..b} to expand sequences of numbers as "seq" adds extra overhead.

    $ time for i in {1..500}; do /bin/true; done

    real    0m0.983s
    user    0m0.650s
    sys     0m0.423s

smallpipe2• 6 years ago

I don't think the explanation for fill_array.c and fill_array_out_of_order.c is correct. Unless you're running on a massive server, you're not getting anywhere near 300MB of cache.

Modern CPUs have optimizations that bypass L1 and L2 cache allocation for a continuous burst of writes without reads, so the result here is main memory write speed, not cache allocation.

bananaface4• 6 years ago

Both examples read from the array before writing, no? So they have to read on each iteration.

I don't have a super solid grasp on caching but it seems like his method of out-of-order referencing will still be hitting a valid L1 cache most of the time, so this understates the problem. Am I misunderstanding?

rjtobin2• 6 years ago

The cartoon picture is that the first example will read everything into cache once, whereas the second example will read everything into cache twice.

Cache lines are typically 64-bytes, so to write a single character to main memory the following things happen (again, a cartoon picture): First read the 64-bytes area that contains the byte of interest so that it is owned by my cache (this is called a RFO, "read-for-ownership"). Second, update the byte of interest. Thirdly (at some point) write the cache-line back to main memory.

In the sequential case, we just read one 64-byte cache line at a time, update those 64 chars, then write the cache line back to main memory.

In the second example, we first update all the even-indexed characters, which still forces us to read in every cache line. Then we loop around and do the odd-indexed characters, at which point we have to read the cache lines all over again (assuming the array is big enough that the whole thing can't fit in cache at once).

webdva• 6 years ago

How fast can a single board computer such as the Raspberry Pi compute the solution to a linear programming problem (i.e., a mathematical optimization problem of the form Ax < b) that has, literally, trillions of constraints? Or can it even be done at all what with the large pool of constraints to navigate through? And how is such a prospect and execution compared to the computations done in the middle of the twentieth century which used weaker computers?

jancsika• 6 years ago

For the final one, I'd like to see a comparison showing how many elements can be set for a linked list in one second.

adverbly2• 6 years ago

Grep bytes surprised me. Why is it the exact same as write to memory? Is reading from memory much faster than writing or something? Even then I'm not sure how it wasn't CPU bound to compare a 4 char string 2 billion times...

mehrdada• 6 years ago

Grepping "blah" over a sequence of zeros is definitely going to be faster than regular grepping.

adverbly2• 6 years ago

Ohhh it's a sequence of zeroes.. oops I missed that part. Makes more sense now.

carlsborg• 6 years ago

342,000,000
bytes written in one second

High end NVMe ssd can probably do 3x to 10x better than ~300MB/second sequential write.

slau• 6 years ago

Indeed. I have 2TB of storage that is only 5 times slower than my 32GB of main memory (4GB/s vs 20GB/s).

bane2• 6 years ago

Something to think about, back in the 80s, when computers were millions of times slower than today, they were still considered so fast that it was worth sacrificing most of the performance by letting people work in an interpreted language BASIC -- and people were still able to be productive and do real work with them.

userbinator4• 6 years ago

Millions, no. Thousands, yes.

Keep in mind that those 80s interpreted languages still have less overhead than the HLLs of today.

bane2• 6 years ago

No, a typical desktop computer today is millions of times faster than a typical 1980s 8-bit computer.

A Commodore 64 ran a 6510 at ~1Mhz (depending on NTSC or PAL). It was a single core CPU with no pipelining or superscaler features and took multiple cycles to complete a single operation putting it's performance in the hundreds of thousands of operations (of any kind) per second.

The Playstation 4, a consumer-grade entertainment device provides around 8TFLOPs of performance.

Just a CPU, like an AMD 3990x is rated at 2.3 million MIPS while the 6502 at 1Mhz is rated at less than .430 MIPS.

coronadisaster• 6 years ago

"A newer computer won't make your code run 1000x faster :) "

unless it is quantum?

lulzx• 6 years ago

It's a critical problem, there are three key areas to prioritize to continue to deliver computing speed-ups:

- better software - new algorithms - more streamlined hardware

The performance benefits from miniaturization have been so great that, for decades, programmers have been able to prioritize making the writing of code easier rather than making the code itself run faster.

The inefficiency that this tendency introduces has been acceptable, because faster computer chips have always been able to pick up the slack.

Now, If we want to harness the full potential of these technologies, we must change our approach to computing.

The researchers recommend techniques like parallelizing code. The multicore technology has enabled complex tasks to be completed thousands of times faster and in a much more energy-efficient way.

we will have to deliver performance the hard way.

For algorithms, the team suggests a three-pronged approach that includes exploring new problem areas, addressing concerns about how algorithms scale, and tailoring them to better take advantage of modern hardware.

..many others will need to take these issues seriously if they want to stay competitive.

Performance growth will require new tools, programming languages and hardware to facilitate more and better performance engineering

computer scientists being better educated about how we can make software, algorithms and hardware work together, instead of putting them in different silos.

entha_saava2• 6 years ago

Am I the only one who dislikes all this parallelism hype? For data analysis and batch jobs on large amounts of data it would be great. Other consumer oriented applications should run on single core.

It hurts when people dismiss otherwise perfectly fine languages like OCaml saying "No multicore" as if majority of tasks need some kind of parallelism.. JS and Python don't do multicore well either.

How much your computer can do in a second (2015)

Related Stories