11–20 of 104 posts
The hardware doesn't seem consistent across different benchmarks. He says it's fast for a "cpu system", but for practical purposes Phi competes more with GPGPUs.
Would this be just as fast with one redis system with 512GB ram? I don't know too many apples to oranges here.
I don't see how these results provide much useful information in terms of being able to say x is faster than y. The hardware doesn't seem consistent across different benchmarks. He says it's fast for a "cpu system", but for practical purposes Phi competes more with GPGPUs. Would this be just as fast with one redis system with 512GB ram? I don't know too many apples to oranges here.
I don't see how these results provide much useful information in terms of being able to say x is faster than y. The hardware doesn't seem consistent across different benchmarks. He says it's fast for a "cpu system", but for practical purposes Phi competes more with GPGPUs. Would this be just as fast with one redis system with 512GB ram? I don't know too many apples to oranges here.
Under a second to do an avg across 1.1 billion rows spread over four machines. That's pretty amazing.
Under a second to do an avg across 1.1 billion rows spread over four machines. That's pretty amazing.
Of course, not quite, and that's discounting the (small) sync overhead but still, no need to shell out 4 big servers, overpriced phi chips and fancy wide bus memory.
I don't see how these results provide much useful information in terms of being able to say x is faster than y. The hardware doesn't seem consistent across different benchmarks. He says it's fast for a "cpu system", but for practical purposes Phi competes more with GPGPUs. Would this be just as fast with one redis system with 512GB ram? I don't know too many apples to oranges here.
The author isn't testing just the software but combinations of various software/hardware systems, including for example PostgreSQL on an i5 CPU, 16GB RAM and 850 SSD hardware: http://tech.marksblogg.com/billion-nyc-taxi-rides-postgresql...
But what useful conclusions can be drawn from it?
If you like writing dense, clever regexs (which I do) then you'll love k & q. The amount that you can get done with just a few characters is unparalleled.
Which leads to, IMHO, their main drawback: k/q (like clever regexes) are often write-only code. Picking up another's codebase or even your own after some time has passed can be very hard/impossible because of how mindbendingly dense with logic the code it. Even if they were the best choice for a given domain, I'd try to steer clear of using them for anything other then exploratory work that doesn't need to be maintained.
Earlier quoted context omitted.
The author isn't testing just the software but combinations of various software/hardware systems, including for example PostgreSQL on an i5 CPU, 16GB RAM and 850 SSD hardware: http://tech.marksblogg.com/billion-nyc-taxi-rides-postgresql...
Great, and btw I think it's cool and I enjoyed reading it. But what useful conclusions can be drawn from it?
How does Phi's MCDRAM compare to GDDR5 (wrt throughput)?
[0]: https://en.wikipedia.org/wiki/GDDR5_SDRAM#Commercial_impleme...