Are you saying that 16 GB isn't enough?
It's common to run several types of server in production, these all need to be run on localhost for development purposes. Also virtual environments so server architecture can easily be scripted.
16GB works for me, but is far from ideal. I was hoping MS would one-up Apple here, but not yet.
AFAIK, the reason ultrabooks have LPDDR3 is because it is very low profile when soldered. If thin is your thing, you want LPDDR3. My t460p has a smaller footprint than a MBP, but it is as thick as a whole stack of them.
The difference between LPDDR3 and DDR3 isn't dramatic in actual operation; LPDDR3 uses about 70% of the power of DDR3.
It becomes a bigger deal when the machine is in standby, however; LPDDR3 uses 10% the power of DDR3. This would be a big deal for Apple, which also insists on using LPDDR3, and has historically sold machines with standby times measured in weeks or months. Not sure if people have particular expectations of standby times from Surface Pros, but if they're used like tablets you'd want it to be decent. Keeping the memory powered is nearly the only power used when a computer's in standby, so 10x the power usage would be a huge deal.
Furthermore, I found that solutions which couldn't be successfully worked on with <16GB RAM were basically architecturally unsound. Not being able to scale the workload on demand or control peak demand. Extra RAM just hid poor developers from their non-scalable solutions - or just increased their downtime till they got an OUT OF MEM error. The issues were only exacerbated at scale - failing even with 128+ GB in RAM.
Basically, when the difference between a dev sample and a prod sample is 3+ orders of magnitude, your ability to scale the process up/down, fail gracefully, even battery life, etc. are far more important than having large swathes of memory to fail on. Especially on the go.
If you do deal with production (big) data, you're ssh'ed in to some always-on, process-maintained hardware if only for the sake of latency and interruptions. And you better have the toolset to do it. How much memory does a terminal take?
For graphics, I understand - but then you're definitely not working on a surface pro or on the go at all really.
ie I'm running Rails, MySQL, Elastic, Redis, Nginx, Memcached, and in some cases, multiple instances (dev, test, and multiple shards)
And then the usual OS requirements - Vim, 250 browser tabs, Slack, Hangouts, etc.
I'm sure there are all manner of optimisations and assumptions that could cut things down, but I'd rather the big manufacturers upgrade their RAM capacity every few years so I can focus on a dev environment that's a good approximation for prod.
Also, 250 tabs? dayum. I don't know how anyone could effectively use that many tabs. I don't think thats what browsers/laptops are designed for. My mind memory of just the tabs would be saturated long before the laptop's.
I do work in graphics/rendering, I work on laptops often and plan to get a surface pro, 16 GBs is the most painful part of working on a laptop for sure. It is the primary reason I spend most of my day on the 128GB ram desktop whenever I'm close. But even 32GB would go a long way for me.
Longer device life and usefulness comes come from additional ram than a beefier processor.
Apple mentioned somewhere the 32 GB laptop jump involves dealing with a battery usage hit. While 32 GB arrives, a few vendors like Lenovo seem to have the 32 GB offering available in laptops, but not their Surface Pro clone.
What's the point of the question?
Lots of end users want a laptop with 32g.
Windows overhead, Visual Studio, Linux VMs, multiple docker containers, local dynamodb, sql database, queues, etc. If you're developing locally against a workflow with a few VMs in the mix, 16gb can be an incredible constraint. I'm not trying to simulate hundreds of users, just one across a stack.
the demand for 32g in a laptop was greater than the demand for a touchbar, I can tell you that.
Fortunately, there’re some ultrabooks on the market with user-upgradeable RAM. This article says Intel CPUs supports 16GB DDR3L modules since Broadwell, i.e. you should be able to install 32GB yourself: http://www.techrepublic.com/article/16-gb-so-dimm-ram-module...
It becomes essential once you start running VM's or Docker etc
Remember, this is a fanless design so thermal throttling will be insane, just like on the macbook and the xps13.
why does this apply here: because I can easily imagine artists using this to modify some assets and trying to run the game to see what they look like, but with 16GB of ram they won't even load the editor, much less the actual server+client combo.
But hey, we're always hiring!
by the way the integrated graphics are real shit in this laptop, better go get a MSI or something. This PC's are clearly not for high end work, it's just Macbook Pro kind of "pro".
PD: I think if you're running the whole map on the RAM you're doing something wrong.
Is it really shocking that dev machines have a lot of ram?
If someone works in full frame photography or edits 4K video, do you tell them to try working on machines with 4GB of ram to see what they come up with, and how it's going to be "beneficial"?
Why would it be any different for games? When a level designer loads the entire map into editor, it's the same as loading a 4K video into Adobe Premiere - it's going to eat up your ram, and you need to have loads of it.
>>Who in hell does run a game server on a laptop, and outside office?
At E3, the answer is - literally everyone. We send one guy with a fully encrypted beefy laptop that runs all servers during the show, and he has to keep an eye on it 100% of the time. You're not going to fly a desktop over the Atlantic just for a games conference.
Because they can travel with people and desktop computers.. kinda.. can't.
Why not fly just an encrypted SSD with the game and buy desktop at the location?
With global inventories, it shouldn't be that hard for major vendors like Dell or Apple to offer an identical configuration to drop a hard drive into.
"He knew from experience that it was always impossible to cut content down to memory budgets, and that many projects had come close to failing because of it. So now, as a regular practice, he always put aside a nice block of memory to free up when it's really needed."
[1]: http://www.gamasutra.com/view/feature/132500/dirty_coding_tr...
I work on a pretty complex system myself and every few months somebody comes in,takes a quick look and tells us we just need to use framework X and all will be easy. Guess what, we are not totally stupid and have looked at it already. And it wouldn't solve the actual problem which is that it's just a very complex thing we are doing.
First understand what people are doing before telling them they are wrong.
TEST things under the constraints of machines that people own. Multiple people have given multiple reasons why there are better ways to do things. I read another recently talking about being able to capture all the game state for debugging, too.
Because it's impractical, unnecessary and wasteful. There are a number of processes that by their nature require global knowledge. These are not the sorts of processes that need to be done in the client (many of them in fact are done up front precisely so that a client will not need to do them), but they are the sorts of processes that a developer will need to do if they are to be able to make a change and see its effect. Also, there are good reasons to generate assets at a higher resolution than needed in the final artifact.
Just like if you're rendering a 3d animated film you might need a more powerful machine than those who are only watching it, or if you're training a neural net, you need a more powerful system than if you're merely running it.
But I work in the same company as Gambiting, on the same game I think. And yes, loading a map that is the size of San Andreas in GTA5 (with more props) is expensive on memory.
You can't "load a region" in the editor, not because there is a design constraint but because you need to generate navigation meshes, collision systems, render objects etc before you "stream" them in, not to mention that "streaming" is a hack that is build for consoles and weak PCs and has to be optimised for to work reliably, you'd spend more time chasing bugs in your streaming than actual bugs you were working with.
So, you load the whole map, you generate your navigation mesh and run your collision detection, and then you can do mapwide things like "find breaks in the world" and other stuff.
In this case, yes, 64G is helpful, because a developers time, especially a tools programmers time who deals in very low level C++/ASM optimisations for AAA games' time is worth more than a studio full of 64G ram modules.
For videogames, both latency, bandwidth, and software support ain’t quite there yet.
I've taken to using an external usb fan to get extra speed.