Jouni

[quote name='SlabGizor117']Ok so I'll try all of that but my main point is that those parts are so bendy in the first place. It's nothing precarious like Jouni posted, all the parts are 2.5m. So why, if all the joints lie flat against each other, they shouldn't be bending. I understand that the joints aren't perfect and engines like the Vector make it worse but why are these parts so wobbly in the first place? If parts like those have to have such bad joints, at least make them brittle instead of flopping around into an L before it breaks..[/QUOTE] KSP doesn't handle stacks with many joints correctly. It treats all joints individually, instead of determining their bendiness by the dimensions and the mass of the stack. A stack of 24 X200-8 fuel tanks bends much more than a stack of three orange tanks, even though both stacks should be the same. The best workaround is to avoid stacks with many small parts in the middle. If you need probe cores, batteries, reaction wheels, and similar parts, place them inside a service bay.

[quote name='Kurld']Sure, maybe KJR is OP, but your example shows building something silly that shouldn't work but does, instead of what is arguably a far worse problem: building something that should work but doesn't, which is why we have KJR to begin with.[/QUOTE] The real issue is that individual parts don't bend and break. Unless we want to make the game silly and unbelievable by having large rigid structures, a rocket stack must bend under stress. That can only happen at joints. Due to whatever technical reason, the rigidity of a joint seems to depend only on node size. If you have many joints close to each other in the middle of a heavy stack, the rocket behaves like a nunchaku. On the other hand, if you know what's going on and avoid poor design choices, bendy rockets become extremely rare. At least as long as you're using stock parts. With 5 m and larger parts, the joint system starts breaking down, and KJR eventually becomes necessary.

[quote name='Warzouz']KJR does solve ridiculous wobbliness. But docking rings plugged to parts will still bend, you'll need struts.[/QUOTE] KJR replaces ridiculous wobbliness with ridiculous rigidity. [IMG]http://jltsiren.kapsi.fi/ksp/1.0/kjr.jpeg[/IMG] That's a 0.625 m decoupler between the lower stage and the upper stage.

I launched a probe to Moho. [IMG]http://jltsiren.kapsi.fi/ksp/1.0.5/moho_probe_0.jpeg[/IMG] [SPOILER="Leaving Kerbin behind"] [IMG]http://jltsiren.kapsi.fi/ksp/1.0.5/moho_probe_1.jpeg[/IMG] [/SPOILER] [SPOILER="It's better to do the insertion burn behind Moho to avoid overheating"] [IMG]http://jltsiren.kapsi.fi/ksp/1.0.5/moho_probe_2.jpeg[/IMG] [/SPOILER] [SPOILER="Dropping the lander from a highly eccentric orbit"] [IMG]http://jltsiren.kapsi.fi/ksp/1.0.5/moho_probe_3.jpeg[/IMG] [/SPOILER] [IMG]http://jltsiren.kapsi.fi/ksp/1.0.5/moho_probe_4.jpeg[/IMG] The landing was quite uneventful. [SPOILER="Back in orbit"] [IMG]http://jltsiren.kapsi.fi/ksp/1.0.5/moho_probe_5.jpeg[/IMG] [/SPOILER] [SPOILER="I was low on fuel, so I had to do a detour around Eve"] [IMG]http://jltsiren.kapsi.fi/ksp/1.0.5/moho_probe_6.jpeg[/IMG] [/SPOILER] [SPOILER="The plan was to let the transfer stage to pass through the atmosphere and escape into interplanetary space"] [IMG]http://jltsiren.kapsi.fi/ksp/1.0.5/moho_probe_7.jpeg[/IMG] [/SPOILER] [SPOILER="If failed. Luckily kerbals don't care about radiation."] [IMG]http://jltsiren.kapsi.fi/ksp/1.0.5/moho_probe_8.jpeg[/IMG] [/SPOILER] [SPOILER="Splashed down in one piece"] [IMG]http://jltsiren.kapsi.fi/ksp/1.0.5/moho_probe_9.jpeg[/IMG] [/SPOILER] The probe design was accidentally very good for reentry. It naturally oriented itself heat shield first, and kept the orientation even when the parachutes were semi-deployed. When the parachutes were fully deployed, the probe slowly rotated to meet the ground landing struts first.

I did some experiments with recoverable interplanetary probes. [IMG]http://jltsiren.kapsi.fi/ksp/1.0.5/probe_reentry_1.jpeg[/IMG] This probe/lander pair survived reentry at interplanetary speeds quite well... [IMG]http://jltsiren.kapsi.fi/ksp/1.0.5/probe_reentry_2.jpeg[/IMG] ...except one of the landing struts, which wasn't completely protected by the heat shield. The MechJeb box looks big and ugly at this scale.

Moho isn't too bad, because you can use [URL="http://jltsiren.kapsi.fi/ksp/1.0/moho_mission_2.jpeg"]Eve gravity assists[/URL] [URL="http://jltsiren.kapsi.fi/ksp/1.0/moho_mission_7.jpeg"]both ways[/URL]. Another trick is to add an extra 1000 m/s to the lander and park the mothership in a highly eccentric orbit. The last time I went there, I started with around 6500 m/s in the transfer stage at LKO: [IMG]http://jltsiren.kapsi.fi/ksp/1.0/moho_mission_1.jpeg[/IMG] It was more than enough, even though I made some bad decisions on the way there. I was even able to salvage the transfer stage for future missions with some "careful" aerobraking: [IMG]http://jltsiren.kapsi.fi/ksp/1.0/moho_mission_8.jpeg[/IMG]

That looks about right. If you have 30% more mass for the same cross-sectional area, you need 30% more drag to decelerate at the same rate. In Kerbin's lower atmosphere, that means going about 2 km lower. The real issue here is that the Mk1 pod is quite heavy for its size.

I guess Squad has some plans for making the heavy 2.5 m crew modules more useful in the future. Perhaps they're going to be the crew modules intended for long-term space travel. Maybe those parts have better life support, or maybe engineers and scientists will be able to do more, if they EVA from a ship with one of those parts.

I built a quick 1.0.5 entry. A pure rocket, as always, and deliberately not too optimized. It's a reasonably big rocket with 18 Vectors and no other engines. The boosters were gimbal locked, while the gimbal range of core engines was limited to 20% of the maximum. MechJeb says more, and I'm not sure why. Perhaps it counts the launch clamps, which were necessary, because the Vector has a tendency to explode if it touches the launchpad. Each booster had a Sepratron with 1.6 units of fuel. They weren't strictly necessary, but it was too easy to hit the falling boosters without them. I did a few short burns during while coasting to rotate the rocket and dropped the interstage fairing at around 55 km. The service bay in the core stage contains reaction wheels, a probe core, and a battery. Six struts connect the payload to the fairing base, and another four struts connect the fairing base to the core stage. Entry name: Space, Vector Launch mass: 1055.93 tonnes Payload mass: 276.53 tonnes Payload fraction: 26.19%

I also built a plane. Unfortunately I forgot landing gear, and the plane didn't survive my first splashdown attempt.

I built the first idea I had when I heard about the Vector engine. If you put the payload at the bottom, kerbals don't have to climb too high to reach space.

You're missing the point, if you think the Vector as an 1.25 m engine. The Reliant is an 1.25-tonne engine and the Swivel is an 1.5-tonne engine. The Vector is a 4-tonne engine with performance appropriately between the 3-tonne Skipper and the 6-tonne Mainsail. If you place a Vector in a 1.25 m stack, you will almost always get worse performance than with a Swivel (and a couple of boosters for heavier payloads) due to the extra mass. The Vector is a nice special-purpose engine for the situations, where you need a lot of thrust but don't have room for bigger engines. It's also useful as a midrange first stage engine for rockets, where a Skipper would be too weak and a Mainsail would be too heavy.

I tried 1.0.5, and it broke almost all of my mods in hilarious ways. Looks like I don't have the time to try it properly before the weekend. The obligatory rocket to test the new Vector engine: It went to orbit in 64K with a plenty of fuel to spare. It also looks like the SAS was behaving better than in 1.0.4. The Vector feels like it's the perfect first stage engine for the smaller 2.5 m rockets, at least if you tweak the gimbal range down to 20% or so. This is what a reentry looks like when the mods don't like 1.0.5:

I continued playing with 64K. After the Mun, Duna is the next obvious target, so I started designing a nuclear transfer stage. It looks like 5 m parts a no longer powerful enough for the 6.4x scale. Maybe I'll have to try something bigger. The current prototype may not be big enough for the actual mission, but the design looks promising.

I returned to KSP after a while. I haven't played too much since the summer, because the Mac version barely works with a minimal number of mods. Add any part mods, and you have to reduce texture resolution, making everything look blurry and annoying. Anyway, I decided to endure the blurry textures, installed 64K and SpaceY, and went to the Mun. First observation: you need a 2x bigger rocket to go to the 6.4x Mun than before 1.0. Reduced engine efficiency certainly makes the life harder. The Mun is still as flat as it was in the 6.4x Kerbol System.

I'm using g++ 5.2.0 on OS X. The C# code was compiled on Mono 4.2.0. I didn't even know that I had Mono installed, and this was the first time I compiled any C# code. The last time I used Visual Studio was 15 years ago, and the last version of Windows I used was Windows 2000.

I did a quick C++ conversion of the code: #include <array> #include <chrono> #include <cstdint> #include <iostream> #include <random> #include <vector> const uint64_t SAMPLE_COUNT = 100000000; const double TO_NANO = 1000000000.0 / SAMPLE_COUNT; double readTimer() { std::chrono::duration<double> temp = std::chrono::steady_clock::now().time_since_epoch(); return temp.count(); } struct array_access { std::string name; array_access() : name("access") {} inline uint64_t operator() (uint64_t n) { return n; } }; struct reverse8 { std::string name; std::array<uint8_t, 256> data; reverse8() : name("reverse8") { std::vector<uint64_t> reverse4 = { 0x0, 0x8, 0x4, 0xC, 0x2, 0xA, 0x6, 0xE, 0x1, 0x9, 0x5, 0xD, 0x3, 0xB, 0x7, 0xF }; for(uint64_t i = 0; i < data.size(); i++) { data[i] = ((reverse4[i & 0xF] << 4) | reverse4[i >> 4]); } } inline uint64_t operator() (uint64_t n) const { return ((uint64_t)data[n & 0xFF] << 56 | (uint64_t)data[(n >> 8) & 0xFF] << 48 | (uint64_t)data[(n >> 16) & 0xFF] << 40 | (uint64_t)data[(n >> 24) & 0xFF] << 32 | (uint64_t)data[(n >> 32) & 0xFF] << 24 | (uint64_t)data[(n >> 40) & 0xFF] << 16 | (uint64_t)data[(n >> 48) & 0xFF] << 8 | (uint64_t)data[n >> 56]); } }; struct reverse16 { std::string name; std::vector<uint16_t> data; reverse16(const reverse8& r8) : name("reverse16"), data(1 << 16) { for(uint64_t i = 0; i < data.size(); i++) { data[i] = ((r8.data[i & 0xFF] << 8) | r8.data[i >> 8]); } } inline uint64_t operator() (uint64_t n) { return ((uint64_t)data[n & 0xFFFF] << 48 | (uint64_t)data[(n >> 16) & 0xFFFF] << 32 | (uint64_t)data[(n >> 32) & 0xFFFF] << 16 | (uint64_t)data[(n >> 48) & 0xFFFF]); } }; struct reverse24 { std::string name; std::vector<uint32_t> data; reverse24(const reverse8& r8) : name("reverse24"), data(1 << 24) { for(uint64_t i = 0; i < data.size(); i++) { data[i] = ((r8.data[i & 0xFF] << 16) | (r8.data[(i >> 8) & 0xFF] << 8) | r8.data[i >> 16]); } } inline uint64_t operator() (uint64_t n) { return ((uint64_t)data[(n >> 40) & 0xFFFFFF] | (uint64_t)data[(n >> 16) & 0xFFFFFF] << 24 | (uint64_t)data[n & 0xFFFF] << 40); } }; template<class Func> void profile(Func& func, const std::vector<uint64_t>& samples) { std::cout << "Profiling " << func.name << "..." << std::endl; uint64_t r = 0; double start = readTimer(); for(uint64_t i = 0; i < samples.size(); i++) { r ^= func(samples[i]); } double seconds = readTimer() - start; std::cout << "Result = " << r << std::endl; std::cout << func.name << ": " << (seconds * TO_NANO) << " ns/call" << std::endl; std::cout << std::endl; } int main(int argc, char** argv) { std::cout << "Initializing..." << std::endl; array_access aa; reverse8 r8; std::cout << "8-bit table built." << std::endl; reverse16 r16(r8); std::cout << "16-bit table built." << std::endl; reverse24 r24(r8); std::cout << "24-bit table built." << std::endl; std::cout << "Testing..." << std::endl; std::mt19937_64 rng(0xDEADBEEF); std::vector<uint64_t> samples(SAMPLE_COUNT); for(uint64_t i = 0; i < samples.size(); i++) { samples[i] = rng(); if(r8(samples[i]) != r16(samples[i])) { std::cout << "Failed: reverse8 != reverse16 @ " << samples[i] << std::endl; return 1; } if(r16(samples[i]) != r24(samples[i])) { std::cout << "Failed: reverse16 != reverse24 @ " << samples[i] << std::endl; return 1; } } std::cout << "Tests passed." << std::endl; std::cout << std::endl; profile(aa, samples); profile(r8, samples); profile(r16, samples); profile(r24, samples); return 0; } With the C# version, I also observed a significant performance difference between the 8-bit lookup table and the 16-bit lookup table: $ mcs -o+ foo.cs $ mono foo.exe Initializing... 8-bit table built. 16-bit table built. 24-bit table built. Testing... Tests passed. Profiling array access... Result = 0x611E686E163A105C Base time: 1,054863 ns/call Profiling Reverse8... Result = 0x3A085C6876167886 Reverse8: 10,821065 ns/call Profiling Reverse16... Result = 0x3A085C6876167886 Reverse16: 6,586188 ns/call Profiling Reverse24... Result = 0x3A085C6876167886 Reverse24: 34,173045 ns/call In the C++ version, the differences in performance were quite minor: $ g++-5 -std=c++11 -Wall -O3 foo.cpp -o foo $ ./foo Initializing... 8-bit table built. 16-bit table built. 24-bit table built. Testing... Tests passed. Profiling access... Result = 1630952772224003662 access: 0.585153 ns/call Profiling reverse8... Result = 8247669395094127976 reverse8: 4.34656 ns/call Profiling reverse16... Result = 8247669395094127976 reverse16: 4.06664 ns/call Profiling reverse24... Result = 8247669395094127976 reverse24: 26.3678 ns/call

You may want to repeat the experiment with the random samples stored in an array instead of being generated on the fly. These days, processors typically have 64 kilobytes of L1 cache and 256 kilobytes of L2 cache per core. An 8-bit lookup table takes 256 bytes, while a 16-bit lookup table requires 128 kilobytes. When you benchmark Reverse8() and Reverse16() with randomly generated numbers, you're essentially comparing an 8-bit lookup table in L1 cache vs. a 16-bit lookup table in L2 cache. On the other hand, if the data resides in memory (as it would in the real use case), an 8-bit lookup table would probably still remain in L1 cache most of the time, while you might have constant L2 cache misses with a 16-bit lookup table.

Xeons are x86-64 processors, just like the i3/i5/i7 family. They're just intended for the server/workstation market instead of the desktop/laptop market. In general, computers using Xeon processors have more memory and more CPU cores, while computers using a desktop-grade i5/i7 processor have better single-threaded performance.

The 52-bit limit is based on the architecture. In the page table, only the middle 40 bits are used for the physical base address of the page, while the remaining bits are reserved for CPU/OS use. As the native page size is 2^12 bytes, this yields 2^52 bytes of physical address space.

That 64 GB limit is for 32-bit x86 processors using some ugly tricks. Current x64 processors support up to 256 TB of memory using 48-bit addresses. The architecture itself could support 4 PB (52 bits), but as far as I know, individual processes would still be limited to 256 TB of address space. The biggest x64 servers I've seen have 6 TB of memory (96 slots with 64 GB DIMMs).

It would ruing NASA's scientific mission. Working with foreign researchers as a branch of military would be hard, while hiring foreigners would become next to impossible. Even collaborating with US universities would be difficult, because many of their researchers are foreign nationals.

Most of that 35+ years is ancient history. Google has used commodity hardware from the beginning, and most other big internet companies have made similar choices. Around 10 years ago, Intel and AMD basically took the entire supercomputer market in a few years. These days, if you want performance and scalability, you choose x64. Even IBM is too small to develop cost-effective alternatives to the hardware everyone else is using. There are basically two reasons for using mainframes. You may have decades worth of legacy software that's not going to be replaced very soon. Alternatively, you may prefer reliability over performance, and hence choose mainframe hardware designed for that particular niche. The niche exists and appears to be stable, but it's not very large compared to the rest of the server market.

Mainframes are rare in industry too these days. They're mostly used in situations where redundancy and reliability are more important than performance. The biggest and most powerful mainframe on sale today has only about 2x more performance and 67% more memory than the biggest server you can build from commodity hardware. The price tag, on the other hand, is much larger than 2x.

Almost nobody uses mainframes anymore. A supercomputer is typically just a bunch of ordinary servers. The same kind of hardware that runs most web services. You can buy individual servers yourself or rent them on demand from your favorite cloud computing provider. If you work in an academic setting, you can probably get access to a computing cluster with tens or even hundreds of servers.