Live data from Hacker News

Racking Mac Pros

photos.imgix.com

211–220 of 331 posts

Re: Racking Mac Pros

#211

This seems risky from a business perspective: it's voluntary vendor lock-in. What if Apple decides to change the Mac Pro form factor for the next iteration? Then you have to retool and are left with a bunch of incompatible chassis. What if Apple stagnates with hardware upgrades? You'd be stuck running obsolete hardware. What if Apple discontinues the entire Mac Pro line? Not to mention the price premium of Apple hard…

> This seems risky from a business perspective: it's voluntary vendor lock-in.

If you want to run a business that builds/tests using the osx/ios ecosystem this is the only way to do it legally. Apple's licensing terms enforces this. Otherwise we'd be running OSX on generic pizza box servers since Apple's hardware is truly overpriced and not built efficiently at all for the datacenter (they work fine on desks). Apple really gimped the 2014 mac mini's btw. They perform worse than the high end 2012 mac minis.

Re: Racking Mac Pros

#212
post #203

Earlier quoted context omitted.

2x FirePro D500 gflop/s: 3500 That 3500 gflop/s for the D700? It is instead 2200 for the D500. http://www.amd.com/en-gb/solutions/workstations/d-series K80 runs about $4900 a card, whereas the entire Mac Pro (list price) is $4000. So it's 2.5x the performance at easily 2x the cost if not more. The 6GB VRAM version with the D700 costs another $600 USD each. The K80 has 12GB VRAM per GPU (24GB total per card). If your…

Sorry, I do have this evaluation in a spreadsheet somewhere (except against the Tesla K20, K80 wasn't out then), but I just quickly looked up the Mac Pro specs. We do use the D500, so I should have quoted those gflops. There is a benefit to off-the-shelf GPUs, but I don't see it as a make-or-break kind of situation for imgix right now. I agree that some day in the future, it does seem like it will make sense to bite…

We do use the D500, so I should have quoted those gflops.

Well now I'm curious as to why you aren't using the D700s. The extra gflops seem like a good value to me. Approximately 60% greater GPU performance for a 15% increase in cost, everything else being equal.

But you probably have to get some work done, rather than answer random questions from the Internet. :-)

Good luck!

Re: Racking Mac Pros

#213
post #207
post #201

Earlier quoted context omitted.

> Have you ever personally run a Hackintosh, full-time for a prolonged period of time? I did. But now I'm running Yosemite under KVM, VT-d motherboard, dedicated videocard and USB3 hub. You can get to a point where "it just works".

> You can get to a point where "it just works". For months and months on end of heavy usage without a single restart or issue? EDIT: to expand a little - I was developing/compiling all day long on my ~2008 MBP with it plugged into an external monitor, network, mouse, kb. I'd close the lid and walk home with it, then watch movies, torrent, develop some more, surf etc. Close lid, and repeat for months on end. The only…

> OS X and the Apple hardware work together and never, ever, ever crash, using a Hackintosh is an exercise in frustration.

Well all I can say that there are no crashes and no causes for frustration on my end.

"It just works" for me is - I don't have to think about it, it does not get in a way.

As a bonus: configuration of the VM can be put in a VCS, whole virtual disk can be snapshotted and reverted if needed.

Re: Racking Mac Pros

#214
This seems really crazy to me. I get it, when you're a startup sometimes you end up with bubblegum and scotchtape solutions like this and sometimes that really makes the most sense on many levels.

But usually you keep that to yourself! To me, this reads sorta like: "Well, it was really hard to find someone who knew how to build a replacement bridge across the creek. We were pressed for time, and Bob didn't know anything about bridges, but luckily, he used to be in the Air Force and we have a bunch of venture capital. ... So we bought a helicopter instead. We only cross a few times a year, so for now we're coming out ahead and it works out for us. Plus the pictures are nice..."

Re: Racking Mac Pros

#215
post #203

Earlier quoted context omitted.

Sorry, I do have this evaluation in a spreadsheet somewhere (except against the Tesla K20, K80 wasn't out then), but I just quickly looked up the Mac Pro specs. We do use the D500, so I should have quoted those gflops. There is a benefit to off-the-shelf GPUs, but I don't see it as a make-or-break kind of situation for imgix right now. I agree that some day in the future, it does seem like it will make sense to bite…

We do use the D500, so I should have quoted those gflops. Well now I'm curious as to why you aren't using the D700s. The extra gflops seem like a good value to me. Approximately 60% greater GPU performance for a 15% increase in cost, everything else being equal. But you probably have to get some work done, rather than answer random questions from the Internet. :-) Good luck!

It is intriguing, and we have one D700 Mac Pro for test purposes. At the time we ordered the Pros for the prototype rack that is the subject of this article, we found that other parts of our pipeline were preventing us from taking full advantage of the increased GPU performance. So we ratcheted down to the D500.

Keep in mind that either of them offer significantly higher gflop/s per system than the best GPU ever shipped on a Mac Mini (480 vs 2200 vs 3500).

However, we have fixed bottlenecks in our pipeline as we identified them, so it is probably time to re-evaluate. I actually just had a conversation with an engineer a minute ago who is going to jump on this in the next few days. Higher throughput and better $/gflop is always the goal, just have to make sure we can actually see the improvement in practice.

Re: Racking Mac Pros

#216

Earlier quoted context omitted.

CHROME ON MAC USERS: Use the imgur links instead of the 0x0 links, some users seem to be reporting crashes related to TLS. The downsampling also isn't that great. Original image: https://raw.githubusercontent.com/haasn/cms/master/rings_lg_... Downsampled with imgix: http://chen.imgix.net/rings_lg_orig.png?w=400 Downsampled with imagemagick: https://0x0.st/1-.png http://i.imgur.com/Nvl7tAm.png Downsampled with imagema…

Just FYI both of those 0x0.st images crash Chrome (Version 42.0.2311.135 (64-bit)) for me and several colleagues... You don't even have to click the link, just simply get Chrome to load it into memory edit: looks like something to do with Chrome's pre-fetching and https cert parsing, I think they're literally parsing the "0x0" string within the cert as a memory location

Ironically enough, it looks like the crash only happens on OS X.

Re: Racking Mac Pros

#217
post #125

Earlier quoted context omitted.

This was pretty much my thought as well. The results of this cost-benefit analysis make me raise my eyebrow, and, same as you, I can only assume that OS X permeates the infrastructure from top to bottom, to an extent that makes pulling it out too painful to even contemplate. Image processing shaders of this type aren't that hard to write. If you're worried about them not matching some piece of client software exactly…

(full disclosure: I work at imgix) Uploading pre-edited images takes time/resources, and in general a lot of our customers rely on us to do all of their image processing so that they don't have to. Additionally, creating edited versions of images in advance presents two problems: 1) Any future site redesigns or edits must now be applied en masse to the existing images or risk older images not complying with the new s…

Hackintoshes would make a lot more sense.

Re: Racking Mac Pros

#218
post #160
post #113

Earlier quoted context omitted.

Obviously, but running OSX on non-Apple hardware is a violation of its EULA. I have contacted a lawyer for this (I wanted to run Hackintosh in the office), the language is very clear. The author of the software has the full power to license its use to you with any restrictions they find necessary no matter how ridiculous. If Apple only sells you the license if you promise not to run it on a thursday, you'll be in vio…

This is correct, and a huge impetus for our use of Apple hardware. We simply cannot risk our business on saving some money at the expense of violating Apple's EULA.

Apple gave up on the server market. They don't care about number-crunching or scientific computing. To build a server-side based business around OS X doesn't make sense to me. Did you try writing your image processing code for Linux and CUDA / OpenCL? Is there anything specific about the OS X frameworks which means you can't develop a non-OS X solution?

Re: Racking Mac Pros

#219

Earlier quoted context omitted.

(full disclosure: I work at imgix) Uploading pre-edited images takes time/resources, and in general a lot of our customers rely on us to do all of their image processing so that they don't have to. Additionally, creating edited versions of images in advance presents two problems: 1) Any future site redesigns or edits must now be applied en masse to the existing images or risk older images not complying with the new s…

Hackintoshes would make a lot more sense.

Of course they would.

Legally? Yeah, good luck.

Edit: I think the more obvious answer to this is that they would rehouse these babies in a more convenient, albeit likely custom form-factor.

Re: Racking Mac Pros

#220
post #189
post #113

Earlier quoted context omitted.

Obviously, but running OSX on non-Apple hardware is a violation of its EULA. I have contacted a lawyer for this (I wanted to run Hackintosh in the office), the language is very clear. The author of the software has the full power to license its use to you with any restrictions they find necessary no matter how ridiculous. If Apple only sells you the license if you promise not to run it on a thursday, you'll be in vio…

> you'll be in violation if you run it on a Thursday Indeed, there is a JS library opensourced by Microsoft to decode Excel files, named xlsx.js. In the license, it is written... that it cannot run on another OS than Windows. It means even though it's Javascript, the page hosting it cannot be viewed on a Mac or Linux. Long story short, Stuart Knightley created a clean room implementation named js-xlsx to do the same…

Thanks for the mention but I only created JSZip[0], the library that powers the zip/unzip of js-xlsx[1], but not js-xlsx itself!

[0] https://github.com/Stuk/jszip [1] https://github.com/SheetJS/js-xlsx

Post reply on HN