One possible reason is that four concurrent processes generate a more favourable pattern of log flushes - typically meaning that each log flush writes more data than is the case with a single executing process.

To determine if transaction log throughput/flush size is a factor, monitor:

* sys.dm_os_wait_stats for `WRITELOG` waits
* sys.dm_io_pending_io_requests for IO performance
* Performance Monitor counters for:
 * Log Bytes Flushed/sec
 * Log Flushes/sec
 * Log Flush Wait Time

Look for internal limits being reached. In SQL Server 2008 R2, there can be a maximum of 32 outstanding (asynchronous) log flush I/Os per database on 64-bit versions (only 8 on 32-bit). There is also a total size limit on the outstanding IOs of 3840KB.

More information:

* [Transaction Log Monitoring][1]
* [Trimming Transaction Log Fat][2]
* [Diagnosing Transaction Log Performance Issues and Limits of the Log Manager][3]


  [1]: http://sqlperformance.com/2013/11/sql-performance/transaction-log-monitoring
  [2]: http://sqlperformance.com/2013/01/io-subsystem/trimming-more-transaction-log-fat
  [3]: https://blogs.msdn.microsoft.com/sqlcat/2013/09/10/diagnosing-transaction-log-performance-issues-and-limits-of-the-log-manager/